Date: Mon, 20 Mar 2017 15:58:57 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Message-ID: <bug-217637-2472-sknliL2N02@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-217637-2472@https.bugs.freebsd.org/bugzilla/> References: <bug-217637-2472@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #61 from slw@zxy.spb.ru --- (In reply to Michael Tuexen from comment #60) > Well, the server knows that he has to drop incoming data, since the application > has closed the socket and there is new data to deliver. I guess we agree on that. Agree. > The reaction is to let the peer now as soon as possible that something went wrong. > I guess this is what we might no agree upon. > However this is the reason why the server sends a RST without trying to retransmit > data he has sent but which has not been acknowledged by the peer. Now server have several task: 1. retransmit his response and (optional) FIN 2. let the peer that something went wrong. I am don't see ideal answer to this. Send RST now may be don't allow to be sure about acknowledged server data. Not sure. Need some tests: retransmit data, retransmit FIN, send RST+ACK, SEQ=FIN.SEQ+1, see reaction from remote: got ACK to data? got ack to FIN? In any cases retransmit is mandatory, by RFC. Some tricks to discard client data may be used here (zero window? silent discard and only SEQ/ACK analize? ACk and discard? send RST+ACK (as you see, RST w/o ACK ignored by client) after client acknowledged server data? -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-217637-2472-sknliL2N02>