Better to know some... than all
|
||||||
|
The Session LayerThe session layer provides a structured means for data exchange between user processes (or applications) on communicating hosts. This layer uses the term session instead of connection to signify the point that communication is studied from an application rather than a host point of view. More specifically, a session imposes a set of rules on the way applications should communicate. Also of interest are: how a session is negotiated between two applications, the synchronization and control of message exchanges between applications (e.g., how they should take turns), the context of messages (e.g., whether they relate to records from a database or keystrokes on a terminal), dealing with transport failures, and the bracketing of messages as required by some applications. We will first look at the session service primitives and their use by higher layers. Then we will describe the session protocol and related issues, such as the use of tokens in activities and dialog units, synchronization, error handling, and the structure of session messages. Finally, we will list a number of session layer standards. Session ServicesAs with earlier layers, the session services are defined in terms of session primitives, of which there are many. Addresses refer to Session Service Access Points (SSAP); these typically are the same as their corresponding transport addresses. Quality Of Service (QOS) denotes a set of parameters which collectively describe the quality of the session service requested by the user. These are essentially the same as those used for the transport layer, with the addition of a few new ones (e.g., concatenation of service requests). Result denotes the acceptance or rejection of the connection. Requirements is used for the negotiation and selection of functional units (described below) that are to be effective for the duration of the session. Serial number denotes the initial serial number used for synchronization purposes. Token refers to the side to which the tokens are initially assigned. User data denotes actual user data provided by the service user for transfer by the service provider. Session service user A first requests a (half-duplex) connection, which is indicated to session service user B by the service provider. B responds to the request and the service provider confirms with A. Two normal data transfers from A to B follow, with a minor synchronization cycle in between. B then asks A for the data token, which A hands over to B. B sends some data to A, and then asks for the session to be aborted.  |
|||||