使用I / O复用时的无阻塞套接字

如何解决使用I / O复用时的无阻塞套接字

如果我有一个具有I / O多路复用功能的TCP服务器，我是否应该使用无阻塞套接字非常困惑，因为互联网上有一些示例不使用它，而有些示例却使用了它。

是否存在差异？如果可以，那么对于可公开访问的服务器来说，更好的选择是什么

解决方法

如果您的TCP服务器是单线程的并且使用阻止I / O，那么连接到它的任何客户端很可能仅通过发送部分消息就可以拒绝向所有其他客户端提供服务，或者或者，在服务器发送数据后，拒绝从其TCP套接字读取任何数据。在前一种情况下，服务器可能会阻塞很长一段时间（也许永远），以等待从客户端接收到整个消息。在此期间，服务器将无法响应其他客户端。在后一种情况下，服务器将阻塞很长一段时间（也许永远），以等待客户端读取一些TCP数据，以便可以耗尽服务器套接字的发送缓冲区，以将更多的传出数据容纳到该客户端。 >

避免该问题的一种方法是将服务器的所有套接字都设置为非阻塞I / O模式。这样，服务器知道它永远不会陷入recv()或send()调用中，因此可以保持对所有客户端的响应，而不管某个特定客户端的运行状况是否良好。在非阻塞设计中，服务器阻塞的唯一位置是位于select()或poll()或类似位置，因为这些调用旨在在任何客户端需要服务时返回，而不是仅阻塞一个客户。 （权衡是，使用非阻塞I / O时，服务器的缓冲/排队逻辑将需要更复杂一些，因为您不能再假定在给定的发送或发送过程中将发送或接收任何特定固定数量的字节。接收操作）

避免出现此问题的另一种方法是制作多线程服务器。这样做的好处是每个客户端都有自己的线程，因此行为不佳的客户端只会阻塞自己的线程，而不会阻塞为其他客户端提供服务的线程。缺点是现在您的服务器是多线程的，并且多线程会带来所有其他陷阱。

（并且，为了完整起见，第三个方法只是忽略行为不佳/连接不良的客户端的可能性，并使用单线程/阻塞模型。这对于希望客户端是玩具的示例很好用非敌对的，并且它们所连接的网络是可靠的，但在现实生活中效果不佳

,

当您希望错误响应（EWOULDBLOCK / EAGAIN而不是线程等待（阻塞）直到可以进行IO操作时，使用非阻塞IO。

这导致了一个问题：如何实现IO多路复用？

如果您使用的是每个连接线程模型（或每个连接进程），则使用阻塞IO可能会更舒适。

但是，如果同一线程正在提供多个IO对象，则阻塞IO会很危险，并且可能使整个应用程序停止运行

当单个线程为多个IO对象提供服务时，最好使用非阻塞IO。

请注意，在开始轮询（使用select / poll或epoll / kqueue）时，该问题一开始可能并不明显。

由于IO操作仅由已经“知道” IO操作不会被阻塞的代码路径执行（已被轮询并且已知为可用操作）。

这掩盖了一个问题，即在代码中某处可能不先轮询就直接调用IO操作，从而导致阻塞的IO调用，从而使应用程序停止运行。