Re: [lwip-users] TCP retransmission flooding at end of stream

[Sergio R. Caprile]

For any Dragon Ball Z fans out there, this STM bug looks like Majin Buu
to me...
Anyway, glad you managed to solve your issue Michael, next user with an
STM bug will be charged ;^) I wonder if the SICS can take donations...

As per the tcp_poll() vs tcp_sent() in your scenario, it depends on what
is more important for your main task. The fastest way to transmit is by
filling the TCP buffer from tcp_sent(), just after freeing the acked
pbuf. This way you can keep the buffer full and respond quickly to
window changes (if any). However, you'll keep your hardware dedicated to
this task, and if it is not your highest priority, it might not be your
main interest. If you otherwise just fill the current buffer and let
tcp_poll() wake you up and keep sending, you'll probably won't saturate
your link, but use less processing power. The send loops in servers
mostly work on tcp_sent(), this is OK when serving "regular" amounts of
data. For CGI handlers that might serve long logs, I like to put a pause
once in a while in case the rest of the tasks need to breath, but I
don't use RTOS but bare metal. In any case, I think it is clearer if you
handle data sending on the tcp_sent() callback and keep the polling for
closure or resume after pause (if any).