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/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- 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 appli= cation > 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 we= nt wrong. > I guess this is what we might no agree upon.=20 > However this is the reason why the server sends a RST without trying to r= etransmit > 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=3DFIN.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) a= fter client acknowledged server data? --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-217637-2472-sknliL2N02>