Table of Contents
The Session Layer
Session Layer of the OSI model
The session layer unlike the other layers is much less complicated in the sense holds fewer responsibilities; thus, having to focus on fewer things!
The session layer’s primary responsibility is to open an active dialog with a communicating system. The way it handles that session and how it does so is in the scope of the session layers implementation. Talking about its hierarchy, it sits above the transport layer and below the presentation layer of the OSI model.
It is to be noted, the OSI is just a reference model and having said that; each layer only talks about its contribution to the network communication. It is no compulsion to have them addressed as is in the OSI model. The TCP/IP protocol suite has wrapped the session, presentation and the application layer into one single layer i.e. the application layer.
Responsibilities of the Session Layer
Dialog Control
The dialog control is one of the primary responsibilities of the OSI model. It enables two systems to get into a dialog and exchange key information. This can either be Half-Duplexed communication or Full-Duplexed communication.
Half-Duplex –> One way communication at a time.
Full-Duplex –> Two way simultaneous communication at at time.
Synchronization
Synchronization is another important implementation of the session handler. The reason this is used is to have some sort of a checkpoint amidst its data transfer. The reason to have these checkpoints is simple; it’s for error handling.
In case one of the bytes is lost in a big stream of data transfer; the data can be resent from the missed checkpoint. It makes sense; don’t you think?
Thus, sync points are implemented and fitted into the packet of the session layer. Since this is a completely software handled layer; the parameters can be tweaked to the users necessary.
Other error handling techniques are also used at this layer to prevent any loss of data during its active dialog session. There are numerous protocols in place to govern and enable this; which will not be discussed in this article.
Token Management
One additional responsibility of the layer is token management. It simply means; to prevent two parties to perform or access the same set of data at the same instance of time. This could be achieved by adding add some sort of a mutex lock before performing an important task!
In this case tokens are passed between the communicating parties and the one possessing it performs the critical task at the instance of possession. This is similar to that of an OS event. It cannot mean that ; one system holds on the token indefinitely; there needs to be a synchronized exchange of these tokens in order for the session to be working as expected. This would be a design consideration!
That’s it for this article; hope you had fun reading and there is a take away from this.
Thanks for reading!
