This tutorial describes introductory concepts in data communications.
Go to the tutorial that describes the TCP/IP.
To learn about DATA COMMUNICATIONS read on!
This section covers some introductory information on the following:
Communication protocols define the manner in which peer processes communicate between computer hardware devices. The protocols give the rules for such things as the passing of messages, the exact formats of the messages and how to handle error conditions.
If two computers are communicating and they both follow the protocol(s) properly, the exchange is successful, regardless of what types of machines they are and what operating systems are running on the machines. As long as the machines have software that can manage the protocol, communication is possible.
Essentially, therefore, a computer protocol is a set of rules that coordinates the exchange of information.
The term packet is used often in data communications, sometimes incorrectly.
To transfer data effectively, it is usually better to transfer uniform chunks of data than to send characters singly or in widely varying sized groups. Usually these chunks of data have some information ahead of them ( called the header ) and sometimes an indicator at the end (called the trailer). These chunks of data are loosely called packets. In some data communications systems, "packets" refer to the units of data passed between two specific layers in a protocol hierarchy e.g. the Data Link Layer and the Network Layer of the OSI 7 layer model.
The amount of data in a packet and the composition of the header or trailer may vary depending on the communications protocol as well as some system parameters, but the concept of a packet always refers to the entire chunk of data (including header and trailer).
A host typically refers to a computer providing an information or communications service.
A gateway or router is a computer that interconnects two or more networks and passes packets from one to the other.
The gateway has an interface to each of the networks to which it is connected. Generally, congestion on connected networks is avoided by keeping local traffic confined to the network on which it originates, except when the packets are destined for another network. The gateway has the responsibility of acting as the switch that allows such packets to go from one network to another.
The process by which the paths that packets travel across a network or internetwork are chosen is known as routing.
A wide range of problems may arise in packet-based data communication. These include the following.
It is impractical to write a single protocol to handle all of these issues. The early methods were often based on a single protocol with many interacting components. The resulting software was difficult to test, debug and modify. Complex data communication schemes therefore require a family of co-operative protocols to handle all transmission tasks ( Ref. 1 ).
The modules of protocol software on each machine can be organised into what may be thought of as layers. Each layer handles a communication sub-problem. This is illustrated in Figure 1.
The services that layers provide to the layers above them may be classified into two types : connection-oriented and connectionless. In a connection-oriented service, the sender of data first establishes a logical connection with the ( prospective ) receiver of the data, uses the connection ( sends the data ), and then terminates the connection ( Ref. 2). During the establishment of the connection, a fixed route that all packets will take is defined, and information necessary to match packets to their session and defined route is stored in memory tables in the gateways ( Ref. 3 ). Connection-oriented protocols provide in-sequence delivery; that is, the service user receives packets in the order they were sent. Packet re-sequencing may have to be implemented internal to the protocol in order to achieve this, but the service user only receives correctly sequenced packets ( Ref. 4 ).
In a connectionless ( or datagram ) service there is no initial end-to-end setup for a session; each packet is independently routed to its destination. When a packet is ready, the host computer sends it on to a gateway. The gateway examines the destination address of the packet and passes the packet along to another gateway, chosen by a route-finding algorithm. A packet may go through many gateways in its travels from one host computer to another. The fact that routes are dynamically chosen means that it is possible for different packets from a single session to take different routes to the destination ( Ref. 3 ). It is also possible for packets, having traversed different routes to the destination, to arrive out of order and be passed on as such to the layer above.
Thus, connectionless networks economise on gateway memory and connection set-up time, while connection-oriented networks economise on routing decisions (which have to be redone for every packet in a connectionless network) ( Ref. 3 ).
Services can also be classified according to the quality of service that they provide to the layers above. There are two types of service quality : reliable and unreliable. A reliable service is one that endeavours never to lose data during a transfer and to provide the data error-free to the service user. In such a scheme the receiver is required to acknowledge the receipt of each item of data, to ensure that no data is lost in transit. In addition to this, the receiver checks each data item received for errors, informing the source if an error is detected and that another copy of the affected data should be sent.
The acknowledgement process required for reliable service introduces delays and overhead. There are some cases when it is more important for the service to be free of delays than for it to be one hundred percent reliable. In such situations an unreliable service may be used. An unreliable service is implemented by omitting the requirement for acknowledgements for the data received. Error checking may be done by the receiver on each block of data, and when one is detected ( even when it is only a single unknown bit ) the complete data block discarded. When an unreliable service is implemented in a given layer, reliability is typically implemented by some higher layer.
Encapsulation is the technique used by layered protocols in which a protocol accepts a message from a protocol above it and places it in the data portion of the lower level protocols message unit ( Ref. 1 ). As data move down the layers, additional information will be appended to it, and it may be segmented into smaller pieces. The encapsulation process is illustrated for the TCP/IP model in Figure 2.
Say an application process on one host has some data it wishes to send. It passes the data to the transport layer, which ( possibly ) modifies the data then attaches the transport header, T, to it and passes the resulting item to the Internet layer. The Internet layer treats the entire message received as data, may make some modifications, and attaches its own header, I, to the message. This message is then passed to the network access layer and the process is repeated. Here, the message from the Internet layer is enclosed in a physical network frame, the header from this layer being represented as N. The data are then transmitted over the medium. Note that, in each layer (below the application layer), depending on the protocol, a trailer may be appended to the message in addition to the header as is mentioned here.
On the receiving end the various headers are successively stripped off as the message moves up the layers until it reaches the receiving process. Data are reassembled ( i.e. the segmentation sub-process is reversed ) if they had been fragmented during their downward path in the transmitting system. At each layer the data at the receiving end ( after reassembly, if performed ) match data at the sending end ( before segmentation, if performed ) ( Ref. 4 ).
Data segmentation and reassembly are illustrated in Figure 3.
Standards prevent a situation arising where two seemingly compatible systems really are not. Data communication standards are created to ensure that individual products ( possibly from two independent sources ) designed to perform data communications tasks will actually be able to work together to perform these tasks. Once the standards are adhered to, the respective designers should not need to collaborate in order to achieve compatibility.
Many definitions for the term open system exist. Perhaps the best definition that can be offered here is that an open system is one for which the architecture is not a secret. The description of the architecture has been published or is readily available to anyone who wants to build products for a hardware or software platform. This definition of an open system may be applied to both hardware and software.
Open systems are in contrast to vendor-owned or proprietary systems. In such systems the vendor developes an architecture which he keeps a secret from the general population. Consequently, only persons the vendor authorizes can build products that will work with the vendor's products. Years ago, open systems were virtually nonexistent. It was customary for hardware manufacturers to have product lines which bound clients to that manufacturer for all software and hardware needs. Some companies took advantage of the captive market, charging outrageous prices or forcing unwanted configurations on their customers.
The equipment from one manufacturer that adheres to an open system standard can be used interchangeably with the equipment from any other manufacturer that adheres to that particular standard. This is so regardless of the other specifics of the vendors' respective equipment ( e.g. operating system, if this is not itself a part of the protocol ). The customer therefore has choices.
Some vendors have established data communication models based on the layered approach previously described. The vendors base their systems or products ( such as network operating systems ) on their own model. An example of this is Novells IPX/SPX protocol architecture, upon which Novell Netware, a popular network operating system, is based. As stated before, in such cases, to develop applications for a particular vendors products, one must adhere to that vendors model. This tends to lead to considerable complication when products or systems from a number of different vendors are to be integrated in some way. To address this problem, two groups concerned with the interconnection of independent systems, the ISO and DARPA, have defined commonly-used models for systems interconnection.
The International Standards Organization ( ISO ) developed a model for the connection of open systems ( systems that are open for communication with other systems ) known as the Open Systems Interconnection ( OSI ) reference model. The OSI model has seven layers : Physical, Data Link, Network, Transport, Session, Presentation, Application. The OSI model is not a network architecture in that it does not specify the actual protocols to be used in each layer ( Ref. 2 ). Rather, the model clearly defines the functions to be performed by each layer and the boundaries between each layer. The OSI model is illustrated in Figure 4.
Prior to, and concurrently with the development of the ISOs OSI model, the US Department of Defense Advanced Research Projects Agency (DARPA) was heavily involved in internetworking activity. It was such activity that resulted in the creation of the Internet. As a result of this activity, DARPA created a four layered model of data communication known as the TCP/IP suite, which has become the de facto standard for interconnection, despite the official status of the OSI model. The TCP/IP model is illustrated in Figure 5.
The TCP/IP and OSI standards are the two major open system, vendor-independent, standards in use ( Ref. 5 ).
1) COMER, Douglas, Internetworking with TCP/IP: Principles, Protocols and Architecture, Prentice-Hall, Englewood Cliffs, New Jersey, USA, 1988.
2) TANENBAUM, Andrew S., Computer Networks ( 3rd Ed. ), Prentice-Hall, Englewood Cliffs, New Jersey, USA, 1996.
3) MACKIE-MASON, Jeffrey K., VARIAN Hal R., Economic FAQs About the Internet, University of Michigan, Ann Arbor, MI 48109-1220, USA, June 1995.
4) McCONNELL, John, Internetworking Computer Systems : Interconnecting Networks and Systems, Prentice-Hall, Englewood Cliffs, New Jersey, USA, 1988.
5) HALSALL, Fred, Data Communications, Computer Networks and Open Systems (3rd Ed.), Addison-Wesley Publishers Limited, 1992.
Authored by Eric Dorman, firstname.lastname@example.org