Eygene Ryabinkin wrote:
Julian, good day.
Thu, Jul 19, 2007 at 09:33:28AM -0700, Julian Elischer wrote:
replying to myself.. the comment in the code in question said:
/*-----------------------------------------------------------------*/
/** if the elaborateTCPFin option is set, keeps the socket open
* and drains it until the other side closes it. Solves a problem
* with IE spewing extra client data to a Linux socket, then reporting
* an error in response a TCP reset (rather than FIN) from Linux */
which is EXACTLY the problem I was seeing :-)
I assume that you're talking about Squid code?
no
this is a proprietary cache program..
Do you think that FreeBSD TCP/IP stack should also do something
about this problem? The situation where one side closes the
descriptor while other it still trying to push the data is legal:
for example, one side invokes close() but some data from other side
is in transit, so we will see some unneccessary FIN packets. Or
you believe that fixing this is irrelevant?
I think that the possible courses of action are:
1/ Ignore further incoming data, but ACK it.
(this is basically what the userland code does in this case)
2/ Stop ACKing the data, and let the other end time out.
3/ Send a RST
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
