| From: | kuznet(at)ms2(dot)inr(dot)ac(dot)ru |
|---|---|
| To: | tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane) |
| Cc: | alan(at)lxorguk(dot)ukuu(dot)org(dot)uk, dyp(at)perchine(dot)com, pgsql-hackers(at)postgresql(dot)org, davem(at)redhat(dot)com |
| Subject: | Re: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection |
| Date: | 2000-07-04 16:04:41 |
| Message-ID: | 200007041604.UAA25262@ms2.inr.ac.ru |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | The Hermit Hacker | 2000-07-04 16:04:55 | Re: [HACKERS] Revised Copyright: is this more palatable? |
| Previous Message | Jan Wieck | 2000-07-04 15:51:14 | Re: Revised Copyright: is this more palatable? |