Will the real sqUnixSocket.c step forward?

Ian Piumarta ian.piumarta at inria.fr
Sat May 4 19:08:41 UTC 2002


On Sat, 4 May 2002, John M McIntosh wrote:
> What you believe the man pages?

Sometimes. ;)  The only place NetBSD returns ECONNABORTED during
accept() is in /sys/kern/uipc_syscalls.c:sys_accept()

		if (so->so_state & SS_CANTRCVMORE) {
			so->so_error = ECONNABORTED;
			break;

SS_CANTRCVMORE is set after reception of a FIN packet (which implies an
already established connection, so this can't happen in accept) or when
the socket is explicily closed, rflushed or shutdown on the server side.  
So, as I understand it, with the current Squeak socket code (which never
tries to accept on a closed socket), ECONNABORTED cannot occur during
accept() on NetBSD.

> The notes I've seen imply the socket can get disconnected somewhere
> between the connect, and the accept. So a somewhat new FREEBSD
> behavior is to throw the ECONNABORTED.

NetBSD handles this by quietly dropping timed-out SYNs from the cache,
without informing the listening socket.  (The logic is distributed in
various parts of netinet/tcp_input.c.)  The new acceptHandler code (which
ignores ECONNABORTED) just implements the same policy of ignoring
timed-out incoming connections.  (The only difference is that now they are
ignored in user-space too, for the benefit of FreeBSD-like kernels that
choose to report them.)

> Well I didn't check, but does it imply the waitforconnection will 
> terminate right away or do we wait for the timeout? Then again I 
> didn't notice any pauses so is that ECONNABORTED connection just 
> ignored? (yes I think)

It is just ignored.  The listening socket is still listening for
connections and queueing them (assuming the backlog is large enough), so
the next time through select() they'll be accepted.  Besides, the
connection abort was not our fault so what's the interest in trying to
deal with it?  The kernel does the right thing (the connection is off the
queue and the listener is still listening), so we can just ignore it.

> I'll await your code. Sometime in the next 24 hours I'll review all 
> the signaling to understand how/what/where

I'll send you a .tgz in a while (when I've finished fixing a few things in
sqXWin).

Ian





More information about the Squeak-dev mailing list