[En-Nut-Discussion] about tcp stack 2.4 an later

[Harald Kipp]

Hi (gfaxman?),

There has been a major change in the network code
from 2.3 to 2.4. Did you mean that one? This had
been done not to get a more clear code but to
enhance the performance. Version 2.3 was able to
reach transfer rates below 100 kByte/s, while
2.4 can transfer about 250 kByte/s. I found out,
that the original idea to distinguish between
synchronous and asynchronous transmits for
decoupling receiver and transmitter was not
that smart.

In opposite to Liquorice, which uses callbacks in
the application code, Nut/OS provides some kind of
BSD style socket interface. In this way the original
Liquorice code may provide the optimum performance,
but the burden of buffering is put on the application
side.

The main problem for Nut/OS is, to decouple these
three parts, which have to run asynchronously:

a) Network receive
b) Network transmit
c) Application interface.

If not decoupling a) and b), the TCP state machine
will probably run into a deadlock. The decoupling
is done at that point you mentioned.

I can't see the problem you mentioned in example
1, because NutEventWait(&tcp_in_rdy, 200) times
out every 200 ms. Or do you mean the LAN connection
may send so many packets, that the NutEventWait
would never timeout?

Regarding your second example: ARP timeouts won't
hurt because of the decoupling mentioned above.
Receiving and transmitting is completely asynchronous.
The TCP packet without ARP entry is buffered,
an ARP request is sent out and the transmit returns,
ready to handle new incoming packets. When later
on the ARP response is received, the buffered
TCP packet will be sent.

Harald