The Transmission Control Protocol

Now, of course, sending datagrams from one host to another is not the whole story. If you log into quark, you want to have a reliable connection between your rlogin process on erdos and the shell process on quark. Thus, the information sent to and fro must be split up into packets by the sender, and reassembled into a character stream by the receiver. Trivial as it seems, this involves a number of hairy tasks.

A very important thing to know about IP is that, by intent, it is not reliable. Assume that ten people on your Ethernet started downloading the latest release of XFree86 from GMU's FTP server. The amount of traffic generated by this might be too much for the gateway to handle, because it's too slow, and it's tight on memory. Now if you happen to send a packet to quark, sophus might just be out of buffer space for a moment and therefore unable to forward it. IP solves this problem by simply discarding it. The packet is irrevocably lost. It is therefore the responsibility of the communicating hosts to check the integrity and completeness of the data, and retransmit it in case of an error.

This is performed by yet another protocol, TCP, or Transmission Control Protocol, which builds a reliable service on top of IP. The essential property of TCP is that it uses IP to give you the illusion of a simple connection between the two processes on your host and the remote machine, so that you don't have to care about how and along which route your data actually travels. A TCP connection works essentially like a two-way pipe that both processes may write to and read from. Think of it as a telephone conversation.

TCP identifies the end points of such a connection by the IP-addresses of the two hosts involved, and the number of a so-called port on each host. Ports may be viewed as attachment points for network connections. If we are to strain the telephone example a little more, one might compare IP-addresses to area codes (numbers map to cities), and port numbers to local codes (numbers map to individual people's telephones).

In the rlogin example, the client application (rlogin) opens a port on erdos, and connects to port 513 on quark, which the rlogind server is known to listen to. This establishes a TCP connection. Using this connection, rlogind performs the authorization procedure, and then spawns the shell. The shell's standard input and output are redirected to the TCP connection, so that anything you type to rlogin on your machine will be passed through the TCP stream and be given to the shell as standard input.