Anatomy of a Network

By John Murphy

Chapter1 of NT Network Programming Toolkit (Prentice Hall)

Have you ever installed an Ethernet card and wondered how it all works. You install the hardware and then the driver and suddenly you are in touch with everybody on your network. How is it possible to send messages from your PC to a UNIX machine? What does the software need to do to work with the hardware? Put another way, where is the border between what the software does and what the hardware does? There must be rules laid down somewhere that define the requirements of the hardware and software to allow one computer to communicate with another computer of perhaps a different type. There are.

In order to allow computers on a network to communicate, the information has to get from the user's application to the network interface card and across the network into the user's application at the destination. This gets more complex when there may be computers of completely different architectures on the network, and even more complex when there are networks of different types connected together. To allow this, the process of passing information down from the user's application to the network interface card was broken down into a number of different steps called layers. Various functions are compartmentalized into each layer and each layer has a well-defined interface with clearly defined entry and exit points. This means that any of the layers can be modified without changing the behavior of the layer above or below it. The layers are arranged in a stack as shown in Figure 1­1. Information originates at the top and is passed down through the stack until it reaches the network interface. It is then passed through the network and the process is reversed at the destination. The information is passed up through the stack until it reaches the application running on the destination machine. The intention is that the lower layers should be transparent; the application layers of the client and server should appear to have a virtual connection.

The TCP/IP stack is detailed in Figure 1­1 and shows examples of applications that could be running at the top layer, such as a mailer application, a news reader application, a Telnet application, and a web application.

Figure 1: ­1

How It Works

When two machines are connected across the network, it will appear that the connection is between corresponding layers, as shown in Figure 1­2. An application running on one machine will employ the services of the lower layers of the stack to communicate with the application layer on the remote machine. At the top layer, the application will employ a protocol to arrange the sequence of data transfer; it will send data, wait for a response, then send new data depending on the response it received. The responses will come from the corresponding Application Layer at the other end. Similarly, the transport layer will set up the transport service.

Figure 1: ­2

At each step along the way each layer will appear to be talking to its peer layer on the remote end. So what purpose do the various layers serve? The functions of the various layers are summarized below.

Application Layer

At the top is the user application. The application will be the front end; it could be, for example, a mail client, a web browser, or a newsreader. It could also be a proprietary client application transferring and retrieving information from a server over a network. The application layer will operate in accordance with a set of specifications called a protocol. Data will be passed to the corresponding layer at the remote end using the services of the Transport Layer in much the same way as two people talking on the phone. They converse as if they were physically talking to each other, when in fact there are some intermediaries in the way.

The protocol used by an application will dictate how the application establishes a connection with its peer and the sequence of data transfers. For example, on successful connection, a protocol implementation may offer a welcome message and ask for a user name. Subsequently it might ask for a password.

Transport Layer

The Transport Layer defines the type of transport service. The possibilities are either a connection-oriented service or a connectionless datagram-oriented service. With the first type, a connection is opened and maintained for the duration of the session, and then closed. The channel is bidirectional; data can be transmitted and received at the same time. Incoming packets are error- checked and resequenced as necessary. This type of service is referred to as a "reliable" connection. The other alternative is a datagram-oriented channel whereby each packet is dispatched on its way without establishing a dedicated channel. As a result, each packet may take a different route to the recipient so that some packets may arrive out of sequence or, indeed, not at all. This type of connection is sometimes called unreliable. So why would you ever use an "unreliable" transport service? If you intend sending binaries of any kind, then you should certainly think about using a reliable transport service; if, on the other hand, you are sending audio or video signals it may not be that important. Suppose you are trying to transmit video signals over a network; whether or not a few individual pixels arrive corrupted is relatively unimportant; what is more important is the speed with which the information reaches the remote end since any incorrect pixels will be updated moments later anyway. The overhead of error correction and resequencing is excessive and completely unnecessary in this case; speed is far more important.

Internet Protocol Layer

Next in line comes the Internet Protocol (IP) Layer. This layer provides, among other things, routing information and a best effort delivery service. Data is passed from the Transport Layer to the IP Layer in the form of IP Datagrams. The destination IP address is resolved into a physical address called the MAC (Media Access Control) address and the packet is dispatched. There is no error checking or resequencing at this layer; packets arriving at the remote end may take different routes and arrive out of sequence as a result. It is also possible for packets to be lost.

So What Does Winsock Offer?

The Socket API affords the network programmer easy access to the network using a few relatively simple functions to transmit and receive data. The details of the lower layers of the TCP/IP stack are transparent leaving the programmer to concentrate on the more important networking protocols. The API uses the concept of sockets as the interface between the Application Layer and the TCP/IP stack. Conceptually, the socket presents itself to the Application Layer as a simple bidirectional channel like two pipes, one for receiving and one for sending. What happens underneath is not important to us; we are only interested in the sequence of events assuming we can establish the channel.

This socket concept was first introduced in the Berkeley Software Distribution version of UNIX; the intention was that the implementation would be transport-independent.

Figure 1: ­3

Conceptually, it means that the Internet application engineer is free to think in terms of bypassing the TCP/IP stack. The details of the underlying layers are largely irrelevant, although it is important to understand why they are necessary.

The Windows implementation is called Winsock and comes in two flavors: Winsock 1.1 and Winsock 2.0. Winsock 1.1 is the version supported by MFC so this is the version we will be looking at here. The Winsock API offers essentially two transport services: a connection-oriented service and a connectionless service.

The sequence of operations to establish a socket connection is quite straightforward. In the case of a connection-oriented service, the application starts by constructing a socket. This socket is then bound to a particular port and the socket's listen() function is called. When a client sends a connect request, the server will acknowledge the request by redirecting the incoming request to an unused port, thus freeing up the listening socket. Once the connection has been established, both sides are free to send and receive as they wish or as the protocol demands.

The listening socket is capable of maintaining a queue or backlog of connect requests in the event that more connect requests arrive before the first has been dealt with.

Figure 1: ­4

Conceptually, the process looks like that shown in Figure 1­4. In the form described, the sockets are operating synchronously. The socket function calls will not return until such time as the operation has completed successfully. These are called blocking sockets because their behavior and the model work well in simple applications, but the disadvantage is that socket calls could block a thread indefinitely in the event of a network problem. The alternative to this is the nonblocking socket. The nonblocking socket operates asynchronously, so that a call to a socket function will return before the operation has had a chance to complete.

In the following chapters, we will be looking more closely at the implementation of Windows sockets and, more specifically, at applications using classes derived from MFC sockets classes. A number of Internet applications will be developed starting with the simple chat application and finishing with a Web server application.

About the Author:

John Murphy is currently Principal Engineer in 3Com's Test Development Group in Dublin and is responsible for developing networking applications for Functional Test, and for Ongoing Reliability Testing. He lives in Meath, Ireland.

Copyright © Prentice Hall, Inc. 1999. All rights reserved.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.