Socket Connect问题

首页 > 代码库 > Socket Connect问题

2024-08-13 12:50:37 224人阅读

一、非阻塞Connect对于Select时应注意的问题
二、linux客户端socket非阻塞connect编程

一、非阻塞Connect对于Select时应注意的问题

对于面向连接的socket（SOCK_STREAM、SOCK_SEQPACKET），在读写数据之前必须建立连接。

建立连接的过程：

首先，服务器端socket必须在一个客户端知晓的地址（IP和端口号）进行监听，也就是说，创建socket之后，必须调用int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen);将socket绑定到一个指定的地址struct sockaddr *addr，然后调用int listen(int sockfd, int backlog);进行监听。此时，服务器socket允许客户端进行连接，backlog表示套接字socket排队的最大连接个数，系统决定实际的值，最大值定义为定义在头文件里的SOMAXCONN宏。如果由于某种原因，服务器端进程未及时accept客户端连接导致此队列满，则新的客户端连接请求将被拒绝。

服务器调用listen监听之后，当有客户端连接到达时，调用int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);接收客户端连接请求，同时返回一个已连接socket描述符用于在客户端和服务器连接间传输数据。同时，原监听socket可以继续监听客户端的连接请求。如果addr不为NULL，则客户端发起连接请求的客户端socket的地址信息会通过addr返回。如果监听socket描述符为阻塞模式，则accept会一直阻塞到有客户发起连接请求；如果监听socket描述符为非阻塞模式，如果当前没有可用的客户端连接请求，则会返回-1（errno设置为EAGAIN）。可以使用select函数对监听的socket描述符进行多路分离：如果有客户端连接请求，select函数将监听socket描述符设置为可读。注意：如果监听socket为阻塞模式，那么，当使用select进行多路分离时，可能造成select返回可读但是调用accept会被阻塞住的情况，原因是在调用accept之前客户端可能主动关闭连接或者发送RST异常关闭连接，因此，建议select与非阻塞select一起使用。

对于客户端，其调用int connect(int sockfd, const struct sockaddr *addr, socklen_t addrlen);发起对服务器socket的连接请求，如果客户端socket描述符为阻塞模式，则其会一直阻塞到连接建立或者连接失败（注意，阻塞模式的超时时间可能为75秒到几分钟之间）；如果客户端socket描述符为非阻塞模式，则调用connect之后，如果连接未能立即建立，则返回-1（errno设置为EINPROGRESS，注意连接也可能马上建立成功，如连接本机服务器进程），如果没有立即建立返回，此时TCP的三路握手动作在后台进行，程序可执行其他操作，然后调用select检测非阻塞connect是否完成（可以指定select的超时时间，该超时时间可以设置为比connect阻塞超时时间短），如果select超时，则可以直接关闭socket，然后可以尝试创建新的socket重新连接；如果select返回非阻塞socket描述符可写，则表明连接建立成功；如果select返回非阻塞socket描述符既可读又可写，则表明连接出错。注意，此处必须与另外一种正常连接的情况区分开来，那就是，当连接建立完成之后，服务器发送了数据给客户端。此时select会同时返回非阻塞socket描述符既可读有可写。此时，可以通过以下方法区分：

调用getpeername获取对端的socket地址。如果getpeername返回ENOTCONN，表示连接建立失败，然后用SO_ERROR调用getsockopt得到套接字描述符上的待处理错误；
调用read，读取socket上长度为0字节的数据。如果read调用失败，则表示连接失败，而且read返回的errno指明了连接失败的原因。如果连接建立成功，read应该返回0；
再次调用connect，它应该返回失败。如果错误errno是EISCONN，则表示套接口已经建立连接，而且第一次连接是成功的；否则，连接建立失败。

另外，我们需要注意下面几点：

对于无连接的socket（SOCK_DGRAM），客户端也可以调用connect进行连接，此连接实际上并不建立类似SOCK_STREAM的连接，而是仅仅在本地保存了对端的地址，这样，后续的读写操作可以默认以该对端作为操作对象。
当对端机器Crash或者网络连接被断开（比如路由器不工作、网线断开等），此时发送数据给对端然后读取本端socket会返回ETIMEOUT或者EHOSTUNREACH或者ENETUNREACH（后两个是中间路由器判断服务器主机不可达的情况）。
当对端机器Crash之后又重新启动，然后客户端再向原来的连接发送数据，因为服务器端已经没有原来的连接信息，此时服务器端回送RST给客户端，此时，客户端读本地端口返回ECONNRESET错误。
当服务器所在的进程正常或异常关闭时，会对所有打开的文件描述符进行close，因此，对于连接的socket描述符，则会向对端发送FIN进行正常关闭流程。对端在收到FIN之后端口变得可读，此时读取端口会返回0，表示到了文件结尾（对端不会再发送数据）。
当一端收到RST导致读取socket返回ECONNRESET，此时如果再次调用write发送数据给对端则触发SIGPIPE信号，信号默认终止进程，如果忽略此信号或者从SIGPIPE的信号处理程序返回，则write出错返回EPIPE。
只有当本地端口主动发送消息给对端才能检测出连接异常中断的情况，搭配select进行多路分离的时候，socket收到RST或者FIN的时候，select返回可读（心跳消息就是用于检测连接的状态）。也可以使用socket的KEEPALIVE选项，依赖socket本身侦测socket连接异常中断的情况。

非阻塞socket进行connect的过程：

将打开的socket设为非阻塞，可以用fcntl(socket, F_SETFL, O_NDELAY)完成；
发起connect调用，此时返回-1，但是，errno被设为EINPROGRESS，意即connect仍旧在进行，还没有完成；
将打开的socket添加至select监控的可写集合，如果可写，用getsockopt(socket, SOL_SOCKET, SO_ERROR, &error, sizeof(int))来得到error的值，如果为零，则说明socket connect成功。

二、linux客户端socket非阻塞connect编程

非阻塞模式有三种用途：

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

目前，connect非阻塞编程的普遍思路是：

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

以下实验基于Unix网络编程和网络上给出的普遍示例，在经过大量测试后，发现其中有很多方法，在Linux中，并不适用。

首先填写套接字结构，包括远程IP和通信端口：

struct sockaddr_in serv_addr;
serv_addr.sin_family = AF_INET;
serv_addr.sin_port = htons(12345);
serv_addr.sin_addr.s_addr = inet_addr("127.0.0.1");
bzero(&(serv_addr.sin_zero), 8);

建立socket套接字：

if ((sockfd = socket(AF_INET, SOCK_STREAM, 0)) == -1) {
    perror("Socket create failure.");
    return 1;
}

将socket建立为非阻塞，此时socket被设置为非阻塞模式：

flags = fcntl(sockfd, F_GETFL, 0);
fcntl(sockfd, F_SETFL, flags|O_NONBLOCK);

建立connect连接，此时socket设置为非阻塞，connect调用后，无论连接是否建立，立即返回-1，同时将errno设置为EINPROGRESS，表示此时TCP三次握手仍旧进行，如果errno不是EINPROGRESS，则说明连接错误，程序结束：

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;
    }
}

设置等待时间，使用select函数等待正在后台连接的connect函数，这里需要说明的是使用select监听socket描述符是否可读或者可写，如果只可写，说明连接成功，可以进行下面的操作。如果描述符既可读又可写，分为两种情况，第一种情况是socket连接错误（这是系统规定的，可读可写时可能是connect连接成功后远程主机断开了连接close(socket)），第二种情况是connect连接成功，socket读缓冲区接收到了远程主机发送的数据，需要通过connect连接后返回的errno值来判定，或者通过调用getsockopt(sockfd, SOL_SOCKET, SO_ERROR, &errno, &len)函数返回值来判断是否发生错误，这里存在一个可移植性问题，在Solaris系统中发生错误返回-1，其他系统中可能返回0，Linux中如下：

FD_ZERO(&rset);
FD_SET(sockfd, &rset);
wset = rset;
tval.tv_sec = 0;
tval.tv_usec = 300000;
int error;
sock_len_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, &wset)) {
    len = sizeof(error);
    if (getsockopt(sockfd, SOL_SOCKET, SO_ERROR, &error, &len) < 0) {
        return 1;
    }
}

这里我测试了一下，按照unix网络编程的描述，当网络发生错误的时候，getsockopt返回-1，程序结束。网络正常时，返回0，程序继续执行。

可是我在linux下，无论网络是否发生错误，getsockopt始终返回0，不返回-1，说明linux与unix网络编程还是有些细微的差别。就是说当socket描述符可读可写的时候，这段代码不起作用。不能检测出网络是否出现故障。

我测试的方法是，当调用connect后，sleep(2)休眠2秒，在这两秒时间内，将网络断开并连接，此时select返回2，说明套接口可读又可写，应该是网络连接的出错情况。

此时，getsockopt返回0，不起作用。获取errno的值，指示为EINPROGRESS，没有返回unix网络编程中说的ENOTCONN，EINPROGRESS表示正在试图连接，不能表示网络已经连接失败。

针对这种情况，Unix网络编程中提出了另外三种方法：

再次调用connect一次，失败返回errno是EISCONN，则说明连接成功，表示刚才的connect成功，否则返回失败。

int connect_ok;
connect(sockfd, (struct sockaddr *)&serv_addr, sizeof(struct sockaddr));
switch(errno) {
    case EISCONN:
        printf("Connect OK.");
        connect_ok = 1;
        break;
    default:
        connect_ok = -1;
        break;
}

如程序所示，根据再次调用的errno返回值将connect_ok的值，来进行下面的处理，connect_ok为1继续执行其他操作，否则程序结束。

但这种方法我在linux下测试了，当发生错误的时候，socket描述符变成可读且可写，但第二次调用connect 后，errno并没有返回EISCONN，,也没有返回连接失败的错误，仍旧是EINPROGRESS，而当网络不发生故障的时候，第二次使用 connect连接也返回EINPROGRESS，因此也无法通过再次connect来判断连接是否成功。

Unix网络编程中说明使用read函数，如果失败，表示connect失败，返回的errno指明了失败原因，但这种方法在Linux上行不通，linux在socket描述符为可读可写时，read返回0，并不会置errno为错误。
Unix网络编程中说使用getpeername函数，如果连接失败，调用该函数后，通过errno来判断第一次连接是否成功，但我试过了，无论网络连接是否成功，errno都没变化，都为EINPROGRESS，无法判断。

悲哀啊，即使调用getpeername函数，getsockopt函数仍旧不行。

综上方法，既然都不能确切知道非阻塞connect是否成功，所以我直接当描述符可读可写的情况下进行发送，通过能否获取服务器的返回值来判断是否成功。(如果服务器端的设计不发送数据，那就悲哀了。)

程序的书写形式出于可移植性考虑，按照unix网络编程推荐写法，使用getsocketopt进行判断，但不通过返回值来判断，而通过函数的返回参数来判断。

用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);

来自为知笔记(Wiz)

Socket Connect问题

声明：以上内容来自用户投稿及互联网公开渠道收集整理发布，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任，若内容有误或涉及侵权可进行投诉：投诉/举报工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。

联系
我们

首页 > 代码库 > Socket Connect问题