From: John Mills <johnmills@speakeasy.net>
To: Alok Singh <alok.singh@broadcom.com>
Cc: John Mills <JMills@airdefense.net>,
eCos Users <ecos-discuss@ecos.sourceware.org>
Subject: Re: [ECOS] Re: Network TCP Handler: stale socket disposal
Date: Tue, 25 Sep 2007 14:56:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.44.0709250946540.12695-200000@otter.localdomain> (raw)
In-Reply-To: <E06E3B7BBC07864CADE892DAF1EB0FBD01146A8B@NT-SJCA-0752.brcm.ad.broadcom.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2467 bytes --]
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
[-- Attachment #2: Patch discards stale sockets --]
[-- Type: TEXT/PLAIN, Size: 907 bytes --]
--- /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);
[-- Attachment #3: Type: text/plain, Size: 148 bytes --]
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
next prev parent reply other threads:[~2007-09-25 14:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-25 12:20 Alok Singh
[not found] ` <6F6F9AF887E54B47961CA0F5D1C228D102129720@shake.airdefense.net>
2007-09-25 13:41 ` Alok Singh
2007-09-25 14:56 ` John Mills [this message]
2007-09-28 12:06 ` Alok Singh
2007-09-28 13:31 ` John Mills
2007-10-02 9:15 ` Lars Povlsen
2015-05-11 16:39 Weili Yao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.44.0709250946540.12695-200000@otter.localdomain \
--to=johnmills@speakeasy.net \
--cc=JMills@airdefense.net \
--cc=alok.singh@broadcom.com \
--cc=ecos-discuss@ecos.sourceware.org \
--cc=john.m.mills@alum.mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).