Editing Session layer (section)

==Services==

=== Connection establishment and release ===

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.

=== Dialogue control ===

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.

=== Synchronization points and resynchronization ===

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.