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

[trex7]

Again thanks for the helpful suggestions. 
I change the algorithm in a way that when the private buffer can accomodate
more than TCP_WND  I call the tcp_recved() with TCP_WND otherwise I call
tcp_recved() with remaining buffer size. I need to review my code though
because the tcp received callback is still triggered even if I cannot
process the pbuf(buffer is full). The good thing is lwip is now advertising
more maximal window than before(according to wireshark).

>> - the size of your "buffer" (made of pbufs) is the size of your TCP
>> window

Great idea, unfortunately I'm using the buffer as a universal buffer. I need
the buffer for other "task" when Im not in streaming mode. 

Trex






address@hidden wrote:
> 
> 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
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users
> 
> 

-- 
View this message in context: 
http://old.nabble.com/flow-of-lwip-as-a-stream-client-tp33420167p33441954.html
Sent from the lwip-users mailing list archive at Nabble.com.