RE: [lwip-users] Releasing pcb after tcp_new()

[Bill Auerbach]

Simon,

Yes, it is - I wasn't sure until the socket is closed that I can release
that memory.  I'm running a stream connection similar to httpserver_raw
implementation.  So if the amount left to send in the sent callback is 0, I
can safely free the memory used and then close the socket?

Running code similar to that, I'm seeing a leak of MEMP_TCP_PCB_LISTEN pcbs,
2 at a time (because I connect for the HTTP 'GET /' and then again for HTTP
'GET /image.jpg'.  I'll do more debugging to be sure it's not me and let you
know if I can reproduce this or not.

Thanks,
Bill Auerbach
 
> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On Behalf
> Of address@hidden
> Sent: Wednesday, January 09, 2008 2:17 PM
> To: Mailing list for lwIP users
> Subject: Re: [lwip-users] Releasing pcb after tcp_new()
> 
> Bill,
> 
> isn't the sent callback enough to keep track of data that is sent
> successfully? Other than that, data should be deallocated when calling
> tcp_close(), which results in deleting the pcb sooner or later...
> 
> Rick,
> 
> the solution to deallocate the pcb is simply calling tcp_close() for
> that pcb. Based on the state of the pcb, it will be deallocated
> instantly or go through some wait states. But it will eventually get
> deallocated. When bind fails, the pcb should be in CLOSED state and
> should be deallocated right away. But what you say sounds kind of wrong
> - that you couldn't create a second listening connection after closing
> the first... I'll try to check that in the code.
> 
> Simon
> 
> 
> Bill Auerbach schrieb:
> >
> > Rick,
> >
> > We're going down the same path, more or less. One thing to watch on
> > tcp_close is the tcb_pcb isn't actually finished being used until
> > later - one of the tcp timers is completing the connection. This ties
> > up pcbs internally for older connections until they are closed.
> > Allocate MEMP_NUM_TCP_PCB to twice what you think - or more if you are
> > opening and closing connections a lot.
> >
> > One thing I would like to see is a callback when the pcb is going to
> > be deallocated so that dynamic memory associated with it can be
> > released when the data is sent and the connection completes later.
> > Maybe someone knows already how to do this?
> >
> > Thanks,
> >
> > Bill Auerbach
> >
> > ------------------------------------------------------------------------
> >
> > *From:* address@hidden
> > [mailto:address@hidden *On
> > Behalf Of *Rick Culver
> > *Sent:* Wednesday, January 09, 2008 12:29 PM
> > *To:* address@hidden
> > *Subject:* [lwip-users] Releasing pcb after tcp_new()
> >
> > I am using CALLBACK API and set up a pcb using tcp_new() followed by
> > tcp_bind() followed by tcp_listen() & tcp_accept(). In my accept() for
> > a valid connection I use tcp_close() to close the LISTEN connection to
> > avoid any additional connection requests for a new connection. When I
> > am done using the connection I use tcp_close() to shut it down and
> > then repeat the process with tcp_new() to start a new LISTEN port. My
> > problem is 2 fold.
> >
> > First I find that the 2nd time through the tcp_bind() function I get
> > an ERR_USE return which appears to be caused by the active list of pcb
> > still having the old port number in it. I think ther is a problem with
> > tcp_bind() which causes this to happen.
> >
> > Secondly (and the biggest problem) is that once I get the ERR_USE then
> > I have a pcb allocated and this consumes pcb space and I eventually
> > run out of space. So the question is, if I get an error with
> > tcp_bind() how can I release the pcb allocated by the tcp_new() so I
> > do not consume pcb memory space and fill it up. I think there could be
> > a problem with tcp_bind() giving this error which is also an issue.
> > Can anyone suggest how to approach these problems?
> >
> > Rick
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > lwip-users mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/lwip-users
> 
> 
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users