Free TCPIP and retransmission

anonymous wrote on Thursday, December 13, 2012:

I’m working with the FreeTCPIP stack provided with the demo for the RX62N processor and I’ve some doubts on the internal ack and retransmission policy.

In the FreeRTOS web site the description says that this stack is an improvement of uIP that removes the limitation of a single packet outstanding on the network - is that right?

Does it means that I can receive more than one poll request and send more than one packet before receiving an ack? If so, when after the transmission of a packet I receive a retransmission request, should I send only the last packet sent  (as stated in the uIP source code) or all the packets sent after the last ack?

Thanks in advance for any help or suggestion!

rtel wrote on Saturday, December 15, 2012:

There are two ways speed improvements are achieved.  I don’t recall which was used in your particular case.

The slow speed comes from the fact that uIP will wait for one packet to be acked before sending another, and Windows (and other desktop) computers will wait around 200ms before acking a packet.

The easiest way to get around this is to trick the other end to send an ACK immediately by sending each outbound packet twice.  If transmissions are done using a DMA then this is the best method as it introduces little or no CPU overhead at the cost of a few more bytes on the wire.

Other demos increase the MSS size to double the true MSS value, then in the network driver split oversized packets into two packets where the maximum size of the packet is the true MSS value.  This has two effects, first it double the amount of data that can be outstanding at any one time and second it ensures the other end of sends an ACK immediately that the second packet is received.

In both cases the internal sequencing of waiting for an ACK before sending the next packet is not changed.


taxalb wrote on Monday, December 17, 2012:

Thank you very much for your answer