| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alan Cox <alan(at)lxorguk(dot)ukuu(dot)org(dot)uk> |
| Cc: | kuznet(at)ms2(dot)inr(dot)ac(dot)ru, dyp(at)perchine(dot)com, pgsql-hackers(at)postgresql(dot)org, davem(at)redhat(dot)com (Dave Miller) |
| Subject: | Re: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection |
| Date: | 2000-07-03 22:52:51 |
| Message-ID: | 24247.962664771@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Alan Cox <alan(at)lxorguk(dot)ukuu(dot)org(dot)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