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
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
