socket中accept的时候能不能设置时间限制

cookis

当只收到SYN 而没有ACK 就死等吧..

lanying_wzw

在 block io 上用 select，很危险……

确实，在accept上应该用非阻塞IO，因为，有可能客户建立连接后马上发个RST，这样连接撤销，虽然select()返回可读，但是你accept()的时候就会阻塞，因为连接已经撤销了。
还有，在带超时的connect()上要用非阻塞，为了发SYN。
别的情况用不用非阻塞得看实际情况，所以select()上用不用非阻塞，得看你的需求和对系统的掌握情况，至于危险不危险。
呵呵，艺高人胆大！

cookis

原帖由 lanying_wzw 于 2008-6-16 19:37 发表

确实，在accept上应该用非阻塞IO，因为，有可能客户建立连接后马上发个RST，这样连接撤销，虽然select()返回可读，但是你accept()的时候就会阻塞，因为连接已经撤销了。

答案是对的?  解释好像有点儿问题吧..
客户端发RST也会造成可读事件的..

yulc

"
确实，在accept上应该用非阻塞IO，因为，有可能客户建立连接后马上发个RST，这样连接撤销，虽然select()返回可读，但是你accept()的时候就会阻塞，因为连接已经撤销了。
"


果然,以上结论在linux 平台下是错误的.
我进行了测试:
测试平台是2.6.18内核的centos5.

当客户建立连接后马上发RST包,服务器然后再调用accept(我的测试方法是accept前进行sleep), 依然会返回一个正确的socket句柄,并且会认为其可读,但在读取时,会得到一个104 (#define ECONNRESET  104 /* Connection reset by peer */ )  的错误.

我觉得这符合linux下tcp协议栈实现:
tcp的三次握手是在accept返回前就完成的,accept仅仅是返回这个一个句柄而已.虽然客户端在此之前RST,但实际上连接曾经建立过,所以accept依然会返回.其后再返回此socket可读(被重置或被断开)

yulc

原帖由 cookis 于 2008-6-16 15:04 发表
当只收到SYN 而没有ACK 就死等吧..

你说的是TCP三次握手时, 第三次客户端不发ACK吧, 怎么模拟这种情况 ?
我认为服务器端遇到此情况时, select根本不会返回有新的事件.因为连接还没有完成嘛.

cookis

对呀.. 就因为这种异常导致的连接始终完成不了..所以我们就不能用阻塞形式的.死等了.

flw

原帖由 leeews 于 2008-6-16 14:26 发表

可否讲解下如何危险？

其实我也不懂。我只是从语义的角度分析。
事实上，很多问题都可以这样分析，只不过 C 程序员太执着于实现了。

yulc

原帖由 cookis 于 2008-6-17 16:49 发表
对呀.. 就因为这种异常导致的连接始终完成不了..所以我们就不能用阻塞形式的.死等了.

不对呀,这种异常的连接完成不了(tcp握手没有完成),协议栈是不会报告给应用程序的,
也就是说你在应用程序中的select是不会返回socket有读事件的,也就是不会进入到 accept() 死等中....

所以, 你的这个论据不能证明 "阻塞情况下accept()是危险的."

[ 本帖最后由 yulc 于 2008-6-18 11:52 编辑 ]

CUDev

accept系统调用的时候，三次握手已经完成，accept只是从已经建立的连接列表中取一个连接。而linux的协议栈在accept前，收到RST没有check一下对应的socket的accept队列，这就是问题的原因。

lanying_wzw

同意楼上，我的意思是select返回可读之后，在accept之前，收到RST。
再就是select返回可写之后，最好用非阻塞，因为像管道之类的，在快写满的时候，select是返回可写的，但要写的数据字节数超过管道剩余大小，write()会阻塞的。