The two primary types of services which are made available by a particular network layer and which actually are also useful classifications for many non-technical types of service industries are known as connection-oriented and connectionless communication.
Connection-oriented Services
One of the easiest ways to understand what a connection-oriented protocol is would be to think of a very familiar service upon which it's based: the telephone system. When I pick up the phone, I have an open circuit, and the dial tone carrier signal allows me to connect to a destination of my choosing.
Given valid input parameters, the service:
- Establishes the connection.
- Allows me to utilize the connection.
- Tears down the connection when I'm done using it.
The primary difference between this method and that of a connectionless service is that in a connection-oriented system, all of my communications are taking place on the same transmission channel. On the other hand, with a connectionless service, all transmissions are independently routed, and perhaps re-assembled in some order at the other end -- the service in between has no inherent responsibility for ensuring ordinality -- it need only assure that each transmission gets delivered from its source to its destination.
Connectionless Services
A good analogy for a connectionless service is the process of sending letters through the postal system. Each transmission (the "letter") contains the full destination address and is processed independent of related messages. As described above, the service has only to ensure that each reaches its host within certain time parameters. Unlike a connection-oriented service, the system has free reign on what happens enroute between the sender and receiver:
- a message can be delayed to ensure another arrives first.
- widely different channels of communication can be used for transmitting messages.
- a message can be handed off to a trusted third party in the distribution network.
- a message can be intercepted by a third party, copied or logged, and passed on to the intended receiver.
These operations are basically impossible for a connection-oriented service.
Types of Services Available in TCP/IP and OSI:
The OSI Reference Model provides for both connection-oriented and connectionless communication at the network level. However, it supports only connection-oriented communication at the Transport layer. It became obvious after the initial design of OSI that allowing both types of traffic at the transport layer was important even though it violated the idea of data abstraction which were central to the design of OSI.
TCP/IP, on the other hand, supports only connectionless traffic at the Network layer, but supports both modes in the Transport layer. This allows for simple request-response protocols to be easily implemented, though it complicates things somewhat for the user. At the Transport level, TCP, the Transmission Control Protocol (a connection-oriented service) as well as UDP, the Universal Datagram Protocol (a connectionless service) are provided.
Quality of Service
Reliability of connections achieved through connectionless and connection-oriented protocols is another major concern. All protocols are not created equal, and sacrifices in reliability can be made in exchange for greater speed, or vice versa. Often the trade-offs are worth it, assuming that we're attempting to fit our task intelligently into the capacities of the protocol.
Sometimes it's necessary for a "handshake" process to occur, especially if we need to authenticate each piece of traffic from a sender, but in many cases (such as streaming video), the performance hit involved is simply unacceptable. Not all applications require connections, and it's naive to think of either protocol as superior to the other.
In certain cases, it's not even necessary to ensure that a message gets sent, so long as the chance that it was received is high enough (think of the high-volume email transmissions of spammers). Consider how difficult and time-consuming it would be if each spam message had to be acknowledged by the receiver and tracked by the spammer!
sources:
- Tannenbaum, Andrew Computer Networks: Third Edition Prentice-Hall 1996.
(a node your library production)