[lwip-users] Freeing all pbufs on tcp_abort()

[JM]

What is the proper way to close a connection and free all resources, namely pbufs, associated with it?  In my application, I have to use tcp_abort to end the connection.  (I do indeed have to send a RST; Winamp does the same thing with streaming audio and I'm emulating that). 

I can connect to to a host and receive data fine, but when I end that connection and initiate a different connection, my debug output occasionally indicates I'm out of MEMP_POOL.  However, if I reset the micro and connect to any host, I do not get any out of memory errors.  This tells me one or more pbufs are not being freed when I end a connection.  Is there a way to free all pbufs, or check which ones are being used? 

[g***@gmx.de]

Post by JM
What is the proper way to close a connection and free all resources,
namely pbufs, associated with it? In my application, I have to use
tcp_abort to end the connection. (I do indeed have to send a RST;
Winamp does the same thing with streaming audio and I'm emulating that).
I can connect to to a host and receive data fine, but when I end that
connection and initiate a different connection, my debug output
occasionally indicates I'm out of MEMP_POOL.

"Out of MEMP_POOL" can mean anything. You need to know exactly which
pool and see if it is really the pbufs you are running out of. But I'd
rather guess it's the tcp_pcb-pool: aborted pcbs are put on the
time-wait list. If you then open a new connection, you will eventually
run out of tcp_pcbs. However, that's not a fatal warning as the tcp code
then frees the oldest pcb in time-wait and uses it. You should check the
stats (or use the prin_stats function) to see which memp pool was emtpy.

Simon

[JM]

I don't recall the exact error, but I have seen the error indicating it's out of tcp_pcbs and it's not that one.  I do know however that it is complaining about being out of pbufs, and it appears occasionally and randomly while it's receiving data.  The stats also show I exceed pbufs in this circumstance. 

--- On Tue, 9/1/09, ***@gmx.de <***@gmx.de> wrote:

From: ***@gmx.de <***@gmx.de>
Subject: Re: [lwip-users] Freeing all pbufs on tcp_abort()
To: "Mailing list for lwIP users" <lwip-***@nongnu.org>
Date: Tuesday, September 1, 2009, 11:45 AM

Post by JM
What is the proper way to close a connection and free all resources, namely pbufs, associated with it?  In my application, I have to use tcp_abort to end the connection.  (I do indeed have to send a RST; Winamp does the same thing with streaming audio and I'm emulating that).
I can connect to to a host and receive data fine, but when I end that connection and initiate a different connection, my debug output occasionally indicates I'm out of MEMP_POOL.

"Out of MEMP_POOL" can mean anything. You need to know exactly which pool and see if it is really the pbufs you are running out of. But I'd rather guess it's the tcp_pcb-pool: aborted pcbs are put on the time-wait list. If you then open a new connection, you will eventually run out of tcp_pcbs. However, that's not a fatal warning as the tcp code then frees the oldest pcb in time-wait and uses it. You should check the stats (or use the prin_stats function) to see which memp pool was emtpy.

Simon

[Kieran Mansley]

Post by JM
I don't recall the exact error, but I have seen the error indicating
it's out of tcp_pcbs and it's not that one. I do know however that it
is complaining about being out of pbufs, and it appears occasionally
and randomly while it's receiving data. The stats also show I exceed
pbufs in this circumstance.

tcp_abort() should, I think, release all the pbufs in use by that
connection. I guess if you're in the middle of receiving a stream of
data you might continue to get packets (which will consume pbufs for a
short while until they are dropped) until the other end spots your reset
and stops sending to you.

Kieran

[Bill Auerbach]

Post by Kieran Mansley
tcp_abort() should, I think, release all the pbufs in use by that
connection. I guess if you're in the middle of receiving a stream of
data you might continue to get packets (which will consume pbufs for a
short while until they are dropped) until the other end spots your reset
and stops sending to you.

A problem I had with trying to use tcp_abort to do the same thing as the OP
in that the listening pcb stopped listening. So a reconnect from the peer
was ignored. I too wanted to abort the connection but not lose the ability
to reconnect to the device.

Bill

[Kieran Mansley]

Post by Bill Auerbach

Post by Kieran Mansley
tcp_abort() should, I think, release all the pbufs in use by that
connection. I guess if you're in the middle of receiving a stream of
data you might continue to get packets (which will consume pbufs for a
short while until they are dropped) until the other end spots your reset
and stops sending to you.

A problem I had with trying to use tcp_abort to do the same thing as the OP
in that the listening pcb stopped listening. So a reconnect from the peer
was ignored. I too wanted to abort the connection but not lose the ability
to reconnect to the device.

If you tcp_abort() the data PCB that you get once the connection is
established it should not affect the listening PCB. If it does, that's
a bug.

Kieran

[Bill Auerbach]

Post by Kieran Mansley
If you tcp_abort() the data PCB that you get once the connection is
established it should not affect the listening PCB. If it does, that's
a bug.

I will retest with 1.3.1 stable and submit a bug report if I have problems
reconnecting.

Bill