Connected: An Internet Encyclopedia
Protocol

Up: Connected: An Internet Encyclopedia
Up: Topics
Up: Concepts
Prev: Network Management
Next: ASCII Request/Reply Protocols

Protocol

Protocol

Douglas Comer defines a protocol as "a formal description of message formats and the rules two or more machines must follow to exchange those messages."

Protocols usually exist in two forms. First, they exist in a textual form for humans to understand. The majority of Internet protocols are distributed as RFCs, which can (and should) be read to understand the protocols' design and operation. Second, they exist as programming code for computers to understand. Both forms should ultimately specify the precise interpretation of every bit of every message exchanged across a network.

Protocols should exist at every point where logical program flow crosses between hosts or programs. In other words, we need protocols every time two different computers or programs need to agree on how they will communicate information between them. Every time we want to print something on a network printer we need protocols, otherwise there will be no agreement on how to pause the sending computer's output if the printer falls behind. Every time we want to download a file we need protocols, otherwise the computers will be unable to agree on which file should be downloaded. Every time we want to save our work on disk, we don't need protocols - unless the disk is on a network file server.

Usually multiple protocols will be in use simultaneously. For one thing, computers usually do several things at once, and often for several people at one. Therefore, most protocols support multitasking. Also, one operation can involve several protocols. For example, consider the NFS (Network File System) protocol. A write to a file is done with an NFS operation, that uses another protocol (RPC) to perform a function call on a remote host, that uses another protocol (UDP) to deliver a datagram to a port on a remote host, that uses another protocol to delivery a datagram on an Ethernet, and so on. Along the way we made need to lookup host names (using the DNS protocol), convert data to a network standard form (using the XDR protocol), find a routing path to the host (using one or many of numerous protocols) - I think you get the idea.

Initially, protocols were specified using an explicit description of how every bit in a binary message should be interpreted. For example, RFC 791 Section 3.1, part of the IP Protocol, specifies the exact interpretation of every bit in the IP packet header. In more recent years, it has become popular to specify protocols using a higher-layer description to avoid such tedious details, while avoiding ambiguity. Two popular means of doing this are ASCII Request/Reply and ASN.1.

In addition to specifying message formats, a protocol may also specify when certain messages are allowed to occur. For example, a file transfer protocol may not allow a READ message until after an OPEN message has been successfully transferred. State diagrams are the most popular way to do this (see RFC 793 Section 3.2 for an example), though ITU-T standards use a formal graphical syntax called SDL.


Next: ASCII Request/Reply Protocols

Connected: An Internet Encyclopedia
Protocol