The session layer services are provided by a functional unit set, which constitutes the session layer. The session layer can be understanding as a general-purpose tool kit out of which the user selects the tools to be used.
The functions provided by the session layers are as follows:
The session layer’s primary function is to provide and establish connections between communicating users, known as sessions. It can transfer the data over these sessions in a reliable and orderly way.
It can settle a session between two computers for communication, file transfer, remote login, or other purposes. It can establish Connection-oriented and connectionless sessions, but a connectionless session is of no use for the session layer user-oriented.
The session connection resembles a transport connection. A request for session establishment must ensure the establishment of a transport connection. When the session is released, the transport connection is also released. There are three ways of mapping sessions onto transport connections.
One to One mapping, many to one mapping and one too many mapping. In one to one mapping, one session uses one transport connection. In many to one mapping, consecutive sessions use the same transport connection, and in one to many mapping, one session spans multiple transport connections.
It is the essential function of the session layer. The exchange of data between user entities can either be a two-way alternate (half-duplex) or two ways simultaneous (full-duplex). In the half-duplex mode, only one user has the exclusive right to initiate the transfer of data. In contrast, in another case, simultaneous data transfer is possible in both directions.
In some cases, the session connections are full-duplex, but the upper layers sometimes communicate in half-duplex modes. In such cases, the session layer has to keep track of whose turn it talks and is known as dialog management. Data tokens are used to implement dialog management.
When a half-duplex session is established, it is determined by initial negotiations which side has received the token first. The user having a token can transmit data. While the other one remains silent. When the token holder has finished transmission, it passes the token to other users, and once it is received to another user, it can now transmit data. In the case of full-duplex operation, no token is used for data transmission.
For releasing the session connection, one of the following four variations are used:
In user, abort session connection may be released rather than aborted by any one of the users. Similarly, in provider abort, the session is aborted by the provider or providers. There is a two-way interaction between users; hence before releasing the connection, the transmitted data is delivered to their destination.
For releasing this way, any user or provider may request for release of the session connection, and the other user has to accept the release. In a negotiated release, the user with a release token can initiate a request to release the session connection. The other user can take or refuse the session release request depending on conditions and requirements. If it is accepted, the session is released.
In user abort and provider abort, the session is aborted without informing the other entities to lose the transmitting data. At the same time, this is not the case with orderly release and negotiated release. The provider abort occurs in case of fatal errors.
Synchronisation assures the same state of interaction between session service users at any point in time. If an error or disagreement occurs, the session entities are moved back to a known state. This service is provided because the transport layer masks only communication errors and not the upper layer errors.
For achieving this goal, synchronisation points are inserted into interactions. The sender inserts a serial number as a synchronisation point, and the receiver confirms the receipt by sending back the serial number.
It is different from acknowledgement as the acknowledgement refers to the receipt of the protocol data unit. Major and minor synchronisation points are used to make the communication instances into a dialog unit or within the dialog unit.
The former is confirmed immediately while the later may not. A standard serial number is used for both of them, and their respective tokens control them.
Sometimes it is required for the state of dialog to be restored to some previously defined state. This is known as backward synchronization or resynchronisation. The session layer entities also provide it.
There are three options of resynchronisation: Set, abandon and Restart. The sending session user continues to hold data for achieving synchronisation as long as it might need it. When resynchronisation occurs, all the tokens are restored to the original positions when the synchronisation point was set.
The session layer allows the user to distinguish between activities that are performed during a session. The user can split the message stream up into logical units. These logical units are called an activity, and this splitting of the message stream into activities is known as activity management.
One of the features of the session layer is its reporting facility for unexpected errors. It is a general-purpose mechanism that allows reporting for troubles to peer if the user falls into it. This reporting is equally applicable to user detected errors, protocol errors or some other unexpected errors.