 |
This article needs additional citations for verification. Please help improve this articlebyadding 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) |
In the seven-layer OSI modelofcomputer networking, the session layerislayer 5.
The session layer provides the mechanism for opening, closing and managing a session 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 of remote procedure calls (RPCs).[2]
An example of a session-layer protocol is the OSI 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 either full duplexorhalf-duplex operation and provides synchronization points in the stream of exchanged messages.[3]
Other examples of session layer implementations include Zone Information Protocol (ZIP) – the AppleTalk[4] protocol that coordinates the name binding process, and Session Control Protocol (SCP)[5] – the DECnet Phase IV session-layer protocol.
Within the service layering semantics of the OSI network architecture, the session layer responds to service requests from the presentation layer and issues service requests to the transport 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 supports HTTP 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 insert synchronization points into the dialogue, and allow them to do a resynchronization, 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 called activities. 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.
The TCP/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 the transport-layer protocols, or otherwise considered the realm of the application layer protocols. TCP/IP's layers are descriptions of operating scopes (application, host-to-host, network, link) and not detailed prescriptions of operating procedures or data semantics.
