Network Protocol Basics

Protocols are nothing more than an agreed-upon way for two objects (people, computers, home appliances, and so on) to exchange information. There are protocols at various levels in the OSI model. In fact, it is the protocols at a particular level in the OSI model that provide that level’s functionality. Protocols that work together at one or more layers of the OSI model are known as a protocol stack or protocol suite. The following sections explain how network protocols move data between machines.


How Protocols Work

A protocol is a set of basic steps two or more parties perform according to a predefined or agreed-upon set of standards. A good example of a protocol that follows some unwritten but largely agreed-upon standards is a telephone conversation. When one person places a phone call, they dial the number of another party. The person on the other end answers the phone and says something akin to “Hello,” at which point the calling party responds with a similar greeting. The conversation ensues from there. When the conversation is complete, each party (usually) ends the call with some parting words such as “Good-bye.” This telephone call followed a routine protocol:

1. Say “Hello.”
2. Converse.
3. Say “Goodbye.”

In the realm of computers, a protocol follows the same concept. A protocol is a set of predefined standards that both computers must perform in the right order. For instance, for one computer to send a message to another computer, the first computer must perform the steps given in the following general example:

1. Break the data into small sections called packets (or segments, or another name depending on the layer involved).
2. Add addressing information to the packets, identifying the destination computer.
3. Deliver the data to the network card for transmission over the network.

The receiving computer must perform these steps:

1. Accept the data from the network adapter card.
2. Remove the transmitting information that was added by the transmitting computer.
3. Reassemble the packets of data into the original message.


Protocols and Binding

Many different protocol stacks can perform network functions, and many different types of network interface cards can be installed in a computer. A computer may have more than one card, and a computer may use more than one protocol stack at the same time.

The binding process is what links the protocol stack to the network device driver for the network interface adapter. Several protocols can be bound to the same card. In addition, one computer with several interface adapters—for instance, a server that must be able to communicate with both a local area network and a network backbone—can have the same protocol bound to two or more network cards.


Determining Connections

Communication between computers can be arranged in two ways:

• Using connectionless protocols

• Using connection-oriented protocols

It’s important to understand the differences between them because different Windows Server 2008 services use both types.


Connectionless Protocols

It might seem odd to talk about a connectionless protocol for networks, but you use at least two of them just about every day: radio and television. Connectionless systems assume that all data will get through, so the protocol doesn’t guarantee delivery or correct packet ordering. Think of shouting a message out of your window to someone walking by outside—there’s no guarantee that they’ll hear you, but it’s quick and easy. These optimistic assumptions mean that there’s no protocol overhead spent on these activities, so connectionless protocols tend to be fast. The User Datagram Protocol (UDP), which is part of the IP protocol suite, is an example of a connectionless Internet transport protocol. In fact, IP itself is connectionless, relying on upper-layer protocols such as TCP to provide the connection. The Domain Name System uses the UDP protocol.


Connection-Oriented Protocols

Connection-oriented systems work more like your telephone—you have to dial a number and establish a connection to the other end before you can send a message. Connection-oriented protocols pessimistically assume that some data will be lost or disordered in most transmissions. They guarantee that transmitted data will reach its destination in the proper sequence and that all data will get through. To accomplish this, connection-oriented protocols that also are considered reliable retain the transmitted data and negotiate for a retransmission when needed. Once all the needed data has arrived at the remote end, it can be reassembled into its proper sequence and passed to the higher-level protocols. This means that any application can depend on a connection-oriented transport to reliably deliver data exactly as it was transmitted. TCP is an example of a reliable connection-oriented Internet protocol. Frame Relay is an example of an unreliable connection-oriented protocol. Unreliable does not imply undependable. It just means that the protocol does not support the retransmission of lost or errored data.

For local area systems where data isn’t likely to be dropped, it makes sense to push serialization and guaranteed delivery up to higher-level protocols that are less efficient because they won’t be used often anyway. But in wide area networks like the Internet, it would simply take too much time for higher-level protocols to sort out what data had been sent and what was missing, so the transport protocol takes measures to guarantee that all the data gets through in order.