close套接字后继续accept返回的套接字值不是刚关闭的描述符的值

Gnixfeng

如题，我使用线程池+epoll做了一个服务器端。
    客户请求连接，accept返回一个套接字值为13，加入epoll监听，客户请求到来epoll返回事件，服务器处理完后将结果写入套接字13，线程继续等待请求到来。直到当客户请求下线后服务器端调用close关闭套接字13，服务器继续等待。接着第二个客户链接到来时，accept返回一个套接字值为14，然后如上继续处理返回，最后调用close关闭。然后不断重复，套接字值不断自增1！试验环境都是同时只有一个客户端连接服务器的。
    问题就是为什么系统没有立即重用刚关闭的套接字，而如果没有客户端连接的情况下，让服务器端静止1分钟左右，在让客户端发起一个连接，这时返回的套接字值是13，然后如果继续前述的操作结果也是套接字值自增。
    但是，
    我在另一个试验中使用只使用线程池没有使用epoll，当我使用一个客户端不断发起一个连接请求，服务器端处理后返回给客户端，然后服务器关闭该连接，客户端接着发起连接。此时系统却可以
很快的马上使用刚关闭的套接字（从套接字的值来看，即值相等的套接字）。不会出现不断自增的情况。

    这是为什么呢?如何避免显式关闭套接字后accept返回的套接字值自增，而不是重新利用刚关闭的套接字？

Gnixfeng

顶下！顶下！

cqw_cu_

1.你应该认真看看TCP/IP协议的理论基础，主动关闭和被动关闭经历哪些过程。
2.这跟你用不用epoll没有关系，如果服务器关闭了连接，而且客户端recv返回0，也关闭连接，那么就可以立刻重用，如果只是单方面的行为，那么就会出现你上面说的情况。
3.网络服务编程的原则性问题，一般服务器不要主动立刻去关闭连接，而是用定时器来处理，建议看看Nginx的处理。

cqw_cu_

1.你应该认真看看TCP/IP协议的理论基础，主动关闭和被动关闭经历哪些过程。
2.这跟你用不用epoll没有关系，如果服务器关闭了连接，而且客户端recv返回0，也关闭连接，那么就可以立刻重用，如果只是单方面的行为，那么就会出现你上面说的情况。
3.网络服务编程的原则性问题，一般服务器不要主动立刻去关闭连接，而是用定时器来处理，建议看看Nginx的处理。