EEPW论坛

listen函数使用主动连接套接口变为被连接套接口，使得一个进程可以接受其它进程的请求，从而成为一个服务器进程。在TCP服务器编程中listen函数把进程变为一个服务器，并指定相应的套接字变为被动连接。

listen函数在一般在调用bind之后-调用accept之前调用，它的函数原型是：

• 参数sockfd

• 被listen函数作用的套接字，sockfd之前由socket函数返回。在被socket函数返回的套接字fd之时，它是一个主动连接的套接字，也就是此时系统假设用户会对这个套接字调用connect函数，期待它主动与其它进程连接，然后在服务器编程中，用户希望这个套接字可以接受外来的连接请求，也就是被动等待用户来连接。由于系统默认时认为一个套接字是主动连接的，所以需要通过某种方式来告诉系统，用户进程通过系统调用listen来完成这件事。
  

• 
  

• 参数backlog

• 这个参数涉及到一些网络的细节。在进程正理一个一个连接请求的时候，可能还存在其它的连接请求。因为TCP连接是一个过程，所以可能存在一种半连接的状态，有时由于同时尝试连接的用户过多，使得服务器进程无法快速地完成连接请求。如果这个情况出现了，服务器进程希望内核如何处理呢？内核会在自己的进程空间里维护一个队列以跟踪这些完成的连接但服务器进程还没有接手处理或正在进行的连接，这样的一个队列内核不可能让其任意大，所以必须有一个大小的上限。这个backlog告诉内核使用这个数值作为上限。

• 毫无疑问，服务器进程不能随便指定一个数值，内核有一个许可的范围。这个范围是实现相关的。很难有某种统一，一般这个值会小30以内。

当调用listen之后，服务器进程就可以调用accept来接受一个外来的请求。关于accept更的信息，请接着关注本系统文章。

下面是来自于（http://blog.csdn.net/forrest_chen/article/details/7021409）的一段话：

TCP的服务器端socket基本流程socket->bind->listen->accept->send/recv->closesocket，客户端基本流程socket->[bind->]->connect->send/recv->closesocket，其中客户端connect函数应该是和服务器端的listen函数相互作用，而不是accept函数。在listen函数中的第二个参数backlog代表着等待处理的连接队列（以下简称队列）的长度，神马意思？我也不太懂，但是通过代码实践，我可以简单的说，每当有一个客户端connect了，listen的队列中就加入一个连接，每当服务器端accept了，就从listen的队列中取出一个连接，转成一个专门用来传输数据的socket（accept函数的返回值），所以在服务器端程序中有两个socket，前者是用来接收客户端连接的socket...