From mboxrd@z Thu Jan 1 00:00:00 1970 From: Duncan Hare Date: Fri, 5 Jan 2018 14:10:57 -0800 Subject: [U-Boot] [PATCH] TCP and wget implementation v4 In-Reply-To: <1265391460.1283367.1515183992460@mail.yahoo.com> References: <20171108163407.3e8bb872@raspberrypi> <1512063880.2580267.1512525185991@mail.yahoo.com> <20180103130704.40c7abf2@raspberrypi> <1220614347.9042380.1515015734928@mail.yahoo.com> <20180103150154.482c86a6@raspberrypi> <1265391460.1283367.1515183992460@mail.yahoo.com> Message-ID: <20180105141057.4e22ebf2@raspberrypi> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de > > > > 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.