Re: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection

Поиск
Список
Период
Сортировка
От kuznet@ms2.inr.ac.ru
Тема Re: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection
Дата
Msg-id 200007041604.UAA25262@ms2.inr.ac.ru
обсуждение исходный текст
Ответ на Re: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: The Hermit Hacker
Дата:
Сообщение: Re: Revised Copyright: is this more palatable?
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: heap_create with OID?