Socket编程之非阻塞connect

比眉伴天荒 2022-06-17 12:06 378阅读 0赞

## 出处：http://blog.sina.com.cn/s/blog\_7977ed370101gvux.html    ##

**非阻塞 connect：**

在一个 TCP 套接字被设置为非阻塞之后调用 connect ，connect 会立即返回 **EINPROGRESS**错误，表示连接操作正在进行中，但是仍未完成，与此同时 TCP 三次握手操作会同时进行。在这之后，我们可以通过调用 select来检查这个链接是否建立成功。  
  
**非阻塞 connect 有三种用途：**  
1.我们可以在 TCP 三次握手的同时做一些其它的处理。connect操作需要一个往返时间才能完成，从几个毫秒（局域网）到几百毫秒或几秒（广域网）。在这段时间内我们可能有一些其他的处理想要同时执行；  
2.可以用这种技术同时建立多个连接。在 Web 浏览器中很普遍；  
3.由于我们使用 select 来等待连接的完成，因此我们可以给 select 设置一个时间限制，从而缩短 connect的超时时间。在大多数实现中，connect 的超时时间在 **75秒到几分钟**之间。有时候应用程序想要一个更短的超时时间，使用非阻塞 connect 就是一种方法。  
  
**非阻塞 connect 听起来虽然简单，但是仍然有一些细节问题要处理：**  
1.即使套接字是非阻塞的，如果连接的服务器在同一台主机上，那么在调用 connect建立连接时，连接通常会立即建立成功。我们必须处理这种情况；  
2.源自 Berkeley 的实现有两条与 select 和非阻塞 I/O 相关的规则：  
    A)当连接建立成功时，套接口描述符变成**可写**；  
    B)当连接建立出错时，套接口描述符变成**既可读又可写**；  
  
注意：当一个套接口出错时，它会被 select 调用标记为既可读又可写。  
非阻塞 connect 有这么多好处，但是处理非阻塞 connect 时会遇到很多【可移植性问题】。  
  
**处理非阻塞 connect 的步骤：**  
第一步，创建 socket，返回套接字描述符；  
第二步，调用 fcntl 或 ioctlsocket 把套接口描述符设置成非阻塞；  
第三步，调用 connect 开始建立连接；  
第四步，判断连接是否成功建立：  
    A)如果 connect 返回 0，表示连接成功(服务器和客户端在同一台机器上时就有可能发生这种情况)；  
    B)调用 select来判定连接建立的是否成功；  
      如果 select返回 0 ，则表示在 select的超时时间内未能成功建立连接；我们需要返回超时错误给用户，同时关闭连接，以防止TCP三次握手继续进行下去；  
      如果 select返回大于 0 的值，则说明检测到可读或可写或异常的套接字描述符存在；此时我们可以通过调用 getsockopt来检测集合中的套接口上是否存在待处理的错误，如果连接建立是成功的，则通过getsockopt(sockfd,SOL\_SOCKET,SO\_ERROR,(char\*)&error,&len) 获取的 error 值将是 0，如果建立连接时遇到错误，则 error 的值是连接错误所对应的 errno值，比如ECONNREFUSED，ETIMEDOUT等。  
  
=============  
“读取套接口上的错误”是遇到的【第一个可移植性问题】：如果出现问题，getsockopt 源自 Berkeley 的实现是返回 0，等待处理的错误在变量 errno 中返回；但是 Solaris 会让 getsockopt 返回 -1 ，errno置为待处理的错误。我们对这两种情况都要处理。  
  
这样，在处理非阻塞 connect 时，在不同的套接口实现的平台中存在的移植性问题。首先，有可能在调用 select之前，连接就已经建立成功，而且对方的数据已经到来。在这种情况下，连接成功时套接口将既可读又可写，这和连接失败时是一样的。这个时候我们还得通过getsockopt 来读取错误值。这是【第二个可移植性问题】。  
=============  
  
**移植性问题总结 ：**  
1.对于出错的套接口描述符，getsockopt 的返回值源自 Berkeley 的实现是返回 0 ，待处理的错误值存储在 errno中；而源自 Solaris 的实现是返回 -1 ，待处理的错误存储在 errno 中。(套接口描述符出错时调用 getsockopt的返回值不可移植)  
2.有可能在调用 select之前，连接就已经建立成功，而且对方的数据已经到来，在这种情况下，套接口描述符是既可读又可写，这与套接口描述符出错时是一样的。(怎样判断连接是否建立成功的条件不可移植)  
  
这样的话，在我们判断连接是否建立成功的条件不唯一时，我们可以有以下的方法来解决这个问题：  
1.调用获取对端socket地址的 getpeername 代替 getsockopt 。如果调用 getpeername失败，getpeername 返回 ENOTCONN ，表示连接建立失败，之后我们必须再以 SO\_ERROR 调用getsockopt 得到套接口描述符上的待处理错误；  
2.调用 read ，读取长度为 0 字节的数据。如果连接建立失败，则 read 会返回 -1 ，且相应的 errno指明了连接失败的原因；如果连接建立成功，read 应该返回 0 。  
3.再调用一次 connect 。它应该失败，如果错误 errno 是 EISCONN，就表示套接口已经建立，而且第一次连接是成功的；否则，连接就是失败的。  
  
**被中断的 connect ：**  
如果在一个阻塞式套接口上调用 connect ，在 TCP的三次握手操作完成之前被中断了，比如说被捕获的信号中断，将会发生什么呢？假定 connect 不会自动重启，它将返回 EINTR。那么这个时候，我们就不能再调用 connect 等待连接建立完成了，如果再次调用 connect来等待连接建立完成的话，connect 将会返回错误值 EADDRINUSE 。在这种情况下，应该做的是调用 select，就像在非阻塞式 connect 中所做的一样。然后 select在连接建立成功(使套接口描述符可写)或连接建立失败(使套接口描述符既可读又可写)时返回。

socket api存在一批核心接口，而这一批核心接口就是几个看似简单的函数，尽管实际上这些函数没有一个是简单。connect函数就是这些核心接口中的一个函数，它完成主动连接的过程。

connect 函数的功能对于TCP来说就是完成面向连接的协议的连接过程，它的函数原型：

linux下

\#include

int connect(int sockfd, const struct sockaddr\*server\_addr, socklen\_t addrlen)

windows下

int connect(

SOCKETs,    // 没绑定套接口描述字

const structsockaddr FAR \*name,   //目标地址指针，目标地址中必须包含IP和端口信息。

intnamelen   // name的长度

);

面向连接的协议，在建立连接的时候总会有一方先发送数据(SYN)，那么谁调用了 connect 谁就是先发送数据的一方。如此理解connect 三个参数就容易了。我必需指定数据发送的目的地址，同时也必需指定数据从哪里发送，这正好是 connect的前两个参数，而第三个参数是为第二个参数服务的。  
  
参数 **sockfd **  
指定数据发送的套接字，解决从哪里发送的问题。内核需要维护大量 I/O 通道，所以用户必需通过这个参数告诉内核从哪个 I/O通道（此处就是从哪个 socket 接口）中发送数据。  
  
参数 **server\_addr **  
指定数据发送的目的地，也就是服务器端的地址。这里服务器是针对 connect 说的，因为 connect是主动连接的一方调用的，所以相应的要存在一个被连接的一方，被动连接的一方需要调用 listen 以接受 connect的连接请求，如此被动连接的一方就是服务器了。   
  
参数 **addrlen**   
指定 server\_addr 结构体的长度。我们知道系统中存在大量的地址结构，但 socket接口只是通过一个统一的结构来指定参数类型，所以需要指定一个长度，以使内核在进行参数复制的时候有个界限。

返回值：没有错误发生，返回0；否则返回 SOCKET\_ERROR(-1) 。

=============================================

与所有的 socket 网络接口一样，connect 总会在某个时候可能失败，此时它会返回 -1，相应的 errno会被设置，用户可能通过这个值确定是哪个错误。常见的错误有对方主机不可达或者超时错误，也可以是对方主机没有相应的进程在对应端口等待。

connect 函数可用于 ***面向连接套接字*，** 也可用于***无连接套接字*** 。  
  
**无连接套接字**：对于无连接的套接字 (SOCK\_DGRAM)，该套接字与目标地址之间建立默认的对应关系，且在本地保存了对端的地址，这样后续的读写操作可以默认以连接的对端为操作对象，网络数据交互发生时可以直接使用send ，而不是用 sendto 来向该地址发送数据；内核会丢弃所有发送给该套接字的源地址不是 connect 地址的报文。再次调用connect 函数，若此时 name 和 namelen 两个参数均为空指针，就会将该套接字恢复为未连接状态，再调用 send函数，系统会提示 WSAENOTCONN 错误码。  
  
**面向连接套接字**：面向连接的套接字 (SOCK\_STREAM) ，函数 connect 会引起调用端主动进行 TCP的三次握手过程。结果通常是成功连接、WSAETIMEDOUT (多次发送SYN报文，始终未收到回复)、WSAECONNREFUSED(目标主机返回 RST) 等。  
  
　　当对端机器 crash 或者网络连接被断开(比如路由器不工作，网线断开等)，此时发送数据给对端然后读取本端 socket 会返回ETIMEDOUT 或者 EHOSTUNREACH 或者 ENETUNREACH(后两个是中间路由器判断服务器主机不可达的情况)。  
  
　　当对端机器 crash 之后又重新启动，然后客户端再向原来的连接发送数据，因为服务器端已经没有原来的连接信息，此时服务器端回送RST 给客户端，此时客户端读本地端口返回 ECONNRESET 错误。  
  
　　当服务器所在的进程正常或者异常关闭时，会对所有打开的文件描述符进行 close ，因此对于连接的 socket描述符则会向对端发送 FIN 分节进行正常关闭流程。对端在收到 FIN 之后端口变得可读，此时读取端口会返回 0表示到了文件结尾(对端不会再发送数据)。　  
  
　　当一端收到 RST 导致读取 socket 返回 ECONNRESET ，此时如果再次调用 write 发送数据给对端则触发SIGPIPE 信号，信号默认终止进程，如果忽略此信号或者从 SIGPIPE 的信号处理程序返回则 write 出错返回 EPIPE。  
  
================================= =====  
1) Broken PIPE 的字面意思是“管道破裂”。Broken PIPE 产生的原因是该管道的读端被关闭。  
2) Broken PIPE 经常发生在 Client 端通过 Socket 发送信息到 Server 端后，就关闭当前 Socket, 之后 Server 端回复信息给 Client 端时。  
3) 发生 Broken PIPE 错误时，调用写的进程会收到 SIGPIPE 信号，默认动作是导致当前进程终止。  
4) Broken PIPE 最直接的意思是：写入端出现的时候，PIPE的另一端却休息或退出了，因此造成没有及时取走管道中的数据，从而系统异常退出。  
  
**Client 端通过 PIPE 发送信息到 Server端后，就关闭 Client 端 Socket , 这时Server 端返回信息给 Client 端时就会产生 BrokenPIPE 信号。**

======================================

可以看出只有当本地端口主动发送消息给对端才能检测出连接异常中断的情况，搭配 select进行多路分离的时候，socket 收到 RST 或者 FIN 时候，select返回可读(心跳消息就是用于检测连接的状态)。也可以使用 socket 的 KEEPLIVE 选项，依赖 socket 本身侦测socket 连接异常中断的情况。  
  
  
**错误信息：**  
  
EACCES, EPERM：用户试图在套接字广播标志没有设置的情况下连接广播地址或由于防火墙策略导致连接失败。  
EADDRINUSE：本地地址处于使用状态。  
EAFNOSUPPORT：参数 serv\_add 中的地址非法。  
EAGAIN：没有足够空闲的本地端口。  
EALREADY：套接字为非阻塞套接字，并且原来的连接请求还未完成。  
EBADF：非法的文件描述符。  
ECONNREFUSED：远程地址并没有处于监听状态。  
EFAULT：指向套接字结构体的地址非法。  
EINPROGRESS：套接字为非阻塞套接字，且连接请求没有立即完成。  
EINTR：系统调用的执行由于捕获中断而中止。  
EISCONN：已经连接到该套接字。  
ENETUNREACH：网络不可到达。  
ENOTSOCK：文件描述符不与套接字相关。

ETIMEDOUT：连接超时。