The arguments about the superiority or otherwise of Connectionless and
Connection Oriented services have raged loud and long. The whole issue is
confused by the fact that the adoption of a CL service in one layer does
not preclude the adoption of a CO service in the layer above - all that is
needed is a protocol sophisticated enough to provide the enhancement. The best
example of this is TCP, which is CO and enhances the CL IP layer.
Equally, it is possible for a protocol to mask the presence of connections
in the layers below and to present a CL service to the layers above. Given
that this flexibility exists, the CO vs CL argument is really concerned
with what is most efficient and convenient for a particular application.
Let us look first at the main characteristic of a CO service - the long
term association it maintains between its two users. Figure 6.7-9 shows a
server X and three clients A, B and C. It is often desirable that X should
operate as a 'stateless' server. This means that there should be no
long-term associations between X and A, B and C. Any such associations
would be difficult to manage as X has no idea how many there will be in
advance, and the amount of state information required in each case might
eat up precious memory. Interactions between X and its clients then, are
inherently CL and require a CL communications service. If all that is
available is a CO service, then something will have to be done to make it
appear to be CL as far as X is concerned.
One way would be to set up a different connection every time X communicates
with a client, but this would be very inefficient if the data transfers are
small as the messages sent to establish and remove the connections are
essentially wasted. A way to reduce this overhead would be to leave the
connections in place once they had been established and to disconnect only
when activity on them seemed to have ceased. However this just
re-introduces the association management problem but in a lower layer. This
can cause serious problems in some operating systems. For example, in
Berkeley Unix systems each association would correspond to a so-called
<#1487#> socket<#1487#> and the number of sockets which an individual process may use is
strictly limited. It is not hard for quite modest servers to run out of
sockets when operating above CO communications services.
CO communications services are not all bad news for clients and servers
though. Often it is convenient if clients and servers receive speedy
notification of each other's demise or of a communications failure. A CO
communications service will usually inform its users if the association has
been broken for either of these reasons. With only a CL communications
service available, clients and servers would have to institute their own
polling regime and maintain the relevant state information themselves.
So far, we have looked at the impact of long-term associations on the
applications themselves. The other layer in which they are important is the
Network Layer. It is here that routing takes place, and in a complex
network many routing decisions have to be taken in order to establish
a path to the final destination. If the Network Layer service is CO then it
is common to make use of the long-term associations in the way the networks
operate. For example, a path across the networks is established when the
connection is set up and remembered for its duration. All packets belonging
to the connection then follow the same path. This means that the routing
decisions have only to be made once and all the resources the connection
needs at the intervening nodes can be reserved in advance. With CL
operation routing decisions have to be made for each packet and there is a
danger that too many packets will be routed via a particular node thus
causing 'congestion'. However, in some circumstances the fact that every
packet is routed individually is considered a virtue as this enables
packets to be routed round failed nodes. This robustness in the face of
failed nodes was one of the main reasons a CL network was chosen by DARPA.
DARPA anticipated failure of some nodes in the event of nuclear attack!
As noted previously, most CO services offer reliability guarantees as well
as long-term associations, that is, they offer Virtual Circuits (VCs).
Proponents of the VC approach argue that the reliable, sequenced,
flow-controlled service provided by a VC relieves the end-systems and the
applications from concerns about errors. This is undoubtedly true and the
sort of applications which currently run above the VC service provided by
X.25 networks exploit the inherent reliability of the service. However,
there are two major flaws in this argument:
-
The applications may not want that much reliability. They may be
willing to sacrifice reliability for increased throughput. The case
often cited is that of packetised voice; here, the loss of the odd
packet will go unnoticed, but a long delay caused by a retransmission
of a lost packet is unacceptable.
-
There are other players involved in the chain linking two applications
apart from the network service. There are the transport and higher
layers implemented in the hosts, together with infrastructure provided
by the operating system in which they are embedded. Whilst these are
usually highly reliable, they are unlikely to be completely error
free. More important are the issues raised by inter-networking. If two
highly reliable networks are linked by a relay system which is
unreliable, then the complete concatenated network is itself
unreliable. An application which is serious about reliability will
have to provide its own error control procedures to cope with this
possibility. Once these are in place, the error control procedures in
the VC oriented networks are being duplicated so they might as well be
abandoned. [#Saltzer##1#]
So which is best? The balance seems to lie with CL services and these seem
to be the choice when the choice can be freely made. However, WANs seem
likely to offer mainly CO services for some time to come. Truly 'open'
distributed systems must be able to operate above either service type.