Better to know some
... than all
As with the transport protocol, the session protocol is essentially connection oriented. It consists of three phases: a connection establishment phase, a data transfer phase, and a connection release phase. The data transfer is by far the most complex of the three, accounting for most of the service primitives. Below, we will look at various protocol-related concepts which primarily deal with the data transfer phase.
Tokens provide a mechanism for limiting the use of certain session services to one of the two session users at a time. Four tokens are provided:
* Data Token. This is used for half-duplex connections. The service user possessing the token has the exclusive right to issue S-DATA requests. Data exchanges using S-EXPEDITED-DATA and S-TYPED-DATA requests are not affected by this token. This token is irrelevant to and unavailable in full duplex connections.
* Release Token. This is used for connections which have successfully negotiated the use of the Negotiated Release functional unit. The service user possessing the token has the exclusive right to issue an S-RELEASE request. Disconnections using S-U-ABORT requests are not affected by this token.
* Sync-Minor Token. This is used for connections which have successfully negotiated the use of the Minor Synchronize functional unit. The service user possessing the token has the exclusive right to issue S-SYNC-MINOR requests. This token is irrelevant and unavailable when the Symmetric Synchronize functional unit is being used instead.
* Sync-Major/Activity Token. This is used for connections which have successfully negotiated the use of the Major Synchronize or the Activity Management functional unit. The service user possessing the token has the exclusive right to issue S-SYNC-MAJOR and S-ACTIVITY requests. Token distribution is managed by three service primitives. S-TOKEN-PLEASE is used by a service user to request the possession of one or more tokens from the other user. S-TOKEN-GIVE is used by the possessor of the token(s) to forward them to the other user. Finally, S-CONTROL-GIVE enables a service user to forward all its tokens to the other user.
Activities and Dialogue Units
An activity represents a convenient way of referring to a set of related tasks as a single entity. It has a clear beginning and a clear end, both of which are marked by major synchronization points. An activity consists of one or more atomic tasks, called dialogue units. Like an activity, the beginning and end of each dialogue unit is marked by a major synchronization point. Dialogue units (and therefore activities) can be interrupted and resumed later. A transaction issued by a banking application to an account database is an example of an activity. It may consist of one or more records, each of which represents a dialogue unit.
The activity service is based on seven service primitives for managing activities. An S-ACTIVITY-START request is issued by one service user to another to indicate the commencement of an activity. It causes the synchronization serial numbers to be set to 1. Each activity is identified by a user-specified identifier. An activity is completed by the service user issuing an S-ACTIVITY-END request, subject to confirmation. Both the activity start and end primitives involve implicit major synchronization points. A service user may interrupt an activity by issuing an S-INTERRUPT-ACTIVITY request, subject to confirmation. Data in transit may be lost, but the activity can be later resumed by issuing an S-ACTIVITY-RESUME request and specifying the identifier of the interrupted activity. A current activity can be discarded by issuing an A-ACTIVITY-DISCARD request, subject to confirmation. The rest of an activity is occupied by data transfer (using mostly S-DATA) and synchronization, which is discussed next.
The synchronization service of the session layer is based upon the use of synchronization points. These are markers that are inserted in the data flow to coordinate the exchange of data between applications. There are two types of synchronization points:
* Major Synchronization Points. These are used to delimit dialogue units, and hence activities. This service is supported by the S-SYNCMAJOR primitive. When this request is used by a service user, no further data exchange can take place until it is confirmed by the receiving user. The primitive takes two parameters: a serial number and an arbitrary block of user data.
* Minor Synchronization Points. These can be issued at arbitrary points in time, and are used for coordinating data exchange within dialogue units. This service is supported by the S-SYNC-MINOR primitive. The primitive takes one parameter (type) in addition to the two used by S-SYNCMAJOR; it determines whether the request is to be confirmed.
All synchronization points are serially numbered for ease of reference. The serial numbers are managed by the service provider. For minor synchronization, when the functional unit Symmetric Synchronize is selected instead of Minor Synchronize at connection time, two serial numbers are employed, one for each data flow direction.
Error Reporting and Resynchronization
The error reporting service is based on two primitives. S-U-EXCEPTION is issued by a service user to report an error condition to the other user. Error conditions detected by the service provider are reported to service users using the S-PEXCEPTION primitive. All data in transit is lost as a consequence. Also, unless the error is handled by the service users, no further activity is permitted. Depending on the nature of the error, it may be handled in a number of ways: issuing an S-UABORT, S-ACTIVITY-INTERRUPT, S-ACTIVITY-DISCARD, or resynchronizing.
Resynchronization is a service used for recovering from errors as well as for resolving disagreements between service users. It allows the service users to agree on a synchronization point, and start from that point. All data in transit is lost as a result. This service is supported by the S-RESYNCHRONIZE primitive, which may be issued by either user and requires confirmation. It takes four parameters: type (explained below), serial number (for a synchronization point), tokens (for distribution of tokens after resynchronization), and user data (an unlimited block). The type parameter may be one of:
* Abandon. Aborts the current dialogue by resynchronizing to a new synchronization point with a serial number greater than all previous ones.
* Restart. Re-attempts a dialogue by retreating to an earlier synchronization point, provided it is no earlier than the last confirmed major synchronization point.
* Reset. Aborts the current dialogue and sets the synchronization serial number to a new value subject to negotiation.
Session layer messages are exchanged by the transport layer using Session Protocol Data Units (SPDUs). Most primitives are implemented as one or two SPDUs (the additional SPDU is used where acknowledgment is required, i.e., in confirmed primitives). Some SPDUs are individually mapped onto TSDUs (e.g., Connect and Disconnect SPDUs). Others are always concatenated with Please- Token and Give-Token SPDUs and then mapped onto. The exact parameters depend on the type of SPDU. As indicated in the figure, parameters may be grouped together. Furthermore, parameter groups may contain subgroups.