[U-Boot] [PATCH] TCP and wget implementation v4

[Duncan Hare <dh@synoia.com>]

> >
> > A note on this TCP implementation. In TCP the transmitting TCP
> > guarantees delivery of a stream, and the receiving TCP guarantees
> > ordered of delivery of the stream. In this implementation The
> > kernel memory buffer and the TCP sequence number is used to order
> > the stream. for the application, and the application is the kernel
> > itself. wget is not considered the application, and does receive
> > packets "out of order."  
> 
> It seems like it would be possible to just store off a packet that is
> ahead of its neighbor and not call any upper handler until the needed
> packet arrives. Then all upper layers wouldn't need to know about the
> reordering.

There is, for u-boot a large number of buffers used on RX, in order
to have a long work queue  of kernel data. 

CONFIG_SYS_RX_ETH_BUFFER 50 

The TCP transmit window is approximately 25 such packets, so overruns
are eliminated.

There are about 3300 kernel data packets in this test kernel, so missing
a few, 3 to 5, has little impact on elapsed time, and they remain in the
input buffer pool ahead of the HTTP header,

The only critical order for this implementation is the TCP header.
Without processing the TCP header we do not know the stream
address of the first byte of kernel data. It is easy when we know this
to map TCP stream address to kernel data offset.

> >
> > Advice on the reset buffer approach are invited. It requires an
> > interface between the wget application to reset the buffer index.  
> 
> Between wget and what? The TCP implementation? It seems like something
> that should be abstracted from wget.

wget receives packets without intermediate ordering.
Ordering data is a function of wget placing the kernel data at the
correct offset, based of TCP stream location, at the correct memory
address. 

wget is the agent which correctly orders data. There is no
socket analogue, the abstraction, and a socket's linked list buffer
reordering, which is the generally recognized reordering point for TCP
data.

Correct ordering is a primary task of this wget implementation,
becuse the destination is a kernel image, and this choice very greatly
simplifies the TCP stack, while reducing code complexity, and limits
code size.

Reordering would require a new piece of code similar to the fragment
assemble piece of code in net.h, and that's an amazing, but complex,
piece of code. My objective was to produce something as
simple as possible.

The TCP stack delivers packets in the order they come off the wire.
Wget puts them in the correct order based on TCP sequence number to
build the kernel image, and the TCP sequence number/ack protocol ensures
complete delivery of a stream.