The Session Services according to GILT for SUNET. ================================================= Author and implementor: Thomas Sjöland, SUNET IMI/TTDS Date: 83 06 26 Contents: 1. The Session Service. A Brief Overview. 2. The Transport Service Interface. 3. The Extended Buffer Pool System. 4. The User Interface for the Session Services. 1. The Session Service. A Brief Overview. -------------------------------------- The Session Service as specified by both CCITT and ISO is a document oriented service wherein the user can control the transfer of structured documents on an end-to-end basis by using a transport connection on the lower communication level. The GILT Session Service as described in the document COST-11- bis/GILT/SES/002 is a superset of the CCITT recommendation S.62 of Control Procedures for the Teletex Service. The extensions to S.62 are carefully made to make it possible for a Teletex terminal embodying only the S.62- part of the protocol to take part in communications with a GILT Session Entity. One protocol primitive and ten parameters, which are coded as private parameters according to the S.62 description, have been added to enhance the quality of the GILT Session Service in comparison to S.62. The rules of the GILT session are stated in the above mentioned document. The rules of the CCITT recommendation S.62 are described in the "Yellow Book". 2. The Transport Service Interface. -------------------------------- The Session Service is realized as the sending of S.62 protocol primitives (+ GILT extensions) to another user through the use of a transport connection which in turn is realized through some public data-network. To enable communication with the Transport Service of SUNET, I have designed a procedural interface that can handle a set of connections simultaneously where the connections can be initiated by either of the two participating parties. The state of the connections is controlled by the interface, thereby eliminating the possibility of any exchange of illegal sequences of transport protocol unit to the Transport Protocol Handler. The Transport Service implementation as such is described in a previous SUNET-report. Therefore I will only present the higher Transport Interface that is intended for use by different application programs, e.g. the Session Protocol Interface. This interface gives a user of the transport layer access to the basic functionality of it without the need of an extensive state automaton. The TCEPs (Transport Connection Endpoints) on this level are considered to be in either of three states: closed, listening or open. The phases of connection and disconnection as well as the handling of incoming credit packets are handled implicitly by the procedures which give these functions: a) Try to establish a transport connection (with timeout for failure). b) Try to establish a transport layer listener. c) Listen for incoming calls on a listener-TCEP with time_out. If an incoming call is detected during this time, the call is answered positively and the user is informed on the identity of the remote party. d) Shut down a connected TCEP and deallocate its message passing channel. e) Try to send a (TSDU) Transport Service Data Unit. If credits are available as large a part as possible is sent. The rest is stored in a local queue and is sent when credits arrive later on. If the parameter careful_send is true the attempt fails if an incoming data-packet is available on the message passing channel. The length of the queues both for incoming packets and outgoing packets waiting for credits is maximized to avoid deadlocks due to lack of buffer space. f) Try to receive incoming data on a specified previously opened TCEP. The attempt ends either with failure or with the receipt of a tsdu from the remote party within the specified time. Expedited data cannot be handled by this interface but are considered to be protocol errors if occurring. The state referred to in the table below is the state of a Transport Connection Endpoint, which is a Transport Connection as seen from one of its two users. Primitive Precondition State Resulting State ========== ================== =============== Success: Failure: t_init_interface -- all closed -- t_est_conn -- open closed t_est_listener -- listening closed t_listen listening open listening/closed t_send open open open/closed t_receive open open open/closed t_give_cdts open open closed shut_tcep -- closed -- 3. The Extended Buffer Pool System. -------------------------------- The system for interprocess communication described in the previous report is not enough to facilitate the easy programming of the session service. To make the programming more natural, a system with a possibility for programmer controlled allocation as well as deallocation of buffers local to the session entity is needed. Many modern Pascal systems have included the DISPOSE primitive as an inverse to NEW but as this is not a very common feature and the programs are intended to be made portable it is not advisable to rely on such a mechanism. An extension of the buffer handling procedure interface designed for the Transport and Network layers as well as the Uninett Filetransfer Service implementation has been made and is located in the files prefixed with "QUEUES-". Here a TSDU (Transport Service Data Unit) is viewed as a linked list of buffers. Each buffer element holds a boolean flag telling whether this is the last buffer element in the current TSDU or not. A set of primitives operate on such lists. In the case of the primitive lPutByte the allocation of new buffers is automatic when the current list is full of text. The way to use it is to assign the buffer pointer the value NIL and then apply lPutByte to it as many times as is required. A buffer chain can be copied by using the primitive copylBuff and be released by using the primitive ReleaseBuff. Care must be taken so that operations are not applied to buffers residing in the free list. Therefore it is adviced that buffer pointers passed as parameters to procedures and functions are always declared as VAR parameters. When a particular type of operation should be added to the ones already defined it is adviced to try to use the existing routines instead of operating directly upon the contents of the lbuff records. A set of routines for operating upon objects of the type "queue" is also included. This might seem to be an unnecessary redundancy but it could be valuable when the length of the list is substantial, where the primitive lPutByte has to dereference its way to the last buffer for each byte put in the list while the operation qPutByte operating on elements of the type QUEUE has a direct pointer to the last buffer in the list. 4. The User Interface for the Session Services. -------------------------------------------- The user can operate the GILT and/or the S.62 protocols by using a procedure interface provided in the files with the prefix "SESSION-". The protocol primitives and the parameters specified in the above mentioned documents can be sent by calling a particular routine for each protocol primitive. In the case of CSUI and RSUI, which are used to transfer document commands, the routines that send the document commands calls the sending routine for CSUI/RSUI explicitly. Two parameters are added to the Document Command sending routines in order to make it possible for the user to choose whether he wants the document command to be sent using a CSUI- primitive or a RSUI-primitive and in this latter case what value should be assigned to the parameter "RequestSessionFunction" if it is used. The parameters of the session and document commands are specified in the above mentioned papers. Some parameters are mandatory. It is not checked by this interface whether all mandatory parameters are available in an incoming or outgoing protocol packet. This is regarded to be the responsibility of the session entity using this interface. To indicate for a given parameter whether if it should be included in the protocol packet or not two mechanisms are available. For parameters with a fixed length (1,2 bytes in most cases) a RECORD type is adopted where the subfield "used" is used to indicate whether the value field is valid or not. In the case of parameters with a varying length, which cannot be predetermined at compile time, a linked list of buffers is used. The value NIL is there a natural value to indicate that the parameter is not to be included in the protocol packet. To handle the parameters and their hierarchy a set of nested RECORD structures has been adopted. These records can be "cleared",i.e. all values are set to indicate a non-significant value (initiate the record), or they could be "released", i.e. to return all non- empty buffer chains referenced in the subfields of these records to the free list of buffers and then clear the record, or in the case of a record of the type "sParam" it could be "packed", i.e. a protocol-packet is constructed according to the parameters described in the record. This is done implicitly by the sending primitives of the interface and the user of the interface should not care about these things normally. An incoming packet could be "unpacked", that is, a record of the type "sParam" is constructed from the content of the protocol-packet. When operating on the content of the sParam-record care should be taken so that buffer chains are not left in "mid-air", but are properly returned to the buffer pool after all processing has taken place on these parameters. This is done by the primitive "sParamRelease". There is also a risk that buffers are returned prematurely causing inconsistency in the local buffer pool. A test routine for this may be invoked while debugging by setting the variable "debug" to TRUE. This option should not be on when the program runs properly. In all these operations error detection is being undertaken and as soon as an error is detected the operation is ended prematurely and control is transferred to the calling routine with an integer error code. The correct sequencing of protocol packets and the actions that are to be undertaken when the particular protocol packets arrive with particular combinations of parameter values are not an issue in this interface but is instead the responsibility of the entity using this service. Whether these functions are a part of the application layer or one of the session layer could be debated upon, which also has been done in the GILT community. These discussions indicated that the user of the Session Service Interface should not be aware of the particular sequencing rules of the protocol. It was suggested that a user interface should be so constructed as to give the user the maximal functionality of the protocol without burdening him with the details of it, e.g. the different methods of acknowledgement (positive and negative etc.) used for different protocol functions. I therefore advice anybody who is intending to use this interface to first build a more abstracted interface on top of this one, which could take care of some error conditions as well as resynchronisation and recovery functions and handle the different acknowledgement functions automatically in a way hidden to the user. This could be done in much the same way as I have designed the upper level user interface for the transport layer in terms of the lower one. Exactly how these primitives should look is somewhat depending on the application one has in mind, thereby forcing one to first decide on the presentation and application layer functions before deciding finally in this matter. I hope that these interface and buffer handling primitives will be proper and sufficient building blocks for the building of applications using the GILT or S.62 Session Services. { The End } Appendix: Here is a description of the files containing the code for the session layer: Filename: Description: --------- ------------ OPTIONS Local compiler options BUFF-CONST The basic routines for handling objects of BUFF-TYPE the type "buffer", used also in the transport BUFF-PROC layer automaton and the UNINETT/SUNET file transfer protocol implementation. MSG-VAR The interface to the interprocess communication MSG-HEAD system. Used also in the other SUNET software. MSG-LOCAL TRP-CONST The lower interface to the transport layer. USER-VAR USER-PROC QUEUES-CONST The queue and linked buffer handling routines. QUEUES-TYPE QUEUES-VAR QUEUES-PROC INTER45-CONST The upper interface to the transport INTER45-TYPE layer. INTER45-VAR INTER45-PROC SESSION-CONST The session layer interface for SESSION-TYPE packing/unpacking of the S.62 (+GILT) SESSION-VAR protocol primitives and the sending SESSION-PROC of them using the upper transport SESS-PROC1 layer interface. SESS-PROC2 SESS-PROC3 SESS-CMDS DOCUM-CMDS TEST-QUEUES Some test-programs. TEST-SESSION