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

[address@hidden]

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