Ins and Outs of TCP

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
pcmattman
Member
Member
Posts: 2566
Joined: Sun Jan 14, 2007 9:15 pm
Libera.chat IRC: miselin
Location: Sydney, Australia (I come from a land down under!)
Contact:
Contact pcmattman

Ins and Outs of TCP

Post by pcmattman »

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 :D. 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 :D
Top
User avatar
Combuster
Member
Member
Posts: 9301
Joined: Wed Oct 18, 2006 3:45 am
Libera.chat IRC: [com]buster
Location: On the balcony, where I can actually keep 1½m distance
Contact:
Contact Combuster

Re: Ins and Outs of TCP

Post by Combuster »

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.
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
Top
pcmattman
Member
Member
Posts: 2566
Joined: Sun Jan 14, 2007 9:15 pm
Libera.chat IRC: miselin
Location: Sydney, Australia (I come from a land down under!)
Contact:
Contact pcmattman

Re: Ins and Outs of TCP

Post by pcmattman »

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 :D

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 :D
Top
pcmattman
Member
Member
Posts: 2566
Joined: Sun Jan 14, 2007 9:15 pm
Libera.chat IRC: miselin
Location: Sydney, Australia (I come from a land down under!)
Contact:
Contact pcmattman

Re: Ins and Outs of TCP

Post by pcmattman »

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 :P).

Any ideas why this'd be happening? It's frustrating constantly getting so many packets for no reason!
Top
User avatar
Combuster
Member
Member
Posts: 9301
Joined: Wed Oct 18, 2006 3:45 am
Libera.chat IRC: [com]buster
Location: On the balcony, where I can actually keep 1½m distance
Contact:
Contact Combuster

Re: Ins and Outs of TCP

Post by Combuster »

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.
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
Top
pcmattman
Member
Member
Posts: 2566
Joined: Sun Jan 14, 2007 9:15 pm
Libera.chat IRC: miselin
Location: Sydney, Australia (I come from a land down under!)
Contact:
Contact pcmattman

Re: Ins and Outs of TCP

Post by pcmattman »

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.
Top
Post Reply

Return to “OS Development”