Session Layer Services: Data Exchange & More
Services Offered: Level Meeting & Data Interchange
The primary purpose of the meeting is to facilitate data exchange. A session, functioning as a transport connection, follows three phases: establishment, use, and release. Primitives provided to the presentation layer for these phases closely resemble those provided to the session layer for managing transport links. Often, the session layer invokes transport primitives to ensure proper execution.
However, there are key differences between session and transport data exchange:
- Sessions and transport connections end differently. Transport connections end with
T-DISCONNECT.request, an abrupt release that may cause data loss. Sessions end withS-RELEASE.request, resulting in an ordered release that *never* loses data. - The amount of data differs. The transport layer has two logically independent data streams: normal and expedited data. The session layer, besides these two, also includes typed data and data capacity.
Dialogue Management
While all connections in the OSI model are split, situations may arise where higher-layer software is structured such that users are expected to take turns in half-duplex communication. Dialogue management is a session layer service that keeps track of whose turn it is to speak and enforces this. When initiating a session, the operation mode (duplex or half-duplex) is selected. The initial negotiation determines who will first transmit data, as only the user with the ‘token’ can stream while the other remains silent. When finished, the token is passed to the interlocutor.
Exception Notification
This is a general-purpose mechanism for reporting unexpected errors. If a user encounters a problem, they can notify their correspondent using the SU-EXCEPTION-REPORT.request primitive. Some user data, typically explaining the issue, can be transferred using this primitive. The service provider may also generate an SP-EXCEPTION-REPORT.indication primitive to inform the user about internal session layer problems or issues originating from the transport layer or below. These notifications contain a field describing the nature of the exception. The decision on what action to take, if any, rests with the user.
Synchronization
Synchronization is used to restore session entities to a known state in case of an error or disagreement. While the transport layer is designed to mask communication errors, the session layer handles error recovery. The session user can divide text into pages and insert synchronization points between them. In case of a problem, it’s possible to restore the session state to a previous synchronization point. The issuer must retain the data for as long as necessary. There are two types of synchronization points: major and minor, each with its own primitives. Units bounded by major synchronization points are called *dialogue units*, representing logically significant work segments.
Activity Management
Activity management divides the message flow into logical units called *activities*. Each activity is completely independent. The choice of what constitutes an activity is up to the users, not the session layer. The session layer ensures that when a user makes a request using the S-ACTIVITY primitive, the other user receives the prompt, handling only the execution of the primitive, not its meaning or use. Activities are closely related to synchronization points. Starting an activity is equivalent to a major synchronization point. Once an activity begins, it’s impossible to resynchronize to a point before the start of that activity. Within an activity, additional major or minor synchronization points can be established.