Re: [lwip-users] When the TCP_MSG have been exhausted, it could not be recovered.

[geckook Xu]

> On Wed, 2007-03-21 at 00:01 +0800, geckook Xu wrote:
>
> > I think the CLOSED state is changed after I call tcp_close(pcb), so I
> > add lock at the front and back of tcp_close(), then the assertion
> > about CLOSED didn't appear frequently, but assertion about TIME_WAIT
> > will appear at function tcp_tcp_slowtmr. What is the metter?
>
> It's not sufficient to protect the stack with locks in just a few
> places.  You have to ensure that there are *never* two threads active in
> the lwIP stack at the same time.  You've managed to fix one case, but
> there are many others as you have now seen.

I use the raw api to do these operation. and the tcp_close is called
in callback function of tcp_recv.
Because the raw api is not blocked, so I think they are runing in the
same thread. If not, What's thread they belong to?
I use the raw api to create a listen server ,and make a client
function for connecting to the other station.
the listen and the client are use the same tcp callback functions
except the tcp_accept() and tcp_connected() callback function.
When I create a listen server and in the same time I user the client
function to connect to the other station in other thread, in this
case, are they in the same thread ? (raw api don't block,so I ask) How
can I control the synchronization between my time functions and the
lwip stack?
I have attached my code in this link below, It is an old version, I
only have modified a little in the new version. if needed, I will
attache my new code tomorrow.
http://lists.gnu.org/archive/html/lwip-users/2007-03/msg00123.html


> >
> > > > There are still anothe problem when the tcp_pcb have been exhausted:
> > > > I set TCP_MSG to 255, and when the tcp_pcb are exhausted, it will be
> > > > exhausted too.
> > > > once TCP_MSG have been exhausted,then TCP_MSG values would not be 
> recovered.
> > > > What should I do now?
> > >
> > > I'm not sure I understand your problem?  Are you just running out of
> > > TCP_MSG structures?  Or are they somehow being leaked so that they never
> > > become available for reuse?  Could this be related to BUG#19345 which
> > > Frederic Bernon is working on?
> > >
> > > Kieran
> >
> > Yes, TCP_MSG structures somehow being leaked so that they never become
> > available for reuse.
> > Do you mean I can referer to
> > http://lists.gnu.org/archive/html/lwip-devel/2007-03/msg00242.html ?
>
> Yes.
>
> > I still found another problem about TCP_MSG structures and
> > MEMP_NUM_TCP_SEG structures.
> > in the cc.h file, when I include a new header file,MEMP_NUM_TCP_SEG
> > structures would be leaked and TCP_MSG structures not, but when I
> > remove this header file, the TCP_MSG structures whuld be leaked
> > instead.
>
> That sounds very strange, I'm not sure what's going wrong here.
> However, I wouldn't be surprised if the leaks weren't also caused by the
> problems you have with protecting the stack using locks.  Until you
> solve that problem, everything else that goes wrong is likely to be
> attributed to that.
>
> Kieran