Hello,
My proposal: Chain up the handed pbufs in the recv callback
("push_back", instead of handling&freeing) to a private chain of pending
data, and call tcp_recved with the amount of bytes you consume from this
received-chain at your own discretion at some other point in time (and
be sure to free the pbufs as you walk across pbuf-borders, ie
"pop_front"). There are quite enough helper functions for handling the
pbufs (and copy data across borders). Oh, and wait for the update that
fixes leaking tcp_ucbs on remote-close with this approach, hehe. Or did
this land already?
Michael
Am 13.09.2017 um 07:13 schrieb Simon Goldschmidt:
Paul Plankton wrote:
So when I do not want the window to be enlarged, I call this function not with
the amount of data received but with a fixed value? E.g. with the window size
like it is defined in lwipots.h?
I'm not sure I understand your question.
For a working TCP connection, you'll have to call 'tcp_recved()' eventually.
The amount of bytes (coutn value) you pass to this function has to be the exact
length of the received data or things will go wrong at some point.
Now you have the option to throttle the sender by only sending a full window of
data until you are ready to process more data (in your application, the stack
internals tell the remote host they have processed the data by sending an ACK,
no a window update).
This is done by *not* calling 'tcp_recved()' directly from the recv callback
but at a later point (watch out for threading issues here!).
However, you *always* must keep the byte count correct, you cannot just pass in
any constant value!
Simon
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
