Socket非阻塞connect编程

2013年7月2日 由 Creater 留言 »

非阻塞模式有3种用途
1、三次握手同时做其他的处理。connect要花一个往返时间完成,从几毫秒的局域网到几百毫秒或几秒的广域网。这段时间可能有一些其他的处理要执行,比如数据准备,预处理等。

2、用这种技术建立多个连接。这在web浏览器中很普遍。

3、由于程序用select等待连接完成,可以设置一个select等待时间限制,从而缩短connect超时时间。多数实现中,connect的超时时间在75秒到几分钟之间。有时程序希望在等待一定时间内结束,使用非阻塞connect可以防止阻塞75秒,在多线程网络编程中,尤其必要。

目前connect非阻塞编程的普遍思路是:
在一个TCP套接口设置为非阻塞后,调用 connect,connect会在系统提供的errno变量中返回一个EINRPOCESS错误,此时TCP的三路握手继续进行。之后可以用 select函数检查这个连接是否建立成功。

流程为:
1、首先填写套接字结构,包括远程的ip,通信端口;
2、建立socket套接字;
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,则说明连接错误,程序结束。
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网络编程的源码进行实现。

可是我在linux下,无论网络是否发生错误,getsockopt始终返回0,不返回-1,说明linux与unix网络编程还是有些细微的差别。就是说当socket描述符可读可写的时候,这段代码不起作用。不能检测出网络是否出现故障。
我测试的方法是,当调用connect后,sleep(2)休眠2秒,借助这两秒时间将网络助手断开连接,这时候select返回2,说明套接口可读又可写,应该是网络连接的出错情况。
此时,getsockopt返回0,不起作用。获取errno的值,指示为EINPROGRESS,没有返回unix网络编程中说的ENOTCONN,EINPROGRESS表示正在试图连接,不能表示网络已经连接失败。
针对这种情况,unix网络编程中提出了另外3种方法,这3种方法,也是网络上给出的常用的非阻塞connect示例:
1、再调用connect一次。失败返回errno是EISCONN说明连接成功,表示刚才的connect成功,否则返回失败。
但这种方法我在linux下测试了,当发生错误的时候,socket描述符(我的程序里是sockfd)变成可读且可写,但第二次调用connect 后,errno并没有返回EISCONN,,也没有返回连接失败的错误,仍旧是EINPROGRESS,而当网络不发生故障的时候,第二次使用 connect连接也返回EINPROGRESS,因此也无法通过再次connect来判断连接是否成功。
2、unix网络编程中说使用read函数,如果失败,表示connect失败,返回的errno指明了失败原因,但这种方法在linux上行不通,linux在socket描述符为可读可写的时候,read返回0,并不会置errno为错误。
3、unix网络编程中说使用getpeername函数,如果连接失败,调用该函数后,通过errno来判断第一次连接是否成功,但我试过了,无论网络连接是否成功,errno都没变化,都为EINPROGRESS,无法判断。
综上方法,既然都不能确切知道非阻塞connect是否成功,所以我直接当描述符可读可写的情况下进行发送,通过能否获取服务器的返回值来判断是否成功。(如果服务器端的设计不发送数据,那就悲哀了。)
程序的书写形式出于可移植性考虑,按照unix网络编程推荐写法,使用getsocketopt进行判断,但不通过返回值来判断,而通过函数的返回参数来判断。
用select查看接收描述符,如果可读,就读出数据,程序结束。在接收数据的时候注意要先对先前的rset重新赋值为描述符,因为select会对 rset清零,当调用select后,如果socket没有变为可读,则rset在select会被置零。所以如果在程序中使用了rset,最好在使用时候重新对rset赋值。

广告位

发表评论

你必须 登陆 方可发表评论.