TCP is not finished

[Jakub Jermář]

The TCP server is not yet finished and works only partially.

[Jakub Jermář]

Copying last update on TCP progress from Lukas Mejdrech:

On 01/ 8/10 07:32 PM, Mejdrech Lukáš wrote:

there is a small progress with the TCP, where the echo accepts a
connection, receives one packet(data segment) and closes the connection
successfully. Unfortunately the replied packet gets lost somewhere :).

[Jiri Svoboda]

I've made some progress. In changeset:mainline,768 I fixed changing the TCP connection state upon connect() (to SYN_SENT) so connect() now works (at least as well as accepting an incoming connection).

Through ticket #277 I fixed handling of incoming FIN (changeset:mainline,773), i.e. now we can tell when the other side has closed the connection.

Nevertheless, there is still a lot of work to do. Data sent through send() don't seem to get through. The socket client code is strangely constructed (see ticket #276). TCP code does not map well to the RFC (no SND.UNA, SND.NXT etc.). The datagram reassembly code seems unnecessarily complex.

[Jiri Svoboda]

In changeset:mainline,774 I fixed a small logic error which makes TCP send() work (sort of). TCP netcat to netecho from oustide now works (on the second attempt)

$ contrib/conf/net-qe.sh
# net
# netecho -t SOCK_DGRAM -p 8080 -v
$ nc 127.0.0.1 8080
^C
$ nc 127.0.0.1 8080
hello
hello
$

[Jakub Jermář]

After the latest changes, I noticed the following:

• sometimes, the leading byte in the TCP packet gets lost (I send "foo" and netecho reports receiving just "oo"); I remember seeing this sporadically also before the latest changes
• sometimes, it takes quite a long time (a couple of seconds to tens of seconds) for netecho to receive the sent data (contrary to being rather instant)
• netecho reports receiving two more bytes than there are printable ASCII characters in the packet (e.g. for "foo" it would report 5); this could, however, be the desired behavior

The first two bullets will reproduce when netecho starts to listen on the TCP after the data was already sent by the client.

Also, the TCP retransmit code is still not being used at all and is, most likely, broken.

The problem of the "first" TCP connection from outside of Qemu goes away if I ping 10.0.2.2 from HelenOS before connecting for the first time. Do we have an ARP related problem here?

[Jiri Svoboda]

Rather than trying to fix the current TCP implementation, which is just too weird, I started to rewrite TCP from scratch. You can watch my progress at ​https://code.launchpad.net/~jsvoboda/helenos/tcp.

[Jiri Svoboda]

See also ticket #291 Invalid mnemonics and documentation in IP protocol.

[Jiri Svoboda]

In the past weeks I have been working on the TCP core. I am using an internal loop-back that bounces the PDUs without actually encoding/serializing them (they only exist in internal representation for now). Most of the connection state machine is done, also a primitive retransmission algorithm is in my working copy.

What also works now is connect(active/passive), send/receive, close. Handling of some less common cases that can happen under adverse network conditions remains to be done, as well as a few other things such as maximum segment size handling, push, urgent data.

Also need to finish synchronization of return from some user calls, PDU encoding/decoding and binding to network stack, IP and socket API.

[Jiri Svoboda]

Merged the new TCP implementation in mainline,1319. This is not 100% complete, but already much more functional than the previous implementation.