"The Linux Gazette...making Linux just a little more fun!"

SYN, SYN/ACK, ACK, ACK, ACK: TCP Handshaking

"Pleased to meet you!"

From Kent S on Sun, 02 May 1999

I need help in finding information regarding how sockets are established (not how to code them). In other words, I know that there is a standard procedure followed (SYN,SYN/ACK,ACK) in getting a device talking with a server.

This is referred to as a "three way handshake." The "SYN" flags are requests by the TCP stack at one end of a socket to synchronize themselves to the sequence numbering for this new sessions. The ACK flags acknowlege earlier packets in this session. Obviously only the initial packet has no ACK flag, since there are no previous packets to acknowlege. Only the second packet (the first response from a server to a client) has both the SYN and the ACK bits set.

I am more curious in determining how, where, and who actually handles this on the Linux server.

The kernel.

As an example - I have inetd looking at port 226 for me that will start a program that will read from the socket. If this program terminates (kill,alarm,etc...) then the device attempts to re-establish (sends a SYN). Then one of two things happens depending on how the program was stopped. Either the server never responds until the device sends a reset or the server sends a SYN/ACK and then sends a packets saying that it is finished sending data. My questions are on the level of does RESET reset a port or a socket, and why would a server send a finish sending data flag if the device is requesting a connection. I have been unable to find info about the protocols of communications that should be taking place. Any help would be appreciated!

Kenneth Scott

I don't really understand what you're asking or what situation you are trying to describe. Giving examples of what you see and the specific diagnostic commands you're using to gather your data on the problem (ps, netstat, lsof, etc) would probably help.

However, I can take a guess at what you might be seeing.

There is also a three way handshake at the termination of a TCP session. Either side sends a packet with the FIN (final) flag set, and waits for the other side to acknowlege that with another FIN packet.

After the local process as attempted to close the socket (and the TCP stack has sent the FIN packet to the remote system) the process will be listed as being in the FIN_WAIT stat when you do a 'netstat' command. Buggy TCP clients may just close their end of the connection without completing the three way session termination. This seems to be mostly from certain MS Windows FTP clients.

There seems to be no "timeout" for how long a processes will sit in FIN_WAIT. When I managed a busy FTP server farm for McAfee Associates (a shareware company with lots of MS-DOS and Windows products) I used to see alot of zombies which were children of FTP daemon processes that were in FIN_WAIT. I had a skulker script that would find the parents of the zombies, check their age and argument list and summarily kill them.

I don't know the details about the TCP RST (reset) process. I've at the extreme edge of my knowlege of TCP in this message --- so I can't go into any greater detail on this.

However, I've heard that the best sources of information about TCP protocols are a couple of books. One would be the O'Reilly volume by Craig Hunt (the crab book), Understanding TCP/IP [ Actually, the "crab book" is TCP/IP Network Administration, now in its 2nd edition. -- Heather ], the other would be a three volume set by Comer and Stevens Internetworking With Tcp/Ip: Principles, Protocols, and Architecture.

As you've suggested these are written more with the programmer in mind. However the O'Reilly book seems to be more suitable for sysadmins and users (besides being a paperback, and therefore much less expensive than the three volume hardcover text books from Prentice Hall).

One of these days I'll get around to reading that one. I'd been holding out for one that covered IPv6 in the hope that IPv6 would be deployed more widely by the time I got around to learning all the gory details. However, it looks like we'll still be dealing with IPv4 (the current suite of protocols) for the foreseeable future.

Copyright © 1999, James T. Dennis
Published in The Linux Gazette Issue 42 June 1999

HTML transformation by of Starshine Techinical Services, http://www.starshine.org/

	1	2	3	4	5	6
	7	8	9	10	11	12
	13	14	15	16	17	18
	19	20	21	22	23	24