[ECOS] Re: Network TCP Handler: stale socket disposal

[John Mills]

All -

First, please excuse my attaching a patch here, but I would like to 
respond once (or a few times &8-) in case it's helpful.

Second, my reply to Mr. Singh failed posting because it originated from a 
reader that can't enforce text-only formatting. Sorry.

Third, I post this patch for test and discussion purposes. It seems to 
help in our limited case, but comes with no guarantee. I would appreciate 
hearing others' experience.

Thanks for your patience.

 - John Mills

On Tue, 25 Sep 2007, Alok Singh wrote:

> John,
 
> Please post it in whatever form you deem as appropriate.  Let us know
> when you will be able to post it.
 
> BTW, I'm seeing a similar issue in my application.  Sockets are
> exhausted, and web is not accessible.  Ping is going through. I've kept
> Max. number of sockets as 32 while configuring ecos. The strange thing
> is that the issue comes after a long period of inactivity, i.e., no web
> activity. Â Â 
 
> Your patch will be useful.
 
> Regards,
> Alok  

> ________________________________________
> From: John Mills [mailto:JMills@airdefense.net] 
> Sent: Tuesday, September 25, 2007 6:56 PM
> To: Alok Singh
> Cc: ecos-discuss@ecos.sourceware.org
> Subject: RE: [ECOS] Re: Network TCP Handler: stale socket disposal
 
> All -
 
> I don't believe my patch was ever accepted. The eCos sources carry a
> cautionary note that such a 'hung' socket may have been placed on the
> net stack 'accept' queue, and may be in the process of acceptance by a
> user thread which could then block.
 
> I checked Linux and FreeBSD man pages on this. In Linux the blocked task
> would receive the next such incoming client and be unblocked. This is
> perfect for my application. Neither OpenBSD nor FreeBSD man pages
> address the issue specifically.
 
> I didn't try to replicate the race condition myself.
 
> eCos now uses an older version of the BSD stack, and updating it looks
> significant - well over a month's work, maybe 3 or 4 based on the time
> the original author reported for his port.
 
> The patch solved a show-stopping problem with our application and seems
> to cause no problems, so we're using it. Two other users tried the
> approach and wrote me off-list: in one case it resolved a problem, in
> the other it made no difference (either way, as far as I know). I can
> share the patch on a "no warranty" basis, but would prefer to post it
> appropriately rather than circulating it randomly.
 
> Â - John Mills
-------------- next part --------------
--- /opt/ecos/ecos-2.0/packages/net/bsd_tcpip/v2_0/src/sys/kern/uipc_socket.c	2003-02-12 10:29:52.000000000 -0500
+++ ./uipc_socket.c	2007-08-28 16:11:56.000000000 -0400
@@ -242,6 +246,11 @@
 			TAILQ_REMOVE(&head->so_incomp, so, so_list);
 			head->so_incqlen--;
 		} else if (so->so_state & SS_COMP) {
+			 if((so->so_error == ECONNRESET) ||
+				 (so->so_error == ECONNREFUSED)){ // forced drop if flagged
+				  TAILQ_REMOVE(&head->so_comp, so, so_list);
+				  head->so_qlen--;
+			 } else {
 			/*
 			 * We must not decommission a socket that's
 			 * on the accept(2) queue.  If we do, then
@@ -249,11 +258,13 @@
 			 * that the listening socket was ready.
 			 */
 			return;
+			 }
 		} else {
 			panic("sofree: not queued");
 		}
 		head->so_qlen--;
 		so->so_state &= ~SS_INCOMP;
+		so->so_state &= ~SS_COMP;
 		so->so_head = NULL;
 	}
 	sbrelease(&so->so_snd, so);
-------------- next part --------------
-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss