Connection Oriented or Connectionless?

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: 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.