OSDev.org

Hi guys,

I'm trying to implement TCP off the RFC and Wikipedia articles on the subject, and I'm not letting myself look at *any* other code - I want to write it myself. But, I've run into some problems with my understanding of it.

So far, I'm writing as a server. So I have been able to establish a connection to a client (so I have no problems getting to ESTABLISHED state). However, once here, I'm totally stuck . I've been able to receive data so far (which comes in as ACK) - my OS prints out the total packet data and I see a nicely formed HTTP request, all ready and fitting in the one packet. So, I ACK the incoming data like a good server and ensure there is no data sent in my ACK (because that'd be pointless). And then, I receive another packet. I *believe* something in this packet indicates the end of the data stream, but I have no idea what exactly. And then, of course, because I don't know when the incoming data steam ends, I have no idea when to start sending my data.

So you can see I'm a bit stuck, some help (preferably NOT code) would be greatly appreciated

The idea with HTTP, is that you start your reply as soon as the request is finished.
In other words, that is when the request is completed (a GET header ends with two newlines, or an empty line depending on how you look at it)

Right now you have the problem that the client can't close the connection because it is expecting *you* to send the reply to it, while you are trying to wait for an end of the data stream, which on the TCP level can only occur via a connection close. The logic error that occurs here is that HTTP does not rely on such a method.

Right, so that'd explain why HTTP requests are sent with the PUSH flag set.

If I understand right, then that means I ACK the completed request with a response (in the data section) as soon as it comes in rather than wait. I'll try it out and see what happens

EDIT: Hey, it worked! Now the client sends RST rather than ACKing, so I've got to figure this phase of a TCP connection out now. Thanks Combuster

Bumping this thread (hence the double post).

Now I am able to connect and disconnect from a remote host cleanly, but I'm having some issues with data transfer. I'm using a Python program to act as my server, and it's meant to accept an incoming connection. Once it accepts, it sends 7 bytes and then waits for either the client to disconnect or to send data.

I'm not worrying about sending data at this stage, just receiving for the time being. The trouble is, I get every time when I am connected (state ESTABLISHED) and the Python program stats sending packets, it sends 7 packets! Inspecting the packet dumps though, each packet is practically the same! I've got no idea why this is happening, and as for now I just ACK (even though I haven't *actually* received the data ).

Any ideas why this'd be happening? It's frustrating constantly getting so many packets for no reason!

Packet errors?
TCP will resend packets when it doesn't know the other end has received them. Try to grab a program like Ethereal and see what is actually going down that line.

I'm using WinDump at the moment, and even though I ACK the received packets (shown by WinDump) it still sends more.

The sequence numbers - are they numbers of bytes or something? I've noticed just now when I successfully sent data to a remote host it ACK'd with a sequence number 4 higher than I was expecting (5 bytes of data sent). The RFC and other documentation isn't exactly all that clear on this...

EDIT: I have now found out that the sequence numbers are actually based on the bytes to be sent. So if I send 5 bytes my local sequence number (say 12345) will go to 12350, and the remote host will ACK 12350. Is that right?

EDIT 2: Actually if the previous edit is true, then that explains why I received 7 packets for a 7 byte string - I was only ACKing the first byte of each packet..

Last edit: Figured it out now... Nothing like trying something out to see how it works.