Re: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection
Date
Msg-id 24247.962664771@sss.pgh.pa.us
Whole thread Raw
In response to Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection  (Denis Perchine <dyp@perchine.com>)
Responses Re: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection  (Alan Cox <alan@lxorguk.ukuu.org.uk>)
List pgsql-hackers
Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
>> 3.  If the connection is in a synchronized state (ESTABLISHED,
>> FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT),
>> any unacceptable segment (out of window sequence number or
>> unacceptible acknowledgment number) must elicit only an empty
>> acknowledgment segment containing the current send-sequence number
>> and an acknowledgment indicating the next sequence number expected
>> to be received, and the connection remains in the same state.

> Reread the 3. above. What it actually requires if you think about it is that
> the receive window is shrunk to zero and the connection hangs for all
> eternity the way you are arguing it.

No, it doesn't "hang for all eternity", it sits in the same state until
(a) the client side closes its sending side of the connection (ie, sends
FIN), or (b) the FIN-WAIT-1 state times out.  But given a normally
responsive client and no loss of physical connectivity or crash of
either TCP stack, there is no connection reset and no failure to deliver
sent data.

There would be no need for all the half-open-connection verbiage if the
spec were meant to be read the way you are reading it.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection
Next
From: Paul Caskey
Date:
Subject: Re: 64-bit sequences