[Bug 217637] One TCP connection accepted TWO times

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637

--- Comment #67 from slw at 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.