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

From kuznet@ms2.inr.ac.ru
Subject Re: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection
Date
Msg-id 200007041604.UAA25262@ms2.inr.ac.ru
Whole thread Raw
In response to Re: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hello!

>           <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
> 
>         After sending the acknowledgment, drop the unacceptable segment
>         and return.
> 
> There is no room here for the TCP to decide to send RST instead.

I apologize, but RFC793 is sort of incomplete. Please, look at
errata in RFC1122 and to bug alerts described in documents published
by tcp-impl (draft-tcpimpl-*).


I cited you corresponding paragraph of the RFC in previous mail.
Shortly:

1. When new data arrive after half-duplex close, we must reset.
2. When close occurs on connection, which has unread data, we  must reset.

It is required from the viewpoint of TCP protocol. Any OS, which
forgets to make this is buggy. By the way, I do not know about OSes,
which do not make this.

From the viewpoint of application, the behaviour is also correct.
Data arrived, when nobody plans to read it, unambiguously means
either connection abort or hard bug in application protocol.

Alexey


pgsql-hackers by date:

Previous
From: The Hermit Hacker
Date:
Subject: Re: Revised Copyright: is this more palatable?
Next
From: Bruce Momjian
Date:
Subject: Re: heap_create with OID?