linux模拟端口阻塞,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在连接建立成功(使套接口描述符可写)或连接建立失败(使套接口描述符既可读又可写)时返回;