The object oriented approach to system design is applicable to most large
computer systems. One of its strengths is that the implement of an object
has complete freedom to choose appropriate algorithms to achieve her
purpose so long as the end result is an object which conforms to
specification. For communication services the situation is a little
different since the objects themselves are distributed;
A service A is implemented by enhancing service B. This
enhancement is performed by a pair of processes X and Y, one in each of the
communicating systems. It is quite likely that X and Y will have been
implemented by different people. If this is to work, then the distributed
algorithm which defines the interactions between X and Y must itself be
standardized. These distributed algorithms are called 'protocols, and the
processes which implement them at each end of a communications service are
called 'protocol entities, or 'entities' for short.
#figure1396#
Figure: Communicating Processes
Communications protocols may be extremely complex specifying complicated
message sequences to recover from loss or mis-sequencing of messages.
Alternatively, they may be very simple, specifying little more than the
format of the messages which will be exchanged. Naturally, the degree of
complexity depends mainly on the amount by which the underlying service
needs to be enhanced.
Drawing nested boxes to any depth strains both typography and the reader's
eyesight. Instead, it is conventional to represent the boxes as in figure
#fn63#1401> and to stack these vertically to illustrate the complete architectural
model (#fn64#1402>). Figure i#fn65#1403> shows a pair of similar protocol entities
(peer entities) exchanging messages with each other in order to implement
the distributed algorithm. The net effect of all this is to provide the
service represented by the broken box. The messages exchanged between the
service users and provider are shown by the vertical arrows. The messages
exchanged by the peer entities are, of course, transported through the use
of some subordinate service, thus each service provider is also a user of
the service below (except for the bottom one of course!).
#figure1404#
Figure: Layering as Model of Nesting
#figure1409#
Figure: ISO OSI 7 Layer Model
It is worth introducing some OSI jargon here. The vertical arrows in Figure
6.5 represent 'service primitives' - the requests and indications that the
service reports. In most cases there will be some data associated with
these primitives which is being passed across the service interface. An
individual lump of this data is called a 'Service Data Unit' (SDU).
The horizontal arrows in Figure 6.5 represent the protocol messages that are
formed by the protocol entities and exchanged with each other. These
messages consist of two types of information; 'Protocol Control
Information' (PCI) - which consists of the sequence numbers, checksums
etc. required by the operation of the protocol; and 'User Data' - the data
(submitted in SDUs) which the service is supposed to be transporting.
Together, the PCI and the User Data constitute a 'Protocol Data Unit'
(PDU).
There is obviously a relationship between SDUs and PDUs. This is not
necessarily simple as there may be good reasons to split one SDU into
several PDUs or to lump several PDUs into one SDU when requesting the
service below.