为什么TCP服务器的监听套接字要设置为非阻塞

常见的网络通信模型都会使用IO多路复用如select、poll、epoll等。当有新的连接请求到来时，监听套接字变为可读，然后调用accept()接收新连接、返回一个连接套接字。 如果监听套接字是阻塞的，问题可能出在什么地方？ 先来看下TCP三次握手的示意图： 从图中可知，connect()会先于accep()函数返回。 当一个连接到来的时候，监听套接字可读，此时，我们稍微等一段时间之后再调用a...

在这种情况下，可以将accept函数包含在一个无限循环中，并在每次循环中使用select函数来检查是否有新的连接到来。在这个例子中，使用select函数每隔一秒钟检查是否有新的连接到来。监听socket必须绑定一个端口，以便其他客户端可以连接到这个端口，并与该服务端进行通信。在调用accept函数之前，可以通过设置socket的属性来将其设置为非阻塞模式。接下来，调用accept函数会立即返回，而不会一直等待新连接的到来。无论哪种方式，都可以将accept函数设置为非阻塞模式，避免程序一直等待连接的到来。

在网络编程时，我们需要注意创建的socket是阻塞状态还是非阻塞状态的，这两种状态在编程时，对于每一个socket系统调用函数（connect、send、sendto、recv、recvfrom）都有一定的影响，socket的阻塞和非阻塞状态可以在每一个socket系统调用调用之前设置，对应着每一个socket系统调用是否是阻塞和非阻塞的；

别在网上瞎学了，我最近也做了一些资源的更新，只要你是我的粉丝，这期福利你都可拿走。我先来介绍一下这些东西怎么用，文末抱走。

本节来理论性的了解一下关于服务端 accept 非阻塞. 阻塞 accept 服务器在繁忙过程时, 在建立三次握手之后, 调用accept之前, 如果出现客户端突然断开连接的情况, POSIX 指出这种情况 errno 设置为 CONNABORTED. 如: 三次握手之后, 客户端发送 RST后断开连接, 之后服务端调用accept准备执行连接但并不知道对端已经关闭, 这个时候accept就...

常见的网络通信模型都会使用IO多路复用技术如select、poll、epoll等。当有新的连接请求到来时，监听套接字变为可读，然后调用accept()接收新连接、返回一个连接套接字。 如果监听套接字是阻塞的，问题可能出在什么地方？ 先来看下TCP三次握手的示意图： 从图中可知，connect()会先于accep()函数返回。 当一个连接到来的时候，监听套接字可读，此时，我们稍微等一段时间之后再调用accept()。就在这段时间内，客户端设置linger选项(l_onoff = 1, l_li

以muduo为例，在类Acceptor中，监听套接字acceptSocket_在初始化时调用socket::createNonblockingOrDie()， 它的实现如下： int sockets::createNonblockingOrDie(sa_family_t family) { #if VALGRIND int sockfd = ::socket(family, SOCK_STREA...

往往在select 或 epoll 中把 listen_socket 设置为非阻塞 O_NONBLOCK原因是出在 accept 上, 比如有这么一个客户端: RST客户端 当这个select或epoll 的服务器非常繁忙时, 有这么一个一连接就断开的客户端,此时 select 返回, 但还没执行到accept , 客户端就断开了, 然后...

普通套接字的缺陷 普通套接字一次只能服务一个客户端，而且若无客户端连接，accept（）一直阻塞，无数据传输，recv一直阻塞，传输效率极低。 普通服务器的IO模型 操作系统监听用户进程的状态，若无数据，则一直等待，知道用户请求数据，操作系统才进行数据处理。 普通套接字实现的服务端的瓶颈 在没有新的套接字来之前， 不能处理已经建立连接的套接字的请求（多个客户端连接只有一个被服务）...

套接字的默认状态是阻塞的，这就意味着当发出一个不能立即完成的套接字调用时，其进程将被投入睡眠，等待响应操作完成，可能阻塞的套接字调用可分为以下四类： (1) 输入操作，包括read，readv，recv，recvfrom，recvmsg； (2) 输出操作，包括write，writev，send，sendto，sendmsg； (3) 接受外来连接，即accept函数。 (4) 发起外出连...

在使用 socket 的一些 api 的时候，默认情况下都是阻塞模式。比如使用 tcp socket 时，客户端调用 connect() 创建连接，connect() 返回的时候要么是创建连接成功了，要么是出现了错误，反正 connect() 返回的时候结果是确定的；tcp 服务端使用 accept() 接收连接的时候，accept() 返回的时候一般就是接收到了新的连接；使用 recv() 接收数据的时候，直到接收到数据之后，才会返回；

阻塞模式 对于TCP套接字（默认情况下），当使用 write()/send() 发送数据时： 1) 首先会检查缓冲区，如果缓冲区的可用空间长度小于要发送的数据，那么 write()/send() 会被阻塞（暂停执行），直到缓冲区中的数据被发送到目标机器，腾出足够的空间，才唤醒 write()/send() 函数继续写入数据。 2) 如果TCP协议正在向网络发送数据，那么输出缓冲区会被锁定，不允许...

把套接字改成阻塞或非阻塞模式

服务器端 ------------------------------------------------------------------------   #define _WINSOCK_DEPRECATED_NO_WARNINGS   #include  #pragma comment(lib, "ws2_32.lib")   #include      #defi

首先我简单介绍一下同步TCP编程 与异步TCP编程。 在服务端我们通常用一个TcpListener来监听一个IP和端口。客户端来一个请求的连接，在服务端可以用同步的方式来接收，也可以用异步的方式去接收。比如： TcpListene server = new TcpListener(IPAddress.Parse("127.0.0.1"), port); TcpClien...