|
From: | address@hidden |
Subject: | Re: [lwip-users] flow of lwip as a stream client |
Date: | Thu, 01 Mar 2012 17:53:25 +0100 |
User-agent: | Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 |
Robert wrote:
>I think that you should buffer the pbufs, and NOT call tcp_recved() until you consume a pbuf in your audio task.
That's what I would do. However, your buffer has to be big enough to hold at least the complete initial receive window's size of data.
Nice idea but the function tcp_recved() is callback in the raw API so that is not possible as I understand it.
Did you confuse this with tcp_recv()? With tcp_recv(), you set the callback pointer to be called when data is received for a pcb, with tcp_recved(), you tell the stack that you actually processed received data - this results in an updated receive window. Normally, you just call tcp_recved() inside your recv-callback and the window is updated at the same time as the data is ACKed. When you need to buffer the data, you can call tcp_recved() when you actually processed the pbufs (and free them, I guess) so the ACK to the data is sent at the time your recv callback is called but the window is not updated until you call tcp_recved(). That way, you throttle the remote server's send speed (by letting the window size become 0).
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. ???
No, that would be awful: never let a remote host retransmit something you already received successfully. Instead, use TCP's sliding window mechanism as it is meant to (see above).
Simon
[Prev in Thread] | Current Thread | [Next in Thread] |