Date: Sun, 28 Apr 2002 18:07:51 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: net@freebsd.org Cc: dwmalone@maths.tcd.ie Subject: Re: soisdisconnected tweak. Message-ID: <3CCC9CE7.B838EA8C@mindspring.com>
next in thread | raw e-mail | index | archive | help
] When soisdisconnected is called on a socket, the connection is ] marked as broken the socket can't recieve or send any more data. ] As far as I can tell, any data which is queued for output cannot ] be sent, but remains queued in the socket until it is closed. ] ] The patch below makes soisdisconnected drop whatever data is queued, ] so that the mbufs can be reused straight away and you don't have ] to wait for the socket to be closed. A shutdown guarantees that the data is transferred from the socket buf to the TCP buf. The real question here is how you get to the state you claim is happening: the so isdisconnected() should stall the calling process until the data has drained, if this is the case, or it should never get called until the buffer is empty. In general, it's valid to have data sitting there waiting, if the data has been sent, but not acknowledged, since an ACK for a previous segment -- indicating that some of the data was lost in transit -- will trigger a retransmit. The retransmitted data has to come from somewhere, for the TCP close semantics to be correct. So back to the real question: how do you get into a situation where data that is *rightly* never to be transmitted is hung there waiting? I can't see how this can ever legitimately happen. Is this maybe part of the sysctl/tcpcb hack thing? If so, then the correct place to do this is on the sysctl write to get rid of the socket: not in the soisdisconnected() call... in other words, it's a discrete event, and has to be handled as such. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CCC9CE7.B838EA8C>