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
|
Список | 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 по дате отправления: