Re: [lwip-users] flow of lwip as a stream client

[address@hidden]

Bill Auerbach wrote:
> > -----Original Message-----
> > So, why don't you just use your received pbuf(s) directly in your audio
> > function ?
> > This way:
> > - the size of your "buffer" (made of pbufs) is the size of your TCP
> > window
> > - the server cannot send more

These 2 statements are true for calling tcp_recved() when freeing a 
pbuf. They are also true for calling tcp_recved() when pulling data from 
a private buffer. They are not true for using a pbuf queue but calling 
tcp_recved() when enqueueing received pbufs. As such they are not a 
result of using pbufs as queue instead of a dedicated buffer.

> > - no copy, less memory used (only the TCP window vs buffer + TCP window)

That is of course true, and it's what I would do also.

> Great idea.  You can keep a queue of pbufs of incoming data.  Which leads to
> a question - what if you do this until lwIP runs out of pbufs?  Does it
> throttle back automatically when it's out of pbufs?

What currently happens is that pbuf.c sees that the PBUF_POOL is empty. 
It then tries to free ooseq data, but your application doesn't get 
noticed about this. As such, the driver will simply not get any more RX 
pbufs, and all RX packets will get dropped (the device will appear 
disconnected/dead). We'd need an application callback for such a 
situation, I guess...

In the meantime, providing enough pbufs in the pool would be the 
solution (or queueing in a private buffer).

Simon