| Hi,
Ok, so it seems I misunderstood the doc. I will try to keep the pbufs in some queue for delayed processing.
Just a last question : If I am really slow, I will have to queue many pbufs, and I will exhaust the pool of pbufs for the new incoming TCP packets. I expect that in that case, the emitting program client will be told that something could not be delivered, and it will have to handle that explicitely. Am I right this case ? Or is the "running out of pbuf" error designed to be handled differently ?
On 27.11.2018 17:16, Pierre Chatelier
wrote:
Hello,
I have a question regarding the expected behaviour with lwip
incoming TCP packets.
I have a my_tcp_recv_cb() callback that handles incoming TCP
packets.
Usually, it just ends with
tcp_recved(pcb, p->tot_len);
pbuf_free(p);
However, if sometimes I do not have enough time or memory to
handle the packet, I would like to tell "do not ack this one,
please send it again later"
According to the doc (http://lwip.wikia.com/wiki/Raw/TCP),
I understand that I should :
I didn' know that one. The wiki is not as well maintained as it
should be, so it's always better to read the main documentation at
http://www.nongnu.org/lwip/
-call tcp_recved(pcb, written);//if I was still able to handle
"written" bytes, and in that case obviously "written" is less than
p->tot_len
-do *not* call pbuf_free(p);
-return an error (e.g. ERR_MEM)
No, you cannot combine "tcp_recved" with returning != ERR_OK.
Because when returning ERR_MEM, the stack will buffer this pbuf and
pass it back to you later. You'll end up with calling tcp_recved for
some bytes more than once.
" If there are no errors and the callback function
returns ERR_OK, then it is responsible for freeing the pbuf.
Otherwise, it must not free the pbuf so that lwIP core code can
store it."
But in that case, it just starts to be a mess. Some packets begin
to be delivered very slowly (1 byte at a time in pbufs!), and it
does not seem to behave as expected.
Actually, that *is* expected. Returning ERR_MEM can only be the last
resort. It destroys some TCP assumptions. You should rather keep the
pbuf on a list for yourself and return ERR_OK and process it at some
later time, calling 'tcp_recved' after processing it. This will send
ACKs immediately (TCP depends on that) but the window will close and
will be reopened for the remote host to send more once you called
'tcp_recved'.
If you can't buffer all pbufs, decrease your TCP_WND size.
Simon
_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users |