[lwip-users] RE: [lwip] TCP pcb's in ESTABLISHED hang around forever after clo se

[timothy . llewellynn]

This is a multi-part message in MIME format.

------=_NextPartTM-000-71908a8e-de0a-47e4-8035-b62eb2fb224c
Content-Type: text/plain;
        charset="iso-8859-1"

we have a similar problem in PCB's hanging around for quite some time. The
problem from what I see is that
the TIME_WAIT pcb's will only expire when tcp_slowtmr is called. since we
are using lwip in a multi-threaded OS, this will only be called when a new
packet arrives. However if we have a short burst of connections then we will
have alot of PCB's hanging around waiting to be released back into the wild.
However if the traffic stops for a while our TIME_WAIT connections need to
be freed but don't because the tcp_slowtmr is only called when a new packet
arrives. Thus when the new packet arrives it gets processed and since we
have all these TIME_WAIT pcbs we run out of memory. This wouldn't be a
problem if either we had lots of PCB's ie memory and regular traffic,
however for our embedded platform have neither.

Has anyone got some ideas on this? It would be nice to be able to call some
protected cleanup function in the lwip stack from a timer to do cleanup
processing when we are idle. however at the momemnt the tcp_slowtmr function
that does the cleanup now is not protected so if I call this and a packet
arrives I presume very bad things will happen.

Ideas??

Tim

-----Original Message-----
From: Paul Sheer [mailto:address@hidden
Sent: 16 August 2002 23:05
To: address@hidden; address@hidden
Subject: Re: [lwip] TCP pcb's in ESTABLISHED hang around forever after
close



>  
> > currently I am thinking of adding a new structure
> > member pcb->die_timeout. This gives the calling app
> > tighter control. You can set die_timeout at any time
> > you think the tcp connection should *really* not hang
> > around for longer than a given number of seconds.
> 
> It is also possible to use the polling functionality. TCP will poll the
> application with a specific interval when the connection is idle.
> 

in any event I have added this new member, and i'm happy with
the behavior. I think its the clean way to do things.

generally, if you're are paranoid about hanging pcbs (and I am),
then you want to drop any pcb that sits around for too long
without receiving *any* packets.

-paul

Paul Sheer Consulting IT Services . . Tel . . . +27 (0)21 6869634
Email . . . address@hidden . . . . . . Pager . . . 088 0057245
Linux development, cryptography, recruitment,  support,  training
http://www.icon.co.za/~psheer . . . . http://rute.sourceforge.net
L I N U X . . . . . . . . . . . .  The Choice of a GNU Generation

[This message was sent through the lwip discussion list.]

------=_NextPartTM-000-71908a8e-de0a-47e4-8035-b62eb2fb224c
Content-Type: text/plain;
        name="InterScan_Disclaimer.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
        filename="InterScan_Disclaimer.txt"

************************************************************************************
This e-mail message is intended only for the addressee(s) and contains
information which may be confidential. If you are not the intended
recipient please do not read, save, forward, disclose or copy the contents
of this e-mail. If this e-mail has been sent to you in error, please delete 
this 
e-mail and any copies or links to this e-mail completely and immediately
from your system. We also like to inform you that communication via e-mail
over the Internet is insecure because third parties may have the possibility
to access and manipulate e-mails.

Any views expressed in this message are those of the individual sender,
except where the sender specifically states them to be the views of
The Swatch Group Ltd.
************************************************************************************

------=_NextPartTM-000-71908a8e-de0a-47e4-8035-b62eb2fb224c--
[This message was sent through the lwip discussion list.]