Re: [lwip-devel] etharp.c updating

[Simon Goldschmidt]

Kieran Mansley <address@hidden> wrote:
> It'll be a TCP RTO.  Fast retransmits will only happen if there is a
> hole in the sequence space followed by valid packets that cause the
> duplicate ACKs.  Without the following valid packets (you won't get them
> in this case as the whole tail will be dropped when the ARP expires) you
> won't get the duplicate ACKs and so you won't get the fast retransmit.
> All that's left is the RTO, which is painfully slow.  

I thought Leon's application would continue to transmit and thus new packets 
would trigger fast retransmission when they are correctly transmitted after the 
ARP entry has been set up again. However, as I said that could not only be 
prevented by the application (stopping to transmit new data) but also by the 
fact that lwIP buffers could be full before the ARP entry is set up.

Anyway, both explanations are a strong case for us to change the code so that 
such an entry is re-requested before it times out. Since would effectively only 
be a test for a single counter (for every transmitted packet), I don't think it 
will hurt performance to much. Restructuring find_entry() to only do a quick 
find on TX should outweight that anyway.

Simon
-- 
NEU: FreePhone - kostenlos mobil telefonieren!                  
Jetzt informieren: http://www.gmx.net/de/go/freephone