断开的TCP连接为什么还存在ESTABLISHED？

xujg

我还是坚持自己的看法,以下可以证明我说的"client 在 normal termination 时 server 可以 select() 到"是正确的.

A socket is ready for reading if any of the following four conditions is true:

a.The number of bytes of data in the socket receive buffer is greater than
   or equal to the current size of the low-water mark for the socket receive buffer.
   A read operation on the socket will not block
   and will return a value greater than 0 (i.e., the data that is ready to be read).
   We can set this low-water mark using the SO_RCVLOWAT socket option.
   It defaults to 1 for TCP and UDP sockets.

b.The read half of the connection is closed (i.e., a TCP connection that has received a FIN).
   A read operation on the socket will not block and will return 0 (i.e., EOF).

c.The socket is a listening socket and the number of completed connections is nonzero.
   An accept on the listening socket will normally not block,
   although we will describe a timing condition in Section 16.6 under
   which the accept can block.

d.A socket error is pending. A read operation on the socket will not block
   and will return an error (–1) with errno set to the specific error condition.
   These pending errors can also be fetched and cleared by calling getsockopt
  and specifying the SO_ERROR socket option.

wangshim_

兄弟们，很高兴大家都能发表真诚的意见。我的意见表达的已很清楚。
xujg,你所说的"可以 select() ",以及：
b.The read half of the connection is closed (i.e., a TCP connection that has received a FIN).
   A read operation on the socket will not block and will return 0 (i.e., EOF).
这段英文说的是半关闭状态，在这种状态下，仍然可以读数据，但不可以写数据。
这个就是shutdown与close的区别，一个可以半关闭，一个是4次握手的全关闭。

xiaofei104

原帖由 柳五随风 于 2005-11-7 23:13 发表
除了wang说的部分正确以外,其他全错误.
client端在长连接情况下,如果没有write动作,那么session上没有数据流动,这种情况下,如果client crashed了,那么client 的os没有机会发送FIN报文,server是不知道client出事了 ...

1.你说的如果client crashed了，如果没有write的话，我觉得这种情况是不存在的，如果仅仅一个TCP连接上了，而且client/server端不进行read,write操作应该是不可能的，如果有read,write操作，在你说的情况下server端肯定知道client端断了，这个时候server断必须要close这个连接，在这种情况下最多是半关闭状态，而不应该是establised状态。

柳五随风

xiaofei  看看书先.

xiaofei104

原帖由 柳五随风 于 2005-11-9 22:50 发表
xiaofei  看看书先.

没有必要这样!有什么说的不对的敬请指教!

柳五随风

原帖由 xiaofei104 于 2005-11-10 10:23 发表


没有必要这样!有什么说的不对的敬请指教!

ftp xxx

登录以后啥也别动直接把电源拔了,看看什么情况在说.

xiaofei104

原帖由 柳五随风 于 2005-11-10 10:54 发表



ftp xxx

登录以后啥也别动直接把电源拔了,看看什么情况在说.

我又重新认识了一下这个问题。在这里希望能与大家真诚交流：

1。对于Client / Server模型的应用程序如果Client端在正常情况下断了，如进程关闭，那么服务器端是一定知道的，因为OS会发送FIN。如果Client端应用程序在异常的情况下断了,如：网络断了，机器断电。。。等情况下一般服务器是不知道Client端出了问题的，所以这个时候服务器端的socket还是established状态,在这种情况下服务器socket只有依赖socket timeout机制，或者socket keepalive检查，不过keepalive无法在程序中控制发送频率，默认情况是2个小时。如果要改需要修改操作系统相关参数。

2。这个帖子与我遇到的问题，都是Client在正常关闭（就是Client进程结束的情况。）而非异常关闭的情况下发现服务器的socket还是established状态这一现象表示不理解？所以希望与大家一起讨论。


对于以上两点非常希望与大家交流，如果有什么不对的希望大家指正，不过我更希望大家能够一起来研究一下我所讲到的第二点。

[ 本帖最后由 xiaofei104 于 2005-11-10 23:54 编辑 ]

xujg

我已经一再说明我所说的是"client 在 normal termination"时的情况
可是为什么一直有人要以网络断或者机器断电的情况来说明我的说法是错误的呢
LZ遇到的问题不是在client正常退出的情况吗?

原帖由 zhanghua111 于 2005-11-5 22:07 发表
最近在linux下写了个http代理程序，代理是通过多线程实现的，后来进行压力测试后发现，客户端已经断开了所有的连接，但是在代理的机器上用netstat还能看到ESTABLISHED状态的连接存在，而且一些子线程也没有正常退 ...

[ 本帖最后由 xujg 于 2005-11-11 08:49 编辑 ]

柳五随风

你怎么知道client是正常退出的?
client程序正常退出不代表client和server的拆会话的4步结束了.看看书再
client退出后,立即查看其socket状态,看看它什么状态.
我觉得很有可能是网络抖动引起的问题,比如线上噪音过大.

xiaofei104

原帖由 柳五随风 于 2005-11-11 11:34 发表
你怎么知道client是正常退出的?
client程序正常退出不代表client和server的拆会话的4步结束了.看看书再
client退出后,立即查看其socket状态,看看它什么状态.
我觉得很有可能是网络抖动引起的问题,比如线上 ...

我不很明确表示了吗？我的正常退出是指进程被用户用窗口右上方的Close按纽关闭，或是被kill pid给干了。在这种情况下操作系统应该给服务器发FIN来结束的。而且我们在这里的问题也很明确了提出对于这种情况下的现象表示不理解？为什么你总是说异常退出的情况。

而且通过同一种方式关闭客户端进程的时候，有时候TCP连接断了，而有时候又没有断。所以对此表示奇怪。希望你不要总是纠缠在没有意义的问题上。

http://bbs.chinaunix.net/viewthr ... ge=1&highlight=

[ 本帖最后由 xiaofei104 于 2005-11-11 11:46 编辑 ]