A solid grasp of TCP/IP fundamentals is essential to everything from effective workstation operation to systems management. Why then, with so many TCP/IP primers written to
“jump-start” us, is the goal of a broad understanding of TCP/IP still elusive?

TCP/IP is complex in its simplicity. That is to say, this popular, easy-to-understand protocol suite that enables millions of computers worldwide to communicate with one another is made complex only when attempts to explain this relatively unpretentious communications medium become needlessly long-winded.

For instance, writers paid by the word are compelled to explain in depth the development of the protocol. They describe how it began as a paranoiac reaction to the Soviet Union’s launch of Sputnik I in 1957, when the Department of Defense designed the Advanced Research Projects Agency Network. ARPANET, the Internet’s progenitor, was designed to survive a nuclear attack on any of its adjoining networks. I won’t do that here! Other TCP/IP writers of “introductory tutorials” forgo the 50,000-foot view altogether and haul out the electron microscope to, presumably, authenticate their own qualifications. In those “high-level” discussions of TCP/IP connections, you might expect to see irrelevant and distracting minutia like the fact that a 10Base5 Thick Ethernet cable’s maximum transmission length is 500 meters and its maximum operating speed is 10 Mb. I won’t do that either.

This is not your father’s TCP/IP overview!

Protocols

Everywhere we turn, we’re surrounded by “behavior expectations,” or protocols. Protocols ensure operations are carried out predictably, consistently, and orderly. In a LAN environment, for instance, literally thousands of transactions may be in flight at any given instant. Without some semblance of order, chaos would ensue, compromising the integrity of the network and making reliable data transmission impossible.

To achieve order, networks make extensive use of protocols. Requests that don’t honor the protocol du jour are routinely rejected or simply discarded. Popular network protocols include the SNA and the Open Systems Interconnection (OSI) models. Both are “layered” protocols: separate layers are responsible for designated functionality and interact with each other accordingly. One layer, for instance, may interface with a user or an

application, and another layer may interface with the physical network. SNA has, of course, been implemented on the OS/400 and the OS/390 (as VTAM).

Because the OSI model, which has no popular implementation, bears some similarity to the TCP/IP model, the two are often referred to as being analogous to one another. They are not. TCP/IP is more than just a protocol. In fact, it is an entire protocol suite specifying not only how various layers will intercommunicate but also how popular applications such as Web browsers, FTP clients, and Telnet implementations will behave.

The TCP/IP Protocol Stack

No discussion of interprocess communications can commence without a brief description of the TCP/IP protocol stack, illustrated in Figure 1. Traditionally represented with four layers, the stack is quite a bit easier to understand when its functions are distilled to the bare minimum.

At the Application Layer, various TCP/IP applications communicate with their cross-network counterparts via sockets in the Transport Layer, which is below the Application Layer. A socket is really nothing more than a port connecting two stacks. An FTP client application might connect to its local TCP port and then request a connection with a target computer’s port. You can almost imagine TCP/IP acting as an old-fashioned telephone operator as it makes a physical connection between your application (client) and the target application (server). At that point, data can flow along the created pipeline in accordance with the rules of application communication (i.e., a protocol).

The Transport Layer supports two types of sockets that the Application Layer may exploit: TCP (Transmission Control Protocol) and UDP (User Datagram Protocol). Little needs to be said except that TCP is the more reliable protocol because of its provision for error checking. UDP, on the other hand, is leaner and meaner and makes no guarantees as to the delivery or integrity of the data. Telnet and FTP, for example, depend on TCP to guarantee the delivery and integrity of the data, while the Simple Network Management Protocol (SNMP) sends traffic through UDP because of its low overhead. A custom- designed client/server application could choose either protocol.

The Internet Layer is responsible for determining the location of the partner system as well as actually dispatching the data. To ship data, the Internet Layer uses IP and a “send and forget” mantra, which presumes a combination of application tracking and network availability will ensure successful transmission. Reliability is not the responsibility of the Internet Layer. Rather, reliability is the chore of TCP in the two Transport Layers. In addition to shipping the data, the Internet Layer is responsible for determining where the data needs to be shipped. For instance, if a client requests a connection to 192.168.0.2, it is the responsibility of the client’s Address Resolution Protocol (ARP) on the network where the target IP address resides to resolve the target system’s MAC address (i.e., the hardware address of its Ethernet card). In short, a higher level may address an envelope simply with the name juliet, but it is the Internet Layer that must add the street address, city, state, and zip code in preparation for mailing.

The lowest level in the stack is the Network Layer. It is here that data is physically shuttled between two points via the local medium (e.g., coax, twisted pair, or telephone line) and network connection (e.g., Token-Ring, Ethernet, or Point-to-Point Protocol [PPP]).

Stack-to-Stack Communication

Ultimately, what permits two applications to communicate via sockets and a virtual pipeline are the sophisticated address-lookup protocols and network topologies provided by TCP/IP. Though this framework is purposefully transparent to the applications programmer, it is necessary to understand it before pursuing in-depth knowledge of other specific TCP/IP topics.

As I mentioned, when one TCP/IP application needs to establish a session with another TCP/IP application (a client with a server, for example), the specified TCP/IP address is used to locate the physical MAC address of the target host. As a result, the Network Layer knows where to send the data. For clarity, two assumptions are made in this explanation:

• An address, rather than a hostname, was specified.
• The address resolved to the same network. If a hostname (a computer’s alias—e.g., juliet) or a domain name (e.g., mycompany. com) is specified, the IP address must first be ascertained. This check is done in one of two ways. First, the local computer’s host file is queried. The host file is a somewhat archaic name server with records of the format “ipaddress hostname.” For instance, the host file entry for Computer A in Figure 2 would include the entry
“192.168.0.2 juliet” indicating that a request for resolution for the hostname juliet would return 192.168.0.2.

If an entry is not located in the local host file, the computer’s name server (designated via configuration parameters) is queried. A name server is typically on a LAN server or other central machine. In Figure 2, the name server is located on Computer C. (It is worth mentioning that in the illustration, Computer C’s name server is part of a Domain Name System (DNS), which implies that network name resolution is distributed among several networked hosts. The Internet is the best example of a DNS. Fundamentally, the DNS and a network of backbone servers are all that differentiate the Internet from smaller networks.)

A request by romeo (Computer A) to open an FTP connection with juliet (Computer
B) resolves to a request for romeo’s ARP to affect a connection from 192.168.0.1 to
192.168.0.2. This request is formally made when the Network Layer passes the data packet to the corresponding MAC address. If the target server (the FTP server, or daemon, in this case) is available to accept connections, it will respond in turn and the pipeline between the stacks will be established.

Applications and the TCP/IP Stack

Although you may not be aware of it, many of your applications communicate directly with the TCP/IP protocol stack within your computer to communicate with a counterpart application on another computer via its corresponding TCP/IP stack. This process is illustrated in Figure 2. (One exception is the earliest permutations of Serial Line Internet Protocol [SLIP], in which a local computer merely connected to a remote TCP/IP protocol stack for services; there was no local stack. SLIP has been supplanted by SLIP/PPP, often referred to simply as PPP.)

As I mentioned, applications send data through TCP/IP to their counterparts via a pipeline. The endpoints of this pipeline are called sockets, which are simply aliases of the IP address and a port number. A TCP/IP application can use any port number from 0 to 65535 to communicate. However, some of these numbers (0 to 1023) are reserved for preordained functions such as FTP, Telnet, DNS, and SNMP. Others, 1024 to 49151, are registered with an organization called the Internet Assigned Numbers Authority (IANA) in much the same way that domain names are registered. The remaining ports are free for local “private use.”

Well-known and registered ports are necessary to maintain order on the network. Without them, whenever you wanted to make a connection to an FTP server (daemon) on a target machine, you would not only need to know the hostname or IP address, but also the port on which the server was waiting to accept connections (or on which the server was
“listening”). Instead, you simply do a quick search using one of the many references available on the Web (e.g., www.iana.org) and learn that the FTP server always connects to its local TCP/IP port 21. Of course, in many cases, the user is insulated from this sort of information. The designers of the client application may dynamically allocate any available

local port, and they will typically ensure that the application makes the correct request to connect to the appropriate port of the target host. The programmers of Netscape’s Navigator and Microsoft’s Internet Explorer Web browsers, for instance, append the well- known port for the HTTP server to any request a user makes. That well-known port is 80. For Telnet, TN3270, and TN5250, the well-known port is 23; for SNMP, it is 161. In most cases, you’ll never know the well-known port through which your applications communicate, nor do you need to know. However, for the truly curious, a NETSTAT command will reveal the port, thereby adding dimension to the client-server relationship. NETSTAT displays protocol statistics and current TCP/IP network connections. On a Windows workstation, you can execute the command from a DOS prompt; execution on other platforms varies with the TCP/IP implementation.

A fun and informative way to better understand sockets doesn’t even require TCP/IP access to another host. Every TCP/IP implementation includes a special loopback address that always points back to itself. That is, when this address request reaches the IP layer for MAC resolution, it is recognized as a local address and doesn’t get passed through the Network Layer. Instead, the request is passed back up through the stack to the target port. If you have an FTP daemon started on your system or a third-party FTP server, you can start an FTP session by pointing to IP address 127.0.0.1 (the loopback address). Once you have a connection, you can use the NETSTAT command to see the local address and port used by the client, as well as the target host IP address and port. You know now that the target port will be the FTP well-known port 21. Experiment with the loopback address. It’s a great way to observe how applications (whether they’re on the same host or thousands of miles apart) communicate with each other.

TCP Sockets

Practically all TCP/IP application communication, and most operations, involves socket communication. And most applications, whether they’re popular applications using well- known ports or home-grown client/server applications, use sockets in a similar manner.

As illustrated in Figure 3, a server or daemon application obtains a socket that the program uses to refer to the opened port (the server’s port must be known to all potential clients). The bind is a registration step the server must perform. When the initialization is complete, the server listens for connection requests on its open port. When a request comes in, the server accepts the connection and is ready to send or receive data based on a prearranged protocol.

The client, meanwhile, also creates a socket by specifying a local unused port. The client then attempts to connect to the known port (which is the port the server previously opened and registered) that will service it. The client might try to connect to a well-known or registered port, or, in the case of a homegrown application, the port need not be known to the entire Internet community but only to the users of the service. Again, once the connection is complete, the applications communicate with each other with simple send and receive operations. When they’re done, the tasks issue a close command to clean things up.

Let’s see how this might work in an FTP implementation. First, the FTP daemon would create a socket and bind itself to port 21, the well-known port for FTP. At that point, the server would listen for and accept all connection requests. The client, meanwhile, would also obtain a local socket, but not one from the reserved range (0 to 1023). Instead, the client might use port 1330, 1880, or some other local port that another client on the same host won’t attempt to open. Once the server accepts the connection, the client and server applications can exchange data using the prearranged protocol, in this case, the File Transfer Protocol, or FTP.

Where Do You Want to Go?

What’s next? You’ve shifted your focus from the overview of stack communication down to interprocess communication. You’ve observed that TCP/IP is not a single protocol, but a protocol suite consisting of the following:

• A set of protocols including the Transport Layer protocols TCP and UDP
• The Internet Layer protocol IP
• The various additional Network Layer protocols such as PPP and Ethernet
• The Application Layer protocols such as FTP, SNMP, Telnet, and any user- written client/server application communication protocols

You’ve also seen that, ultimately, applications communicate by establishing a pipeline via socket connections. And even with everything you’ve learned, you’re still at the threshold of TCP/IP. From this brief examination, you can glimpse the TCP/IP enigma: the complexity of the simplicity. Where you go now depends on your interest. If you’re a network planner, you’ll pursue more in-depth information on the Internet and Network Layers, perhaps from a DNS and network topology perspective. If you’re interested in applications development, you’ll pursue details of the Transport Layer—TCP and
UDP—and sockets programming. In either of these cases, you’ll find abundant information in the Request For Comment (RFC) documents that circulate among the Internet community and describe the protocols with nauseating detail. RFC791, for example, describes IP, and RFC794 describes FTP. There are more than 2,500 RFCs available by a simple Yahoo! search.

However, if your interest in TCP/IP was just a curiosity, you’re now armed with an understanding of what were previously cryptic configuration parameters and can see, at least, how applications communicate with each other across a LAN or the Internet.

So don’t just sit there; go FTP something!

Application Layer

Clients, Server/Daemons: Rexec, DNS, SNMP, Web Browser (HTTP client), FTP, Telnet/TN5250/TN3270, etc.

Transport Layer

TCP and UDP Sockets

Internet Layer

Address Resolution Protocol (ARP)

Network Layer

Ethernet, Token-Ring, FDDI, SLIP/PPP, etc.

Figure 1: Check out how the TCP/IP stack looks.

Computer C

e.g. 192.168.0.3

DNS Server

Physical Connection

e.g. SLIP/PPP Dial-Up Line (above), or, Ethernet LAN connection (below)

Figure 2: Here’s what a TCP/IP stack client/server communication model looks like.

Server

socket() bind() listen() accept()

send()/recv() close() end (or iterate)

Computer A

e.g. 192.168.0.1 Hostname: romeo

TCP/IP Protocol Stack

Computer B

e.g. 192.168.0.2 Hostname: juliet

TCP/IP Protocol Stack

TCP/IP Protocol Stack

FTP Client

Host

File

FTP Server (Daemon)

Client

socket() connect() send()/recv() close()
end

Figure 3: This diagram demonstrates how a typical client/server socket interprocess flow operates.