https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637
--- Comment #67 from s...@zxy.spb.ru --- (In reply to Michael Tuexen from comment #66) > No, the loss of data is caused by the application calling close() *before* > incoming user data arrived. Loss of sended application data caused by close() before incoming user data arrived? Realy? TCP don't have such claim. > So the TCP stack on the server has to drop that user data. No problem. This is not application data. > Sure. This is what the application triggers. However, when user data arrives > after > the close call, this gets ungraceful, since this user data can't be delivered > to > the user anymore. I am not afraid about user data, I am afraid about server data. Server data lost and this is problem. No problem about lose user data. > I don't see text in RFC 793, where it is required that you continue to process > a connection after you know that it failed. What reason to failed connection? > I think the RFC doesn't cover the case > where the application says "I don't want to receive anymore". Yes, RFC says all CLOSE is 'means "I have no more to send" but does not mean "I will not receive any more."' I mean "Thus, it should be acceptable to make several SEND calls, followed by a CLOSE, and expect all the data to be sent to the destination." have precendece over all. "Reset Generation" allow generation RST from ESTABLISHED/FIN-WAIT-1/fIN-WAIT-2 state only "If an incoming segment has a security level, or compartment, or precedence which does not exactly match the level" Also, "3.9. Event Processing", "SEGMENT ARRIVES" don't generate RST in ESTABLISHED/FIN-WAIT-1/FIN-WAIT-2 STATE. I mean conection not in failed state until all server data and FIN will be ACKed. Or at timeout. After this, connection may be moved to failed state. Not until. PS: May proposal resolve next issuse: 1. server response not lost any more 2. client see valid replay from server, not just 'connection droped' 3. late segments from client don't mach syn-cookei and don't re-open connection 4. no new restrictions for first segment syn cookie processing 5. client side of connection clearly closed (currently generated RST w/o ACK ignored by all clients except FreeBSD. this is another bug) 6. this is compatible w/ existing applications -- 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"
