Peter Samuelson wrote:
> [Bob Denny]
>> Yes, it does need improvement :-) He is correct in his thoughts about
>> subprocesses on windows. Unless the subprocess is poorly written,
>> closing the input handle will make the subprocess ultimately go away.
>
> And yet terminating the TCP connection does not have the same effect on
> the server process? That is to say, when the client is killed,
> shouldn't the OS be responsible for immediately closing the TCP
> session? Are you saying your Windows kernel (I don't remember if you
> mentioned which version of Windows you have) does _not_ do this? That
> sounds to me like a whole other bug - in that Windows kernel.
The problem is that the TCP stack may be unable to detect
a connection drop (on either the client or the server) unless
the application tries to send some data. (This is independent
of the OS; I believe it is an artifact of the way IP works.)
I almost never see this in a LAN environment (the stack tends
to detect connection drops instantaneously), but if a router
is involved, it isn't unusual.
Turning keepalives on for the socket can help this problem,
but generally, keepalives don't kick in until the socket
has been idle for an hour. (So the stack won't detect the
drop for an hour even with keep alives on.)
So if the ssh client doesn't get a chance to do a clean shutdown,
the server may not notice the connection drop for up to an hour.
Now, I don't swear that is what is going on in _this_ case... but
in the general case... this can be a problem.
Thanks,
Joseph
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2410027
Received on 2009-10-22 03:06:30 CEST