zoukankan html css js c++ java

非阻塞Connect对于select时应注意问题

http://www.cnitblog.com/zouzheng/archive/2010/11/25/71711.html

对于面向连接的socket类型(SOCK_STREAM,SOCK_SEQPACKET)在读写数据之前必须建立连接，首先服务器端socket必须在一个客户端知道的地址进行监听,也就是创建socket之后必须调用bind绑定到一个指定的地址，然后调用int listen(int sockfd, int backlog);进行监听。此时服务器socket允许客户端进行连接，backlog提示没被accept的客户连接请求队列的大小，系统决定实际的值，最大值定义为SOMAXCONN在头文件<sys/socket.h>里面。如果某种原因导致服务器端进程未及时accpet客户连接而导致此队列满了的话则新的客户端连接请求被拒绝(在工作中遇到过此情况，IONA ORBIX(CORBA中间件)由于没有配置超时时间结果在WIFI网络中传输数据出现异常情况一直阻塞而无机会调用accept接受新的客户请求，于是最终队列满导致新的客户连接被拒绝)。

　　调用listen之后当有客户端连接到达的时候调用int accept(int sockfd, struct sockaddr *restrict addr, socklen_t *restrict len);接受客户端连接建立起连接返回用于连接数据传送的socket描述符，进行监听的socket可以用于继续监听客户端的连接请求，返回的socket描述符跟监听的socket类型一致。如果addr不为NULL,则客户端发起连接请求的socket地址信息会通过addr进行返回。如果监听的socket描述符为阻塞模式则accept一直会阻塞直到有客户发起连接请求，如果监听的socket描述符为非阻塞模式则如果当前没有可用的客户连接请求，则返回-1(errno设置为EAGAIN)。可以使用select函数对监听的socket描述符进行多路分离，如果有客户连接请求则select将监听的socket描述符设置为可读(注意，如果监听的socket为阻塞模式而使用select进行多路分离则可能造成select返回可读但是调用accept会被阻塞住的情况，原因是在调用accept之前客户端可能主动关闭连接或者发送RST异常关闭连接，因此select最好跟非阻塞socket搭配使用)。

　　客户端调用int connect(int sockfd, const struct sockaddr *addr, socklen_t len);发起对服务器的socket的连接请求，如果客户端socket描述符为阻塞模式则会一直阻塞到连接建立或者连接失败(注意阻塞模式的超时时间可能为75秒到几分钟之间)，而如果为非阻塞模式，则调用connect之后如果连接不能马上建立则返回-1(errno设置为EINPROGRESS，注意连接也可能马上建立成功比如连接本机的服务器进程),如果没有马上建立返回，此时TCP的三路握手动作在背后继续，而程序可以做其他的东西，然后调用select检测非阻塞connect是否完成(此时可以指定select的超时时间，这个超时时间可以设置为比connect的超时时间短)，如果select超时则关闭socket，然后可以尝试创建新的socket重新连接，如果select返回非阻塞socket描述符可写则表明连接建立成功，如果select返回非阻塞socket描述符既可读又可写则表明连接出错(注意：这儿必须跟另外一种连接正常的情况区分开来，就是连接建立好了之后，服务器端发送了数据给客户端，此时select同样会返回非阻塞socket描述符既可读又可写，这时可以通过以下方法区分:
　　1.调用getpeername获取对端的socket地址.如果getpeername返回ENOTCONN,表示连接建立失败,然后用SO_ERROR调用getsockopt得到套接口描述符上的待处理错误;
　　2.调用read,读取长度为0字节的数据.如果read调用失败,则表示连接建立失败,而且read返回的errno指明了连接失败的原因.如果连接建立成功,read应该返回0;
　　3.再调用一次connect.它应该失败,如果错误errno是EISCONN,就表示套接口已经建立,而且第一次连接是成功的;否则,连接就是失败的;
　　对于无连接的socket类型(SOCK_DGRAM)，客户端也可以调用connect进行连接,此连接实际上并不建立类似SOCK_STREAM的连接，而仅仅是在本地保存了对端的地址，这样后续的读写操作可以默认以连接的对端为操作对象。

　　当对端机器crash或者网络连接被断开(比如路由器不工作，网线断开等)，此时发送数据给对端然后读取本端socket会返回ETIMEDOUT或者EHOSTUNREACH 或者ENETUNREACH(后两个是中间路由器判断服务器主机不可达的情况)。

　　当对端机器crash之后又重新启动，然后客户端再向原来的连接发送数据，因为服务器端已经没有原来的连接信息，此时服务器端回送RST给客户端，此时客户端读本地端口返回ECONNRESET错误。

　　当服务器所在的进程正常或者异常关闭时，会对所有打开的文件描述符进行close，因此对于连接的socket描述符则会向对端发送FIN分节进行正常关闭流程。对端在收到FIN之后端口变得可读，此时读取端口会返回0表示到了文件结尾(对端不会再发送数据)。　

　　当一端收到RST导致读取socket返回ECONNRESET，此时如果再次调用write发送数据给对端则触发SIGPIPE信号，信号默认终止进程，如果忽略此信号或者从SIGPIPE的信号处理程序返回则write出错返回EPIPE。

　　可以看出只有当本地端口主动发送消息给对端才能检测出连接异常中断的情况,搭配select进行多路分离的时候，socket收到RST或者FIN时候，select返回可读(心跳消息就是用于检测连接的状态)。也可以使用socket的KEEPLIVE选项，依赖socket本身侦测socket连接异常中断的情况。

　　发送socket数据有以下方法:

　　调用ssize_t send(int sockfd, const void *buf, size_t nbytes, int flags);，只能用于建立好了连接的socket(面向连接的SOCK_STREAM或者调用了connect的SOCK_DGRAM)。flags取值如下:

　　MSG_DONTROUTE 对数据不进行路由

　　MSG_DONTWAIT 不等待数据发送完成

　　MSG_EOR 数据包结尾

　　MSG_OOB 带外数据

　　注意send函数成功返回并不代表对端一定收到了发送的消息，另外对于数据报协议如果发送的数据大于一个数据报长度则发送失败(errno设置为EMSGSIZE)。

linux 客户端 Socket 非阻塞connect编程(正文)

linux 客户端 Socket 非阻塞connect编程（正文）/*开发过程与源码解析

　　开发测试环境：虚拟机CentOS，windows网络调试助手
　　非阻塞模式有3种用途

　　1.三次握手同时做其他的处理。connect要花一个往返时间完成，从几毫秒的局域网到几百毫秒或几秒的广域网。这段时间可能有一些其他的处理要执行，比如数据准备，预处理等。
　　2.用这种技术建立多个连接。这在web浏览器中很普遍.
　　3.由于程序用select等待连接完成，可以设置一个select等待时间限制，从而缩短connect超时时间。多数实现中，connect的超时时间在75秒到几分钟之间。有时程序希望在等待一定时间内结束，使用非阻塞connect可以防止阻塞75秒，在多线程网络编程中，尤其必要。例如有一个通过建立线程与其他主机进行socket通信的应用程序，如果建立的线程使用阻塞connect与远程通信，当有几百个线程并发的时候，由于网络延迟而全部阻塞，阻塞的线程不会释放系统的资源，同一时刻阻塞线程超过一定数量时候，系统就不再允许建立新的线程（每个进程由于进程空间的原因能产生的线程有限），如果使用非阻塞的connect，连接失败使用select等待很短时间，如果还没有连接后，线程立刻结束释放资源，防止大量线程阻塞而使程序崩溃。

　　目前connect非阻塞编程的普遍思路是：
　　在一个TCP套接口设置为非阻塞后，调用connect，connect会在系统提供的errno变量中返回一个EINRPOCESS错误，此时TCP的三路握手继续进行。之后可以用select函数检查这个连接是否建立成功。以下实验基于unix网络编程和网络上给出的普遍示例，在经过大量测试之后，发现其中有很多方法，在linux中，并不适用。

　　我先给出了重要源码的逐步分析，在最后给出完整的connect非阻塞源码。
　　1.首先填写套接字结构，包括远程的ip，通信端口如下： */
　　struct sockaddr_in serv_addr;
　　serv_addr.sin_family=AF_INET;
　　serv_addr.sin_port=htons(9999);
　　serv_addr.sin_addr.s_addr = inet_addr("58.31.231.255"); //inet_addr转换为网络字节序
　　bzero(&(serv_addr.sin_zero),8);

　　// 2.建立socket套接字：
　　if ((sockfd = socket(AF_INET, SOCK_STREAM, 0)) == -1)
　　{
　　perror("socket creat error");
　　return 1;
　　}

　　// 3.将socket建立为非阻塞，此时socket被设置为非阻塞模式
　　flags = fcntl(sockfd,F_GETFL,0);//获取建立的sockfd的当前状态（非阻塞）
　　fcntl(sockfd,F_SETFL,flags|O_NONBLOCK);//将当前sockfd设置为非阻塞
　　/*4. 建立connect连接，此时socket设置为非阻塞，connect调用后，无论连接是否建立立即返回-1，同时将errno（包含errno.h就可以直接使用）设置为EINPROGRESS, 表示此时tcp三次握手仍旧进行，如果errno不是EINPROGRESS，则说明连接错误，程序结束。
　　当客户端和服务器端在同一台主机上的时候，connect回马上结束，并返回0；无需等待，所以使用goto函数跳过select等待函数，直接进入连接后的处理部分。*/

　　if ( ( n = connect( sockfd, ( struct sockaddr *)&serv_addr , sizeof(struct sockaddr)) ) < 0 )
　　{
　　if(errno != EINPROGRESS) return 1;
　　}

　　if(n==0)
　　{
　　printf("connect completed immediately");
　　goto done;
　　}

　　/* 5.设置等待时间，使用select函数等待正在后台连接的connect函数，这里需要说明的是使用select监听socket描述符是否可读或者可写，如果只可写，说明连接成功，可以进行下面的操作。如果描述符既可读又可写，分为两种情况，第一种情况是socket连接出现错误（不要问为什么，这是系统规定的，可读可写时候有可能是connect连接成功后远程主机断开了连接close(socket)），第二种情况是connect连接成功，socket读缓冲区得到了远程主机发送的数据。需要通过connect连接后返回给errno的值来进行判定，或者通过调用 getsockopt(sockfd,SOL_SOCKET,SO_ERROR,&error,&len); 函数返回值来判断是否发生错误，这里存在一个可移植性问题，在solaris中发生错误返回-1，但在其他系统中可能返回0.我首先按unix网络编程的源码进行实现。如下：*/

　　FD_ZERO(&rset);
　　FD_SET(sockfd,&rset);
　　wset = rset;
　　tval.tv_sec = 0;
　　tval.tv_usec = 300000;
　　int error;
　　socklen_t len;

　　if(( n = select(sockfd+1, &rset, &wset, NULL,&tval)) <= 0)
　　{
　　printf("time out connect error");
　　close(sockfd);
　　return -1;
　　}

　　If ( FD_ISSET(sockfd,&rset) || FD_ISSET(sockfd,&west) )
　　{
　　len = sizeof(error);
　　if( getsockopt(sockfd,SOL_SOCKET,SO_ERROR,&error,&len) <0)
　　return 1;
　　}

　　/* 这里我测试了一下，按照unix网络编程的描述，当网络发生错误的时候，getsockopt返回-1，return -1，程序结束。网络正常时候返回0，程序继续执行。
　　可是我在linux下，无论网络是否发生错误，getsockopt始终返回0，不返回-1，说明linux与unix网络编程还是有些细微的差别。就是说当socket描述符可读可写的时候，这段代码不起作用。不能检测出网络是否出现故障。
　　我测试的方法是，当调用connect后，sleep（2）休眠2秒，借助这两秒时间将网络助手断开连接，这时候select返回2，说明套接口可读又可写，应该是网络连接的出错情况。
　　此时，getsockopt返回0，不起作用。获取errno的值，指示为EINPROGRESS，没有返回unix网络编程中说的ENOTCONN，EINPROGRESS表示正在试图连接，不能表示网络已经连接失败。
针对这种情况，unix网络编程中提出了另外3种方法，这3种方法，也是网络上给出的常用的非阻塞connect示例：
　　a.再调用connect一次。失败返回errno是EISCONN说明连接成功，表示刚才的connect成功，否则返回失败。代码如下：*/

　　int connect_ok;

　　connect(sockfd, (struct sockaddr *)&serv_addr, sizeof(struct sockaddr) );
　　switch (errno)
　　{
　　case EISCONN: //connect ok
　　printf("connect OK \n");
　　connect_ok = 1;
　　break;
　　case EALREADY:
　　connect_0k = -1
　　break;
　　case EINPROGRESS: // is connecting, need to check again
　　connect_ok = -1
　　break;
　　default:
　　printf("connect fail err=%d \n",errno);
　　connect_ok = -1;
　　break;
　　}

　　/*如程序所示，根据再次调用的errno返回值将connect_ok的值，来进行下面的处理，connect_ok为1继续执行其他操作，否则程序结束。
　　但这种方法我在linux下测试了，当发生错误的时候,socket描述符（我的程序里是sockfd）变成可读且可写，但第二次调用connect 后，errno并没有返回EISCONN，,也没有返回连接失败的错误，仍旧是EINPROGRESS，而当网络不发生故障的时候，第二次使用 connect连接也返回EINPROGRESS，因此也无法通过再次connect来判断连接是否成功。
　　b.unix网络编程中说使用read函数，如果失败，表示connect失败，返回的errno指明了失败原因，但这种方法在linux上行不通，linux在socket描述符为可读可写的时候，read返回0，并不会置errno为错误。
　 c.unix网络编程中说使用getpeername函数，如果连接失败，调用该函数后，通过errno来判断第一次连接是否成功，但我试过了，无论网络连接是否成功，errno都没变化，都为EINPROGRESS，无法判断。
　　悲哀啊，即使调用getpeername函数，getsockopt函数仍旧不行。
　　综上方法，既然都不能确切知道非阻塞connect是否成功，所以我直接当描述符可读可写的情况下进行发送，通过能否获取服务器的返回值来判断是否成功。(如果服务器端的设计不发送数据，那就悲哀了。)
　　程序的书写形式出于可移植性考虑，按照unix网络编程推荐写法，使用getsocketopt进行判断，但不通过返回值来判断，而通过函数的返回参数来判断。
　　6. 用select查看接收描述符，如果可读，就读出数据，程序结束。在接收数据的时候注意要先对先前的rset重新赋值为描述符，因为select会对 rset清零，当调用select后，如果socket没有变为可读，则rset在select会被置零。所以如果在程序中使用了rset，最好在使用时候重新对rset赋值。

　　程序如下：*/

　　FD_ZERO(&rset);
　　FD_SET(sockfd,&rset);//如果前面select使用了rset，最好重新赋值

　　if( ( n = select(sockfd+1,&rset,NULL, NULL,&tval)) <= 0 )
　　{
　　close(sockfd);
　　return -1;
　　}

　　if ((recvbytes=recv(sockfd, buf, 1024, 0)) ==-1)
　　{
　　perror("recv error!");
　　close(sockfd);
　　return 1;

　　}
　　printf("receive num %d\n",recvbytes);

　　printf("%s\n",buf);

　　*/

非阻塞connect

在一个TCP套接口被设置为非阻塞之后调用connect,connect会立即返回EINPROGRESS错误,表示连接操作正在进行中,但是仍未完成;同时TCP的三路握手操作继续进行;在这之后,我们可以调用select来检查这个链接是否建立成功;非阻塞connect有三种用途:
1.我们可以在三路握手的同时做一些其它的处理.connect操作要花一个往返时间完成,而且可以是在任何地方,从几个毫秒的局域网到几百毫秒或几秒的广域网.在这段时间内我们可能有一些其他的处理想要执行;
2.可以用这种技术同时建立多个连接.在Web浏览器中很普遍;
3.由于我们使用select来等待连接的完成,因此我们可以给select设置一个时间限制,从而缩短connect的超时时间.在大多数实现中,connect的超时时间在75秒到几分钟之间.有时候应用程序想要一个更短的超时时间,使用非阻塞connect就是一种方法;
非阻塞connect听起来虽然简单,但是仍然有一些细节问题要处理:
1.即使套接口是非阻塞的,如果连接的服务器在同一台主机上,那么在调用connect建立连接时,连接通常会立即建立成功.我们必须处理这种情况;
2.源自Berkeley的实现(和Posix.1g)有两条与select和非阻塞IO相关的规则:
A:当连接建立成功时,套接口描述符变成可写;
B:当连接出错时,套接口描述符变成既可读又可写;
注意:当一个套接口出错时,它会被select调用标记为既可读又可写;

非阻塞connect有这么多好处,但是处理非阻塞connect时会遇到很多可移植性问题;

处理非阻塞connect的步骤:
第一步:创建socket,返回套接口描述符;
第二步:调用fcntl把套接口描述符设置成非阻塞;
第三步:调用connect开始建立连接;
第四步:判断连接是否成功建立;
       A:如果connect返回0,表示连接简称成功(服务器可客户端在同一台机器上时就有可能发生这种情况);
       B:调用select来等待连接建立成功完成;
         如果select返回0,则表示建立连接超时;我们返回超时错误给用户,同时关闭连接,以防止三路握手操作继续进行下去;
         如果select返回大于0的值,则需要检查套接口描述符是否可读或可写;如果套接口描述符可读或可写,则我们可以通过调用getsockopt来得到套接口上待处理的错误(SO_ERROR),如果连接建立成功,这个错误值将是0,如果建立连接时遇到错误,则这个值是连接错误所对应的errno值(比如:ECONNREFUSED,ETIMEDOUT等).
"读取套接口上的错误"是遇到的第一个可移植性问题;如果出现问题,getsockopt源自Berkeley的实现是返回0,等待处理的错误在变量errno中返回;但是Solaris会让getsockopt返回-1,errno置为待处理的错误;我们对这两种情况都要处理;

这样,在处理非阻塞connect时,在不同的套接口实现的平台中存在的移植性问题,首先,有可能在调用select之前,连接就已经建立成功,而且对方的数据已经到来.在这种情况下,连接成功时套接口将既可读又可写.这和连接失败时是一样的.这个时候我们还得通过getsockopt来读取错误值;这是第二个可移植性问题;
移植性问题总结:
1.对于出错的套接口描述符,getsockopt的返回值源自Berkeley的实现是返回0,待处理的错误值存储在errno中;而源自Solaris的实现是返回0,待处理的错误存储在errno中;(套接口描述符出错时调用getsockopt的返回值不可移植)
2.有可能在调用select之前,连接就已经建立成功,而且对方的数据已经到来,在这种情况下,套接口描述符是既可读又可写;这与套接口描述符出错时是一样的;(怎样判断连接是否建立成功的条件不可移植)

这样的话,在我们判断连接是否建立成功的条件不唯一时,我们可以有以下的方法来解决这个问题:
1.调用getpeername代替getsockopt.如果调用getpeername失败,getpeername返回ENOTCONN,表示连接建立失败,我们必须以SO_ERROR调用getsockopt得到套接口描述符上的待处理错误;
2.调用read,读取长度为0字节的数据.如果read调用失败,则表示连接建立失败,而且read返回的errno指明了连接失败的原因.如果连接建立成功,read应该返回0;
3.再调用一次connect.它应该失败,如果错误errno是EISCONN,就表示套接口已经建立,而且第一次连接是成功的;否则,连接就是失败的;

被中断的connect:
如果在一个阻塞式套接口上调用connect,在TCP的三路握手操作完成之前被中断了,比如说,被捕获的信号中断,将会发生什么呢?假定connect不会自动重启,它将返回EINTR.那么,这个时候,我们就不能再调用connect等待连接建立完成了,如果再次调用connect来等待连接建立完成的话,connect将会返回错误值EADDRINUSE.在这种情况下,应该做的是调用select,就像在非阻塞式connect中所做的一样.然后,select在连接建立成功(使套接口描述符可写)或连接建立失败(使套接口描述符既可读又可写)时返回;

Linux网络编程之connect函数分析

在一个 CLIENT/SERVER模型的网络应用中，客户端的调用序列大致如下：

socket -> connect -> recv/send -> close

其中socket没有什么可疑问的，主要是创建一个套接字用于与服务端交换数据，并且通常它会迅速返回，此时并没有数据通过网卡发送出去，而紧随其后的 connect函数则会产生网络数据的发送，TCP的三次握手也正是在此时开始，connect会先发送一个SYN包给服务端，并从最初始的CLOSED 状态进入到SYN_SENT状态，在此状态等待服务端的确认包，通常情况下这个确认包会很快到达，以致于我们根本无法使用netstat命令看到 SYN_SENT状态的存在，不过我们可以做一个极端情况的模拟，让客户端去连接一个随意指定服务器（如IP地址为88.88.88.88），因为该服务器很明显不会反馈给我们SYN包的确认包(SYN ACK)，客户端就会在一定时间内处于SYN_SENT状态，并在预定的超时时间（比如3分钟）之后从connect函数返回，connect调用一旦失败(没能到达ESTABLISHED状态)这个套接字便不可用，若要再次调用connect函数则必须要重新使用socket函数创建新的套接字。

下面结合实例分析，客户端代码如下：

非阻塞Connect对于select时应注意问题

linux 客户端 Socket 非阻塞connect编程(正文)

Linux网络编程之connect函数分析

linux connect 设置连接超时

Linux网络编程之connect函数分析

Linux网络编程之tcpdump抓包分析TCP三次握手过程

TCP连接状态转换详细描述