On Thu, Mar 1, 2012 at 8:53 AM,
address@hidden <address@hidden> wrote:
Robert wrote:
>I think that you should buffer the pbufs, and NOT call tcp_recved()
until you consume a pbuf in your audio task.
I think you will also want to return ERR_MEM from your callback, if I understand the code correctly, the stack will buffer the data for you and then will try again on the next fasttmr will try delivering the data again to your application.
This way, when your circular buffer is full, the stack will buffer up the data, and the server will stop sending data until you have cleared your circular buffer and the window is updated.
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