https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637
--- Comment #61 from s...@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. _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
