lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Robert
Subject: Re: [lwip-users] flow of lwip as a stream client
Date: Thu, 01 Mar 2012 17:34:23 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2

>I think that you should buffer the pbufs, and NOT call tcp_recved() until you consume a pbuf in your audio task.

Nice idea but the function tcp_recved() is callback in the raw API so that is not possible as I understand it.

What you can maybe do if you are writing the server software also is not to acknowledge the message if your puffer is full, so the sender will try to re send it. ???

not sure if this could work, I am self new with the lwip stack.


Am 01.03.2012 17:15, schrieb Stephane Lesage:
Thanks for the reply. I'm indeed using a circular buffer to buffer the
incomming pbufs. My problem is that I don't how how to process the
pbufs if my circular buffer is full. That means that the decoder that
consumes the buffer is slower than the incomming pbufs. I dont want to
stop the application I just want to wait. The above code is not
complete, sorry for that, I just want to demonstrate that Im not sure
what to do if the I cant process the pbuf because I need to wait until
I have enough space in the circular buffer.
I appreciate your answer.
Hi,

The problem is that you read always as much as possible from the
streaming server.
If not real-time, it will always send you too much.
You have to let the TCP window go full by not reading, so that the
server cannot send you more data.

That's not so easy to do with raw API.
I think that you should buffer the pbufs, and NOT call tcp_recved()
until you consume a pbuf in your audio task.

Hope this helps.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]