Distributed systems and their protocols

Stuart Phillips uses the client-server model to develop a set of protocol requirements

Several models have been developed to assist with the design and understanding of distributed systems. The client-server model is used here to develop a set of requirements to be met by protocol sets used within a distributed system. An architecture within which pro- tocols may be implemented to meet the requirements developed is proposed. A number of key requirements are reviewed and areas requiring further develop- ment identified.

tern also comprises a number of computer systems attached to a common LAN, but in this case the user may be presented with an image of one large computer system. It becomes unnecessary for users to be aware on which machine their data is held or which machine or machines are executing their work. A user task may have several component parts which may be executed on different machines in a manner totally transparent to the user.

Keywords: computer networks, local area networks, wide area networks, client-server model

The availability of local area networks (LANs) has resulted in the implementation and development of distributed and networked systems by both the end- user and manufacturer. This, in turn, has increased awareness of the problems inherent in the design of such systems and has stimulated the development of standards applicable to l_AN-based products.

A clear distinction has to be made between dis- tributed systems and networked systems. The latter term describes the situation where a number of com- puter systems are attached to a common LAN which is used for the exchange of data between one computer and any other on the network. Data exchanged typically consists of file-based or short-length terminal messages when the LAN is used to allow a user to log onto a remote computer. In each case, the user sees a number of distinct systems and any user task is executed solely by one computer. The distributed sys-

Logica VTS Ltd, Drakes Way, Greenbridge, Swindon SN3 3JL, UK The paper was presented at the Localnet '83 Conference, organized by Online Conferences Ltd in New York, USA (28-30 September, 1983)

C L I E N T - S E R V E R M O D E L

Several models have been developed to assist with the design and understanding of distributed systems. One of the most versatile models is the client-server model (see Figure 1) I

The client-server model is used here to develop a set of requirements to be met by protocol sets used within a distributed system. An architecture within which protocols may be implemented to meet the requirements developed is then proposed. Finally, a number of key requirements are reviewed and areas requiring further development identified.

The essence of the client-server model is the absence of a single, central computer as a means of providing computing power. Instead, each user is equipped with a workstation providing both an access point to the facilities presented by the distributed sys- tem, and an independent processor for running applications.

In the case of an interactive application, each user typically has a dedicated processor forming a worksta- tion. This may be a simple data-entry point consisting of a small microprocessor with display and keyboard or something more sophisticated such as a scientific workstation with a powerful microprocessor, a high quality graphics display, keyboard and graphics tablet.

12

0140-3664/84/010012-05 $03.00 © 1984 Butterworth & Co. (Publishers) Ltd.

computer communications

Time - o f - doy Communicat ions

File Resource server monoger Workstat ion

Figure 1. Client-server model

The software functions wi th in each workstation act as a client to one of a number of dedicated function ser- vers. Servers can be provided to service the various needs of a user community ranging from file servers, database servers and print servers, to communicat ions servers acting as gateways to other services such as telex or teletex.

The addit ion of a resource manager allows the workstation to direct a task to a processing engine which either provides a specialized function or has a lighter loading/more powerful processor than the user's workstation. Voice annotation of documents and point- to-point voice transmission may be catered for by the addit ion of a te lephone handset and approp- riate electronics to the workstation. Software may then be provided to integrate data and speech traffic on a single LAN.

REQUIREMENTS FOR PROTOCOLS

In order to determine which protocols should be included in a protocol set for use within a distr ibuted system or to develop suitable protocols, it is necessary to identi fy the requirements of the various entities within the distr ibuted system.

The cl ient-server model results in a wide range of message types, bandwidth and latency requirements, both wi th in the I_AN system itself and outside when communicat ing via gateways and wide area networks (WAN). Messages may originate from any of the entit ies making up the system, but in general can be classified into one of three types:

• Long blocks such as program load into a processing engine or disc blocks obtained from a file server. This type of message requires a high average bandwidth but can tolerate significant delays in message delivery or channel acquisition. Messages generally travel over virtual circuits with adequate protocol control to detect missing or corrupt blocks.

• Short blocks such as connection and disconnection messages or similar control messages. These messages require a much lower average bandwidth but require high peak bandwidth. Delays both in delivery or channel acquisit ion can be tolerated but wil l inevitably lead to poor system performance. Messages travel mostly over connectionless data-

grams control led by simple protocols in order to minimize overheads. Time-critical blocks such as encoded voice data or interprocess communications (IPC). These messages require access to the total bandwidth pro- vided by the system and are intolerant of delays, however induced. Average bandwidth consumed by messages of this type is l ikely to be small. Messages may travel either via datagrams or via vir- tual circuits, but it is essential that protocol over- heads for normal operation should be minimized.

All message types share a common set of require- ments: they require guaranteed delivery or notif ication of nondelivery. Nondel ivery could be detected by the absence of a high-level acknowledgement or t imeout, but if it happened too frequently could result in loss of performance. Messages should be delivered in sequence or not at all. It is simple to detect sequence errors and recover by discarding and retransmission of affected blocks. However, the extra protocol required to perform more efficient recovery may well impose unacceptable overheads - - therefore reducing through- put. Recovery from duplicated blocks may impose similar overheads; therefore, it may be preferable to discard blocks than to deliver duplicates.

Flow control must be provided to allow a process to l imit the rate at which it receives messages. In the case of a server this is crucial, since wi thout f low control, a single user could saturate the server, thus disrupting the service provided to other users. Where messages are transferred over virtual circuits, this is relatively straightforward to achieve. It is dif f icult to impose f low control on datagram messages, however, wi thout the introduction of significant protocol overheads.

Adequate addressing has to be provided to allow routing of messages within either a workstation or ser- ver. It becomes necessary to address individual pro- cesses within a server or workstation from a remote process. Combined together over a single network, the various message types impose a collective demand for high peak bandwidth coupled with small latency for channel acquisition. This typical ly results in an overall uti l ization that is deceptively small.

The functional requirement that items within the I_AN environment should be addressable from outside the I_AN, leads to another set of requirements on the protocols used within the system. These requirements result from the need to interwork, not only with wide area networks but also with other distr ibuted systems (see Figure 2).

It is inevitable that with this method of interworking some of the previously identif ied requirements will not be achievable. Certainly, the speed difference bet- ween local and wide area networks wil l result in a lower end-to-end bandwidth than could be achieved over the local network. The quali ty of service provided by a LAN differs significantly from that of WAN. The I_AN appears as a high bandwidth, sequence-preserving system with very low error rate. The WAN, on the other hand, offers a service with much lower bandwidth,

vol 7 no 1 february 1984 13

Got~s~y 1

( ~ Wide area

IsDivSstt~ bmU tled ~ xxxj~ network

Figure 2. Interworking distributed systems

coupled with an error rate at least three orders of magnitude worse and capable of delivering blocks out of sequence. As a result, WAN protocols have to pro- vide more control over data transfer in order to main- tain a service equal to that provided by I_AN protocols. Owing to the higher quality of service provided by the I_AN, protocols within a I.AN may be made simpler and hence impose lower overheads.

Unless it is desired to impose over LANs protocols developed for use in WAN systems, these differences lead to the need to provide protocol conversion within the gateways allowing the I.AN access to other systems. The alternative would result in the overheads of WAN protocols degrading the performance of the I_AN system.

The open systems interconnection reference mod- el 2 only permits the description of gateway functions at the network level. To adhere to this principle, and to allow the distributed system to be treated as an open system, requires that the levels of service provided by the I.AN and the WAN be brought to a common level. This can be achieved by providing an enhancement to one system or a degradation to the other. Since most WANs are connection-oriented, and most LANs oper- ate in a connection-less mode, it is best to enhance the level of service provided by the I_AN. This would impose significant overheads if the I_AN system were forced to use a connection-oriented protocol for all purposes.

In order to prevent this, it is necessary to construct the gateway so that it appears to abide simultaneously by two sets of rules: the I_AN protocol rules and the WAN protocol rules. The gateway must present the remote distributed system (connected via the wide area network) as simply an extension of the local sys- tem. The degree of transparency that can be provided will, however, be limited by the lower bandwidth and increased latency of the resulting system.

Such transparency can only be achieved by provid- ing facilities for routing, address translation and pro- tocol conversion within the gateway. This leads to an architecture for the gateway as shown in Figure 3.

A set of protocol conversion and mapping functions is provided between the two halves of the gateway. The only requirement placed on the I_AN protocols by such a technique is that of providing adequate

addressing, to enable any object internal to the dis- tributed system to be addressed from outside. It is obviously advantageous to try to make the mapping used between the local and wide area networks as sim- ple as possible--an aim likely to be difficult to achieve.

Finally, it is necessary to consider the characteristics of the local area network in order to identify what requirements are placed on protocols by their underly- ing subnet. The I_AN provides many of the facilities identified as requirements, high system bandwidth, small latency and preservation of sequence. However, their ability to detect nondelivery of a message or to provide flow control depends upon the technology used in implementation. For example, with Ethernet it is only possible to ensure delivery of a message by sub- sequently receiving an acknowledgement, whereas a slotted ring provides hardware-generated ack- nowledgment at link level. Since it is required to inter- work with other systems, it is unreasonable to make protocols technology dependent. It therefore becomes necessary to provide a comprehensive net- work service that is independent of its underlying hardware. Within this service, adequate addressing and flow-control can be provided.

POSSIBLE ARCHITECTURE

It is obviously very difficult to develop a single protocol that would fulfil all types of message transfer. The alter- native is to provide several protocols that collectively provide the desired services, running over a common base. This approach is by no means unique, indeed the Xerox PUP architecture s , although developed to pro- vide internetworking rather than true distribution, adopted a similar approach.

An efficient network service should be provided to support the transfer of the various message types. Suf- ficient addressing has to be provided by this service to allow messages to be transferred to the higher layers. One approach to support this multiplexing is to introduce the concept of sockets. Sockets are simply logical subaddresses into which protocols can be plugged, an approach adopted within Berkley 4.2 BSD

Networkl (LAN)

Conversion J and

Network Network protocol I protocol 2

Subnetwork Subnetwork service I service 2

Network 2 ( WAN )

Figure 3. Gateway architecture

14 computer communications

I I I Vitual circuit

support

I I

I

Session and above

I I IPC support

I Common network services

I Link and physicQI

I I

I " Etc. }

I

Figure 4. Multiplexed transport service architecture

Unix 4. This leads to a number of transport protocols running over a common network service as shown in Figure 4.

This allows a number of transport services to be pro- vided, with each service being tailored to meet the demands of its users. Where appropriate, the transport services may add extended addressing facilities, vary- ing degrees of error detection and recovery, or other specialized facilities.

The unfortunate side effect of this flexibility is to increase the number of transport protocols that have to be supported. However, some transport protocol standards such as ECMA-72 s reference five different classes of protocol. These range from Class 0 which is identical to the teletex transport service through to Class 4, a protocol capable of functioning over a wide range of subnet capabilities by providing detailed error detection, recovery and checkpointing mechanisms. All classes currently defined are connection oriented and establish virtual circuits over which messages may be transferred.

The distributed system becomes a number of separate interworking systems, with both client and server processes having inbuilt transport services. From outside, however, the distributed system appears as a single system with a large number of addresses above the externally visible network service in the gateway. Thus, the complete address of a pro- cess within, for example, a server operating as part of a distributed system becomes the network address of the gateway plus the internal address structure of the local system, allowing any item within the system to be made externally visible.

Finally, because the layered approach to protocol design is maintained, it becomes straightforward to add a new protocol when requirements change or are extended.

FURTHER DEVELOPMENT

Although a number of transport protocols have been standardized, the majority are virtual circuit or connec- tion oriented. Certain types of message, particularly voice messages, do not require the levels of security

offered by a virtual circuit. These message types are time critical, with timely delivery being more important than data integrity. The nondelivery of small quantities of data becomes less important providing the bulk is delivered and is delivered on time. Depending upon the characteristics of the subnet, it may be more appropriate for these message types to travel via a con- nectionless or datagram system. Although there is con- siderable activity in the international standards bodies towards the definition of further transport services, there is as yet no standardized, connectionless trans- port protocol.

Similarly, there are a number of connection oriented network protocols embodied in standards. All have been developed to meet the widely different require- ments of the WAN environment. The need has been identified for an efficient and hence simple network service. Its main function is that of addressing and rout- ing rather than providing extensive error recovery. Since it is desired to run both connection and connectionless (datagram) mode transport services, the network service must be capable of supporting both methods of operation. The connectionless net- work service should guarantee the sequence and non- duplication of the datagrams transferred. As an option, it should be capable of providing guaranteed delivery or advice of nondelivery. The network service is the keystone of the architecture and deserves careful development.

The fundamental aim of the client-server model must be kept firmly in sight; it is by definition centred around the concept of transactions between client and server. The transactions may vary from requests for the time of day, through obtaining blocks of a file, to high- level database transactions. Little work has been done in defining standards for transaction protocols, yet in order for the end-user to be able to obtain multivendor systems, standards must be developed. Some work has been done in defining file transfer protocols, but these do not fit within the scope of distributed systems, belonging more naturally to networked systems.

CONCLUSIONS

A distributed system constructed around the client- server model requires protocols that provide both con- nection and connectionless modes of operation. Since there exist a wide range of differing requirements for latency, peak and average bandwidth, it is unlikely that a single set of protocols can meet all requirements.

One possible method of meeting the various requirements is to construct a system with multiple transport services multiplexed on a common network service. By this method, transport protocols may be implemented that closely match the needs of the higher levels requiring to transfer data. The presence of the network service facilitates interworking with other systems by permitting a high level of external visibility of the various processes contained within the system.

vol 7 no I february 1984 15

Considerable development work is required to define suitable protocols for use within the model and obtain international standards approval for them. It is likely to be some considerable time before this aim is met.

REFERENCES

1 Abraham, S M and Dalai, Y K 'Techniques for decentralised management of distributed systems'

Proc. Compcon Conf. (Spring 1980) pp 430--437 2 ISO/TC97/SC16/DP7498 Basic reference model,

open systems interconnection ISO, Switzerland, (1980)

3 Boggs, D F, Shoch, T F, Taft, E A and Metcalfe, R M PUP: an internetwork architecture Xerox Technical Report, CSL 79-10 (July 1979)

4 Berkeley4.2 BSD Unixsystem manual University of Berkeley, California, USA (1982)

5 ECMA-72 transport protocol European Computer Manufacturers Association, Geneva (September 1982)

T h e In te rna t iona l journa l p u b l i s h e d by But te rwor th Sc ien t i f i c L imi ted - - J o u r n a l s Divis ion in assoc ia t ion wi th t h e E u r o p e a n C o m p u t e r M e a s u r e m e n t A s s o c i a t i o n

published quarterly

Coverage:

• measurement applications • measurement technology • analytical methods

• modelling techniques • capacity planning • performance theory

For further details please contact: Christine Mullins Butterworth Scientific Limited -- Journals Division PO Box 63 Westbury House Bury Street Guildford Surrey GU2 5BH England Telephone: 0483 31261 Telex: 859556 SCITEC G

16 computer communications