Types of Network Communication Services

Connection-oriented service

This type of service is modeled after the telephone system. To use a connection-oriented network service, the service user first establishes a connection, uses the connection, and then releases the connection. In this type of service, the messages/ data arrive at the receiving end in exactly the same order in which they were transmitted.

Each service is characterized by a quality of service. Some services are reliable as they never lose data. Usually, a reliable service is implemented by having the receiver acknowledge the receipt of each message, so the sender is sure that it arrived. The acknowledgement process introduces overhead and delays, which are often worth it but are sometimes undesirable.

A typical situation in which a reliable connection-oriented service is appropriate is file transfer. Here it is necessary that all the bits of the file arrive correctly and in the same order they were sent. One would not want a file transfer service which occasionally scrambles or loses a few bits, even if it is much faster.

For some applications, the delays introduced by acknowledgements in a reliable connection-oriented case, are unacceptable. One such application is digitized voice traffic. It is preferable for telephone users to hear a bit of noise on the line or a garbled word from time to time than to introduce a delay to wait for acknowledgements. Similarly, when transmitting a video film, having a few pixels wrong is no problem, but having the film jerk along as the flow stops to correct errors is very irritating.

Reliable connection-oriented services can be message sequences or byte streams.

Message sequences – Here message boundaries are preserved. When two 1-KB messages are sent, they arrive as two distinct 1-KB messages, never as one 2-KB message.

Eg:- Pages of a book sent over a network to a photo type setter. Each page is sent as a separate message and the message boundaries must be preserved here.

Byte streams – Here the connection is simply a stream of bytes, with no message boundaries. When 2K bytes arrive at the receiver, there is no way to tell if they were sent as one 2-KB message, two 1-KB messages, or 2048 1-byte messages.

Eg:- A terminal logging into a remote time-sharing system. Here a byte stream from the terminal to the computer is all that is needed.

Connection-less service

This type of service is modeled after the postal system. Each message (data packet) carries the full destination address, and each one is routed through the system independent of all others. Normally, when 2 messages are sent to the same destination, the first one sent will be the first one to arrive. However, in a connection-less type service it is possible that the first one sent may be delayed so that the second one arrives first.

Not all applications require connections. An email, and more particularly junk mail need not be sent in a connection-oriented fashion. Further 100 percent reliability in delivery is also not essential, specially if it costs more. We just need a way to send a single message that has a high probability of arrival, but no guarantee.

Unreliable connection-less service is often called datagram service, in analogy with telegram service, which also does not provide an acknowledgement back to the sender.

In certain situations, the convenience of not having to establish a connection to send one short message is desired, but reliability is essential. For such situations we have acknowledged datagram service. It is like sending a registered letter and requesting a return receipt. Eg:- Registered mail.

Yet another type of connectionless service is the request-reply service. In this service the sender transmits a single datagram containing a request – the reply contains the answer. Eg;-Database query.

Service Primitives

A service is formally specified by a set of primitives (operations) available to a user or other entity to access the service. These primitives tell the service to perform some action or report on an action taken by a peer entity.

The service primitives are divided into 4 classes:

1. Request => An entity wants the service to do some work
2. Indication => An entity is to be informed about an event
3. Response => An entity wants to respond to an event
4. Confirm => The response to an earlier request has come back

To illustrate the use of primitives, consider how a connection is established and released. The initiating entity does a CONNECT.request which results in a packet being sent. The receiver then gets a CONNECT.indication announcing that an entity somewhere wants to set up a connection to it. The entity getting the CONNECT.indication then uses the CONNECT.response primitive to tell whether it wants to accept or reject the proposed connection. The entity that issued the initial CONNECT.request finds out what happened via a CONNECT.confirm primitive.

Primitives can have parameters. For example, the parameters to a CONNECT.request might specify …

• the machine to connect to
• the type of service desired, and
• the maximum message size to be used on the connection.

The parameters to a CONNECT.indication might contain …

• the caller’s identity
• the type of service desired, and
• the proposed maximum message size

Services can be either confirmed or unconfirmed. In a confirmed service, there is a request, an indication, a response, and a confirm.

In an unconfirmed service, there is just a request and an indication.

CONNECT is always a confirmed service. DATA transfer may be conformed or unconfirmed. DISCONNECT is unconfirmed.

An example to illustrate the concept of service primitives - Inviting a person for a seminar over the telephone.

Illustration Diagram