Fork us on GitHub Follow us on Google+ Follow us on Facebook Follow us on Twitter

Opened 9 years ago

Closed 7 years ago

#205 closed defect (fixed)

TCP is not finished

Reported by: Jakub Jermář Owned by: Jiri Svoboda
Priority: major Milestone: 0.5.0
Component: helenos/net/tcp Version: mainline
Keywords: Cc:
Blocker for: Depends on:
See also:


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

Change History (9)

comment:1 Changed 8 years ago by 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 :).

comment:2 Changed 8 years ago by 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.

comment:3 Changed 8 years ago by 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
# netecho -t SOCK_DGRAM -p 8080 -v
$ nc 8080
$ nc 8080

comment:4 Changed 8 years ago by Jakub Jermář

Owner: set to Jiri Svoboda
Status: newassigned

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 from HelenOS before connecting for the first time. Do we have an ARP related problem here?

comment:5 Changed 8 years ago by Jakub Jermář


comment:6 Changed 7 years ago by 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

comment:7 Changed 7 years ago by Jiri Svoboda

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

comment:8 Changed 7 years ago by 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.

comment:9 Changed 7 years ago by Jiri Svoboda

Resolution: fixed
Status: assignedclosed

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

Note: See TracTickets for help on using tickets.