 | This articleneeds additional citations forverification. Please helpimprove this article byadding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Session layer" – news ·newspapers ·books ·scholar ·JSTOR(October 2009) (Learn how and when to remove this message) |
| OSI model bylayer |
|---|
In the seven-layerOSI model ofcomputer networking, thesession layer islayer 5.
The session layer provides the mechanism for opening, closing and managing asession between end-user application processes, i.e., a semi-permanent dialogue. Communication sessions consist of requests and responses that occur between applications. Session-layer services are commonly used in application environments that make use ofremote procedure calls (RPCs).[2]
An example of a session-layer protocol is theOSI protocol suite session-layer protocol, also known as X.225 or ISO 8327. In case of a connection loss this protocol may try to recover the connection. If a connection is not used for a long period, the session-layer protocol may close it and re-open it. It provides for eitherfull duplex orhalf-duplex operation and providessynchronization points in the stream of exchanged messages.[3]
Other examples of session layer implementations includeZone Information Protocol (ZIP) – theAppleTalk[4] protocol that coordinates the name binding process, and Session Control Protocol (SCP)[5] – theDECnet Phase IV session-layer protocol.
Within the service layering semantics of the OSI network architecture, the session layer responds to service requests from thepresentation layer and issues service requests to thetransport layer.
At the minimum, the session layer allows the two sides to establish and use a connection, called a session, and allows orderly release of the connection.
In the OSI model, the transport layer is not responsible for an orderly release of a connection. Instead, the session layer is responsible for that. However, in modern TCP/IP networks, TCP already provides orderly closing of connections at the transport layer.
After a session connection is released, the underlying transport connection may be reused for another session connection. Also, a session connection may make use of multiple consecutive transport connections. For example, if, during a session, the underlying transport connection has a failure, the session layer may try to re-establish a transport connection to continue the session.
The session layer may provide three different dialogue types - two way simultaneous (full-duplex), two way alternate (half-duplex), and one way (simplex). It also provides the mechanisms to negotiate the type of the dialogue, and controls which side has the "turn" or "token" to send data or to perform some control functions.
Dialogue control is not implemented in TCP/IP, and is left to the application layer to handle, if necessary. In the widely used HTTP/1.1 protocol, the client and the server typically work in a half-duplex way. HTTP/1.1 also supportsHTTP pipelining for full-duplex operation, but many servers/proxies couldn't handle it correctly, and there was no dialogue negotiation mechanism to check whether full-duplex is usable or not, so its support was eventually dropped by most browsers.
The session layer may also allow the two sides to insertsynchronization points into the dialogue, and allow them to do aresynchronization, which aborts the current transmission, sets the synchronization point to a certain value, and restarts transmission from that point.
This may be used in real-time audio/video transmission. Synchronization points can be used to insert timestamps to the data flow, and a resynchronization may be used to reset the transmission to start from a new timestamp. For example, if the video stream lags behind the audio stream too much, the receiving side may issue a resynchronization request on the video stream, restarting its transmission from a later timestamp.
This may also be used by the application to do checkpointing. Synchronization points can be used to indicate that a checkpoint has been committed by the application, and after an application crash or a power failure, a resynchronization can be used to indicate that the application has recovered from a checkpoint and the transmission can be resumed from that point.
This may also be used to interrupt / resume a dialogue at any time, not due to an application failure, but as planned by the application. The application may interrupt a dialogue, start another dialogue in the same session, and resume the previous dialogue in the same session or in another session.
The session layer may also provide explicit support for managing multiple interruptible dialogues over one or more sessions. These dialogues are calledactivities. Activities can be interrupted and resumed explicitly. Compared to implicitly interrupting and resuming dialogues by resynchronization, activity support gives the application simpler control of these dialogues.
TheTCP/IP reference model does not concern itself with the OSI model's details of application or transport protocol semantics and therefore does not consider a session layer. OSI's session management in connection with the typical transport protocols (TCP, SCTP), is contained in thetransport-layer protocols, or otherwise considered the realm of theapplication layer protocols. TCP/IP's layers aredescriptions of operating scopes (application, host-to-host, network, link) and not detailedprescriptions of operating procedures or data semantics.
