[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] Freeing just part of a pbuf chain?
From: |
Brian McFarland |
Subject: |
Re: [lwip-users] Freeing just part of a pbuf chain? |
Date: |
Tue, 22 Nov 2011 11:58:03 -0500 |
>> On a related note, if I don't want to tcp_recv() any more data until
processing the data in B->C, can I just postpone calling tcp_recved()?
> No. That will eventually result in no more data being passed to your
callback as it will prevent the sender from transmitting more, but not on a
timescale that you are hoping for. tcp_recved() allows lwIP to re-advertise
the memory to the sender so it can transmit more packets, but if there were
others already in flight or internal to the stack they will carry on being
delivered. There isn't an easy way with the raw API to stop the stack like
that. It is this sort of feature that the higher layer APIs provide
(together with the associated overhead).
So if I understanding windowing correctly, if want to throttle the remote
client from sending more data until I'm ready for it, I need to delay
calling tcp_recved(), but still be prepared to handle up to a total of
TCP_WND bytes in my tcp_recv() callback? Will the LwIP stack ever send
MORE than TCP_WND bytes through to the tcp_recv() callback without first
invoking tcp_recved() to advertise a new window?