[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] flow of lwip as a stream client
From: |
trex7 |
Subject: |
Re: [lwip-users] flow of lwip as a stream client |
Date: |
Mon, 5 Mar 2012 00:49:18 -0800 (PST) |
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.