On Thu, Mar 1, 2012 at 8:53 AM, goldsi...@gmx.de <goldsi...@gmx.de> 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 > > > ______________________________**_________________ > lwip-users mailing list > lwip-users@nongnu.org > https://lists.nongnu.org/**mailman/listinfo/lwip-users<https://lists.nongnu.org/mailman/listinfo/lwip-users> > -- Mat Henshall Founder and CEO, Square Connect, Inc. San Jose, CA www.squareconnect.com cell: 650.814.7585
_______________________________________________ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
