Re: [lwip-users] losing input packets and repeated acks

[Jonathan Larmour]

Carl D. Blake wrote:
> I haven't been able to determine why my tcp advertised window keeps
> decreasing, but I've been investigating why I appear to be receiving
> corrupted data.  It seems that I'm not actually getting corrupted data. 
> What's happening is that the lwip device attempts to transmit a packet
> of data, but it can't allocate a tcp seg.  When that happens it throws
> away the packet rather than waiting for the number of tcp segs to drop
> and trying again.  I've just been using the default of 16 for
> MEMP_NUM_TCP_SEG.  Should I increase this?  It seems odd to me that the
> system would just throw the packet away.  Is there some way of retrying
> the packet?

IMHO the correct solution would be to increase the number of SEGs. If you 
want to retry the packet, that means putting packets on queues, which means 
you have to worry about the packets staying there and not being freed back 
to the system; plus queue management, plus some event mechanism to trigger 
the retry. This all takes code and RAM resources, and risks causing 
different resource failures.

The general philosophy in lwIP is to just drop packets when out of 
resources. The alternative approach to queue packets would, if extended to 
cover all situations where that could be argued, lead to large memory 
footprints.

Out of interest, I've personally made my number of TCP_SEGs match 
TCP_SND_QUEUELEN, although that would be overkill for some applications. On 
a 32-bit architecture, segs are only 20 bytes each.

Jifl
--
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine