原帖由 xiaofei104 于 2005-11-11 11:45 发表
我不很明确表示了吗？我的正常退出是指进程被用户用窗口右上方的Close按纽关闭，或是被kill pid给干了。在这种情况下操作系统应该给服务器发FIN来结束的。而且我们在这里的问题也很明确了提出对于这种情况下的 ...
说明你看不懂我在说什么.完成了4步close,server上能不正常?奇怪的很呢.
在这种情况下操作系统应该给服务器发FIN来结束的。
---失败了怎么办?超过N次失败呢?
如果你的问题发生的很频繁,用类似tcpdump这样的东西把你的packet记录下来,看看到底协议怎么走的(client/server都要).
我在重复一遍,我不认为你说的是对的.至于纠缠,呵呵,恐怕你也是太托大了.
原帖由 柳五随风 于 2005-11-11 12:06 发表
说明你看不懂我在说什么.完成了4步close,server上能不正常?奇怪的很呢.
在这种情况下操作系统应该给服务器发FIN来结束的。
---失败了怎么办?超过N次失败呢?
如果你的问题发生的很频繁,用类似tcpdump这样 ...
我可以明确的告诉你,在异常的情况下是没有发送FIN的,关键是为什么操作系统在采取同样的方式关闭进程的时候有着不同的反映,有时候发送FIN,有时候却没有发送.
我的程序也遇到了这种情况，client都已经关机再次重启了，但是上次的tcp连接仍然在“ESTABLISHED”状态，时间过去一年了，看大家吵架仍然很有意思，问题也没有解决。
我想解释下上面大家吵来吵去3次4次握手的问题。除了在拔网线和异常掉电以及动态修改本机IP这三种情况外（如有遗漏请指正），client应用程序的关闭，必然会造成server感知到网络断开的，因为程序关闭，操作系统会释放其占用的文件句柄。
xiaofei104的问题必然不是正常程序关闭造成的，大家首先应该把各自判断的依据弄准确才好。另外，“断开的tcp连接仍然ESTABLISHED”这个问题我还没有解决，打算用client的唯一标识来解决。。。
我也在压力测试的时候碰上过这个问题。
测试场景：同时建立500个连接；client突然断链。会发现，server会有部分连接未断。
在服务端/客户端同时抓包，会发现有些连接，在client抓的包显示已经发送fin包了，但是在server端却没有收到fin。
所以，我觉得，可能是fin包丢失了（因为同时处理这么多tcp_close？）
规避方案：加心跳。心跳，就可以发现连接是否正常。
正常,linux下,都是要自己发送心跳来检测是否真的连接正常