困惑：socket通信使用阻塞模式，一旦对端进程崩溃或关闭连接，recv不能马上返回值吗？

hisense0709

以下实验在windows下作，

      实验一：网上有种说法：“阻塞模式下直接使用套接字接收或者发送，如果通信的对端关闭连接或者对端进程崩溃，则这边的recv函数就会长时间不返回值
”，但是我实际编了个程序测试了阻塞模式下的recv，发现在对端关闭连接就马上返回0，如果对端进程崩溃，则recv马上返回  < 0; 而且都是立即就能返回，
     实验二：拔网线断网，如果建立的长连接，分拨的是自己机子的网线还是拔得是对端的网线两种情况，仅仅把自己的机子网线拔掉，自己机子的recv需要几秒钟能返回，无论是select模式还是阻塞模式都是如此， 仅仅拔掉远端机子的网线，本机这端的网线不动，则本机的recv套接子，无论是select还是阻塞模式，都无法感知远端网线是否拔掉，拔对端的网线，得靠对端自己的recv，能在几秒钟后感知，本地机子不可能感知远端的网线拔掉，这个和远端程序崩溃不一样，远端程序崩溃，本地机子recv马上就能返回，无论是select还是阻塞模式,我做实验得出的结论

我的结论： 1 我觉得所谓”阻塞模式下直接使用套接字接收，一旦通信对方关闭或者进程崩溃，不能马上返回对端这些异常，只有selcet模式可以马上返回异常，“这说法是错误的！两者都可以 马上返回值，但两种方式都不能感受到远端的网线是否拔掉，两者都可以在自己机子的网线拔掉后几秒钟感知到
           结论2 ：一个套接字情况下，select模式和直接阻塞模式使用套接字相比，优势只体现在select是异步模式，可以发，收分开，而直接阻塞模式，如果要一问一答，则只能同步，即：发完后等到对方应答后才能再发。对“马上感知对端通信异常（指对端套接字关闭，对端进程崩溃）”而言， 两者效果一样！（当然，如果通信双方使用>=2个的套接子通信，select还是比仅仅使用两个都阻塞模式的套接字的优势多了起来，不再赘述）

请高人指教，我上述两点是否正确？多谢！

csumck

这跟是否阻塞一点关系都没有。 程序崩溃，操作系统会负责发送Rst包的，另一端是能够立刻感知的。 中间网络设备断掉是没有感知的，TCP层是靠KEEP_ALIVE包检查连接状态，linux上默认是两小时发送一次。应用层自己加心跳。

hisense0709

楼上高人多谢指点！！！但你说的“中间网络设备断掉是没有感知的，”， 但是我发现“把自己的机子网线拔掉，自己机子的recv只要几秒钟感知到能返回，无论是select模式还是阻塞模式都是如此，”， 自己的机子的网线，似乎应该是中间网络设备呀，所以，你说的是否不严谨？

linux_c_py_php

网络环境复杂, TCP协议只是两个端自己维护的一个状态, 如果不去验证链路是否通常, 那么网线拔了之类的肯定是不知道的.

folklore

>> 本地机子recv马上就能返回，无论是select还是阻塞模式,
<<　这个要看对方的实现，　一般OS会给程序做收尾工作。

>> 但是我发现“把自己的机子网线拔掉，自己机子的recv只要几秒钟感知到能返回
<< 本机能够很快检测到自已网络不通， 但远端因为网络状况不同， 无法预测廷迟时间， 只能等最大超时。

myworkstation

回复 3# hisense0709


    他说的情况比较有代表性的是路由环节，尤其是公网的路由，当某个节点路出现问题时路由器会自己切换到其它路由上，此时通信的双方并不知道某个节点路由出了问题，你拔掉网线只能说明通信的端点上出现问题。

csumck

回复 3# hisense0709


    应该是操作系统感知，然后通知进程了。

kdkgod

@linux_c_py_php仁兄是不是开发游戏的，石器的代码如何看才能入手，请指教