connect()、accept() 和 select() 发生顺序

Question

我是C新手，

刚注意到客户端的connect()函数只要TCP三向hand-抖完了。我的意思是 connect() 甚至可以在调用服务器端的 accept() 之前返回(如果我错了请纠正我)。

基于这些知识，我的问题是，当我之后在客户端调用 select() 并观察文件描述符以等待它可写时， select() 成功返回，也就是说服务器端已经调用了accept()，现在我可以安全地向服务器端写入了，对吧？非常感谢您的宝贵时间。

int flags = fcntl(fd, F_GETFL);

flags |= O_NONBLOCK;

fcntl(fd, F_SETFL, flags);

if (connect(fd, (struct sockaddr *)saptr, salen) < 0)
{
    if (errno != EINPROGRESS)
        /* error_return */
}

fd_set set;
FD_ZERO (&set);

FD_SET (fd, &set);

select (FD_SETSIZE, NULL, &set, NULL, &timeout)
/* Here, if select returns 1, that means accept() is already called 
   on the server side, and now I can safely write to the server, right? */

Answer 1

when select() successfully returns, that means the server side has already called accept()

不，不一定。 connect() 在连接尝试完成时返回，无论是成功还是失败。在远程端，这是由网络堆栈处理的，在任何应用程序的上下文之外。随后的 accept() 本身不会产生额外的通信。

and now I can safely write to the server side, right?

“安全”可以指各种各样的事情，但是如果您的意思是本地端可以在不阻塞的情况下至少写入一个字节，那么是的，select() 向您保证。无论您成功写入什么，都将通过线路发送到远程端。它可能会在那里缓冲一段时间，具体取决于远程端软件的行为。该软件是否已accept()连接与该问题没有直接关系。

更新:另请注意，网络堆栈维护一个已建立连接的每个套接字队列，这些连接尚未被accept()ed(其积压)。这种排队行为是服务器可能不会在建立连接后立即accept() 连接的原因之一，尤其是在重负载下。