The services described in the examples above have appealingly simple
behaviors. Unfortunately, practical communications services often have
rather more complex behaviors and a number of irritating questions must be
asked about them. For example:
-
What guarantee does the service give that the data will be delivered
at all?
-
What guarantee does the service give that the data will not be
corrupted on the way?
-
What guarantee does the service give that the data will not be
delivered to the wrong address?
-
Is data submitted in one lump guaranteed to be delivered in one lump?
-
Is there any chance that a message will be duplicated and delivered
twice?
-
Does the service offer confirmation of receipt (like certificate of
postage)?
-
Does the service offer confirmation of delivery (as in recorded
delivery)?
-
Will successive data requests be delivered in the order they are
submitted?
-
How long will delivery take?
-
Are there constraints on the size of messages?
All these (and other) questions must be answered before the service
definition can be considered complete. The answers define the Quality of
Service (QoS) being offered. Often, the purpose of the enhancing a
primitive service is to remove some of this complexity so that the
top-level service provides a nice clean, simple and easily understood
service that the distributed system designer can use to transport her
messages. This is related to the approach of `selective transparency' discussed
in chapter 1, used in distributed applications
design There are two main views about what this nice, clean, simple and
easily understood service should look like.
In Europe, public data communications services have been developed by the
PTTs (Post, Telephone and Telegraph authorities). It has been natural for
them to think of data communications as being analogous to the telephone
system and so the communications service they offer has a strong
resemblance to the telephone service. Their service changes state in the
course of the communication. Initially it is in an idle state
in which only 'connection requests' are allowed (the telephone is on the
hook and all you can do is to lift it up and dial). Once a connection has
been established we enter the connected state. Here you can request 'data
transfers' (speak) or 'disconnects' (put the phone down). Quite reasonably,
this type of service is called 'Connection Oriented' (CO).
The key feature of a CO service is the existence of shared state
information between the two ends of the communication when in the connected
state. At the minimum his information tells us that two identified users (A
and B say) are bound to a particular connection (c say). A then knows that
any data it sends on c will be delivered at B (ignoring errors and other
difficulties for the moment), and vice versa.
In practice, the CO service offered by the PTTs involves the two users in
rather more shared knowledge and offers amongst other things:
-
Guarantees that data will be delivered in sequence and un-corrupted.
-
The ability of either end to control the rate at which data is sent by
the other ('flow-control').
-
Confirmation of delivery.
This sort of service is supposed to resemble that which would be provided
by a highly reliable dedicated physical circuit. Consequently, it is called
a Virtual Circuit (VC) service (see Figure 6.6).
#figure1419#
Figure: Connection Oriented Network Service
In contrast, the simpler service of Figure 6.7 is called 'Connectionless'
(CL). Here there is a single state and only one type of request - 'data
transfer'. CL services have been supported by two main groups; the
purveyors of Local Area Networks and disciples of the Internet community.
#figure1424#
Figure: Connectionless Network Service
We shall return to the CL vs CO argument later.