Date: Mon, 29 Apr 2002 10:06:56 +0100 From: David Malone <dwmalone@maths.tcd.ie> To: Terry Lambert <tlambert2@mindspring.com> Cc: net@freebsd.org Subject: Re: soisdisconnected tweak. Message-ID: <200204291006.aa93819@salmon.maths.tcd.ie> In-Reply-To: Your message of "Sun, 28 Apr 2002 18:07:51 PDT." <3CCC9CE7.B838EA8C@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
I think your fears about data being lost here may be unfounded.
The description of soisdisconnected() says:
... soisdisconnected() is called when the connection to the
peer is totally severed.
This seems to mean that that either the connection has timed out
or has been aborted. I think it should be safe to drop any data
which is waiting to be sent if connection is actually severed.
I've included a list of the places where soisdisconnected is called
from, and they all seem pretty final.
David.
unp_detach
unp_disconnect
raw_uabort
raw_udisconnect
ddp_disconnect
ddp_abort
at_pcbdetach
atm_sock_connect (if connect fails)
ngs_rmnode
div_abort
rip_abort
tcp_input (TCPS_FIN_WAIT_1 && ourfinisacked) || (TCPS_CLOSING && ourfinisacked)
|| (TCPS_FIN_WAIT_2 && FIN)
tcp_close
tcp_usrclosed (and we're in state >= TCPS_FIN_WAIT_2)
udp_abort
rip6_abort
udp6_abort
ipx_abort
ipx_drop
ipx_usr_abort
ipx_disconnect
spx_close
natm_usr_disconnect
natm_usrreq for PRU_DISCONNECT
idp_abort
idp_drop
idp_usrreq for PRU_DISCONNECT and PRU_ABORT
spp_close
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? <200204291006.aa93819>