UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

A semi-automatic approach to protocol implementation : the ISO class 2 Transport protocol as an example Lau, Allen Chakming 1986

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
831-UBC_1986_A6_7 L38_4.pdf [ 3.41MB ]
Metadata
JSON: 831-1.0051901.json
JSON-LD: 831-1.0051901-ld.json
RDF/XML (Pretty): 831-1.0051901-rdf.xml
RDF/JSON: 831-1.0051901-rdf.json
Turtle: 831-1.0051901-turtle.txt
N-Triples: 831-1.0051901-rdf-ntriples.txt
Original Record: 831-1.0051901-source.json
Full Text
831-1.0051901-fulltext.txt
Citation
831-1.0051901.ris

Full Text

A S E M I - A U T O M A T I C A P P R O A C H T O P R O T O C O L I M P L E M E N T A T I O N -T H E ISO C L A S S 2 T R A N S P O R T P R O T O C O L AS A N E X A M P L E By A L L E N C H A R M I N G L A U B.Sc, Simon Fraser University, 1983 A THESIS S U B M I T T E D IN P A R T I A L F U L F I L L M E N T O F T H E R E Q U I R E M E N T S F O R T H E D E G R E E O F M A S T E R O F S C I E N C E in T H E F A C U L T Y O F G R A D U A T E STUDIES ( D E P A R T M E N T O F C O M P U T E R SCIENCE) We accept this thesis as conforming to the required standard T H E U N I V E R S I T Y O F BRITISH C O L U M B I A July 1986 © Allen Chakming Lau, 1986 In p r e s e n t i n g t h i s t h e s i s i n p a r t i a l f u l f i l m e n t of the requirements f o r an advanced degree a t the U n i v e r s i t y of B r i t i s h Columbia, I agree t h a t the L i b r a r y s h a l l make i t f r e e l y a v a i l a b l e f o r r e f e r e n c e and study. I f u r t h e r agree t h a t p e r m i s s i o n f o r e x t e n s i v e copying o f t h i s t h e s i s f o r s c h o l a r l y purposes may be granted by the head of my department or by h i s or her r e p r e s e n t a t i v e s . I t i s understood t h a t copying or p u b l i c a t i o n of t h i s t h e s i s f o r f i n a n c i a l g a i n s h a l l not be allowed without my w r i t t e n p e r m i s s i o n . Department of C^W/fr/Stf ^ / ^ C F The U n i v e r s i t y of B r i t i s h Columbia 1956 Main Mall Vancouver, Canada V6T 1Y3 Date /</, DE-6 (3/81) A b s t r a c t Formal Description Techniques (FDTs) for specifying communication protocols, and the adopted F D T standards such as Estelle have opened a new door for the possibility of automating the implementation of a complex communication protocol directly from its specification. After a brief overview of Estelle F D T , we present the basic ideas and the encountered problems in developing a C-written Estelle compiler, which accepts an Estelle specification of protocols and produces a protocol implementation in C . The practicality of this tool — the Estelle compiler — has been examined via a semi-automatic implementation of the ISO class 2 Transport Protocol using the tool. A manual implementation in C / U N I X 4.2bsd of this protocol is also performed and compared with the semi-automatic implementation. We find the semi-automatic approach to protocol implementation offers several advantages over the conventional manual one. These advantages include correctness and modularity in protocol implementation code and reduction in implementation development time. In this thesis, we discuss our experience on using the semi-automatic approach in implementing the ISO class 2 Transport Protocol. ii Contents Abstrac t ii Contents i i i List of Figures v List of Tables v i Acknowledgement v i i 1 Introduction 1 1.1 Motivations 1 1.2 Scope and Contributions 2 1.3' Thesis Outline 3 2 Estelle 4 2.1 Channel and Interaction Primitive 4 2.2 Module and Interaction Point 6 2.3 Refinement and Process 7 2.4 Extended Finite State Machine 10 3 T h e Implementation Strategy 14 3.1 Data Structures 14 3.2 Interactions 17 3.3 Transitions 17 3.4 System Interfaces 18 4 T h e C-Estelle C o m p i l e r 20 4.1 The Structure 21 4.2 Translation Issues •• 21 4.2.1 Pascal to C Problems 21 4.2.2 Estelle to C Considerations 24 iii 5 Implementation Example - The ISO Transport Protocol 2G 5.1 Overview of The ISO Class 2 Transport Protocol 26 5.2 Design of the Implementation 30 5.2.1 Structure 30 5.2.2 Implementation Issues 30 5.2.3 Scheduler Design 31 5.3 Semi-Automatic Implementation 32 5.3.1 The Generated Code 32 5.3.2 Integration Process 34 5.4 Manual Implementation 35 5.5 Results 36 6 Conclusions 40 6.1 Thesis Summary 40 6.2 Future Work 41 Bibl iography 43 A T h e I S O Class 2 Transport P r o t o c o l — State Diagram 45 B T h e I S O Class 2 Transpor t P r o t o c o l — Estelle Specification 47 C S y s t e m Initialization a n d Scheduler — F o r S e m i - A u t o m a t i c Implementation 66 D S y s t e m Initialization and Scheduler — F o r M a n u a l Implementation 72 iv L i s t of F i g u r e s 2.1 An Example of Channel Specification 5 2.2 An Example of Module Specification 6 2.3 Typical Refinement of a Transport System 8 2.4 An Example of Refinement Specification 9 2.5 An Example of Process Specification 11 2.6 An Example of Transition Specification 13 3.1 Procedure of the Semi-Automatic Implementation 15 3.2 Data Structure of an Interaction 15 3.3 Data Structure of a Module Instance 16 3.4 Data Structure of an Interaction Point 17 4.1 The Structure of the C-Estelle Compiler 22 5.1 Transport Service — Primitive Sequence 28 5.2 Transport Protocol Data Unit Fixed Header Formats 29 A . l Transport Protocol State Diagram 46 v Lis t of Tables 5.1 Sizes of Different Parts of Implementations vi A c k n o w l e d g e m e n t I would like to thank my supervisor, Dr. Son Vuong, for his guidance throughout the course of this thesis and Dr. Harvey Abramson for his comments and careful reading of the thesis. Many thanks are due to Susan Chan and Helen See for their helpful comments and their fine editing skills. Finally, I wish to thank Frances Liu for her patience and love. vii Chapter 1 I n t r o d u c t i o n 1.1 M o t i v a t i o n s Formal Description Techniques (FDTs) [Boch80] for specifying protocols and services have opened a new door for the possibility of automating the implementation of a complex com-munication protocol directly from its specification. These FDTs are advance enough that they are becoming standards such as [CCITT85], [Estelle85] and [Lotos84] and their compil-ers, [Ansart83], [Bria86], [Ford85], [Gerber83] and [Hans84], are also being developed to make themselves usable in the design and implementation of real-life protocols. This new approach to protocol implementation is superior than the traditional approach in that communication protocols are implemented semi-automatically in a systematic manner rather than manually in an ad hoc manner. It avoids different interpretation of the specification and various implementation errors, hence, provides confidence in conformance to the specifi-cation. As a large portion of the protocol implementation is generated by the compiler in a standard target language, the implementation is highly portable. Furthermore, the generated code is well-constructed, and system-dependent features can be easily located in a few routines. Thus, the implementation is easier to maintain. 1 CHAPTER 1. INTRODUCTION 2 The motivation of this thesis is to verify the usefulness of the semi-automatic approach to protocol implementation. An Estelle compiler is chosen to implement a fairly complex ISO class 2 Transport Protocol [CCITT85,IS082b]. A manual implementation of this protocol is also performed and compared with the semi-automatic implementation. 1.2 S c o p e a n d C o n t r i b u t i o n s The chosen compiler is developed by Daniel Ford in the language C on a V A X 11/7501 running UNIX 4.2bsd2. The compiler accepts an Estelle specification for communication pro-tocols and produces C code. The generated code is then incorporated with pre-written generic and implementation-dependent routines to implement the specified protocol. The original C-written Estelle compiler3 is erroneous and insufficiently tested. Its per-formance has been greatly enhanced by transforming B N F grammars into L A L R grammars which best fit the Y A C C compiler [John75] for generating the parser of the C-Estelle compiler. The grammar rules were also rewritten so that the compiler supports complex data structures such as variant record and pointer which are commonly used in complex protocol specifications. Furthermore, the translation routines were modified to produce optimized and better-organized code. The enhanced compiler was examined by using it to implement protocols such as hot potato, alternating bit, and ISO class 2 Transport Protocol. It was also ported to several S U N Workstations4 and the protocol implementations are successfully running among the V A X 11/750 and S U N Workstations. X V A X is a trademark of Digital Equipment Corporation 2 UNIX is a trademark of A T & T Bell Laboratories. 3 For brevity we shall often use the terms C-Estelle compiler in place of C-written Estelle compiler *SUN Workstation is a trademark of Sun Microsystems. CHAPTER 1. INTRODUCTION 3 1.3 Thesis Outline After an overview of Estelle in Chapter 2, the development of the automatic tool, C-Estelle compiler is described. Chapter 3 explains the implementation strategy used in the tool, and Chapter 4 discusses the problems encountered. An extensive application of the tool is described in Chapter 5. The real-life ISO class 2 Transport protocol is implemented both semi-automatically by using the tool and manually in an ad hoc manner. After a presentation of their designs and implementations, experience learned from the implementations is discussed. The last chapter summarizes the thesis and offers suggestions for future work. Since the implementations of the C-Estelle compiler and the protocol were written in the language C, all coding examples presented are C-like. In addition, implementations run on the UNIX 4.2bsd operating system. Thus, reader are assumed to have a basic understanding of the language C and the U N I X 4.2bsd operating system. Chapter 2 E s t e l l e Estelle (Extended State Transition Language) is a formal description technique developed by the International Standard Organization (ISO) T C 97/SC 16/WG 1 — F D T , Subgroup B [Estelle85,IS084]. Based upon an extended finite state transition model and the Pascal pro-gramming language, Estelle is used for the specification of communication protocols and ser-vices. The framework of an Estelle specification is a set of co-operating entities, each described as a module, interacting with each other by exchanging information through channels. The actual behaviour of a module is specified as either an integrated behaviour of a set of interacting submodules or at the innermost level, an extended finite state automaton. 2.1 C h a n n e l a n d I n t e r a c t i o n P r i m i t i v e A channel is a two-way simultaneous pipe which transmits information between two con-nected modules. A channel-type definition specifies a set of interaction primitives which is grouped under two different roles. These roles are used to distinguish the two sides of the channel, and hence, the two connected modules. Primitives grouped under one role can only be initiated by the module instance which plays that role in respect to the channel; and they 4 CHAPTER 2. ESTELLE 5 are received by the module instance which plays the other role. Information is transmitted between module instances via the parameters of interaction primitives. As an example, fig-ure 2.1 shows a definition of a channel-type TS_primitives. There are ten possible Transport C H A N N E L TS_primitives ( TS.user, TS.provider ); B Y TSjiser : T_CONNECT_request T_CONNECT_response T_DATA_request T_XPD_request TJDISCONNECT_request B Y TS_provider : T_CONNECT_indication T_CONNECT_confirm TJDATAJndication T J X P D indication T_DISCONNECTJndication ( Frorrutransport^addr To_transport^addr QuaLofjservice TS_user_data ( QuaLof_service TS_user_data ( TS_user_data ( TS_user_data ( TS_user_data ( From_transport_addr To.transportjaddr Q ual joLser vice TS_user_data ( Qual_of_service TS_user_data ( TS_user_data ( TS_user_data ( Reason TS_user_data A D D R _ T Y P E ; A D D R . T Y P E ; Q O S . T Y P E ; D A T A _ T Y P E ); Q O S . T Y P E ; D A T A - T Y P E ) D A T A . T Y P E ) D A T A . T Y P E ) D A T A . T Y P E ) A D D R _ T Y P E ; A D D R _ T Y P E ; Q O S . T Y P E ; D A T A - T Y P E ); Q O S . T Y P E ; D A T A _ T Y P E ) D A T A _ T Y P E ) D A T A _ T Y P E ) R E A S O N _ T Y P E D A T A _ T Y P E ); E N D TS_primitives; Figure 2.1: An Example of Channel Specification service interaction primitives which can be used by a Transport service user to interact with the service provider. Five of them, namely T.CONNECT_request, T_CONNECT_response, T_DATA_request, T_XPD.request and T_DISCONNECT_request, can be initiated by a module CHAPTER 2. ESTELLE 6 instance which plays a role of TS_user in respect to the channel. The parameters of the inter-action primitives, such as TS_user_data, carry the given information from a TS_user module instance to a receiving TS_provider module instance. 2.2 M o d u l e a n d I n t e r a c t i o n P o i n t A module is the basic component of an Estelle specification and represents an entity of the specification. A module- type definition is a list of interaction points at which the module interacts with its environment. Each interaction point, (also called port), is an abstract interface of a module used to interact with the connected modules. For each interaction point, a role of its associated channel-type is specified. An interaction is then identified by the name of the interaction point at which it occurs and the name of the interaction. In addition, the interaction has to be one of the defined interaction primitives in the corresponding channel-type definition. The actual behaviour of a module is defined as either an integrated behaviour of a set of interacting submodules or an extended finite state automaton. For a given module-type, one or many module instances (i.e. protocol instances) can be obtained. A n example of a module specification is given in Figure 2.2. Al l possible interactions of a Transport service user with a M O D U L E TS_user_module; T S A P : TS.primitives ( TS_user ); E N D TS_user_module; Figure 2.2: A n Example of Module Specification Transport service provider is then through an interaction point TSAP. The interaction point is associated with a TS_primitives channel, and the module plays a role of TS_user. Thus, at this interaction point, the module can initiate the interaction primitives T_CONNECT_request, CHAPTER 2. ESTELLE 7 T_CONNECT_response, TJDATAjequest , T_XPD_request and TJDISCONNEGT_request. It is also allowed to receive other interaction primitives defined only for the TS.primitives channel. 2.3 R e f i n e m e n t a n d P r o c e s s In Estelle, the actual behaviour of a module is specified either indirectly as a Refinement or directly as a Process. If a module is not a complete self-contained entity, it is decomposed into a set of co-operating submodules, each of which may be further decomposed. The behaviour of the module is the integrated behaviour of the submodules and hence it is called a refinement. A module can also be specified as a process which describes the corresponding finite state transition model of the module. A n Estelle refinement specification includes definitions of internal channel-types, submodule-types, and specifications of the corresponding processes and refinements. After the definition of the internal structures, module instances are created and connected accordingly. If necessary, interaction points of internal module-types may be replaced by those of their parent module-type. A typical refinement of a Transport system is depicted in Figure 2.3. According to this refinement, a Transport_system module is refined as a Transportjref refinement, which is de-composed into two TS_user modules, one A T P module, two RS modules, and four System modules. The corresponding Estelle specification is shown in Figure 2.4. After defining the internal structures, module instances are declared. Module instances are then connected pro-vided that they play the different role of a channel through which they interact with each other. There are no replacement because Transport_system module is a closed system. A n Estelle process definition specifies the queueing discipline associated with each interac-CHAPTER 2. : ESTELLE 8 I r a n $ p o r t _ s y $ t e m Transport Service users u 1 u 2 nrp ( A b s t r a c t T r a n s p o r t P r o t o c o l ) 1 RSI R S 2 Network Service Providers s i S 2 S 3 S 4 Sys t em Se rv i ce P rov i de r s T r a n s p o r t _ r e f Figure 2.3: Typical Refinement of a Transport System CHAPTER 2. ESTELLE 9 R E F I N E M E N T Transport_ref F O R Transportjsystem; (* Constant and Type Definitions *) (* Channel Definitions *) (* Module and Process/Refinement Declarations *) (* Module Instances *) U l : TS_user_module W I T H TS_user_process(l); U2 : TS_user_module W I T H TS_user_process(2); A T P : ATP_module W I T H ATP4>rocess; SI S2 S3 S4 System_module W I T H System_process(l) System_moduIe W I T H System_process(2) Systemjnodule W I T H System_process(3) Systemjnodule W I T H System_process(4) RSI : RS_module W I T H RS_process(l); RSI : RS.module W I T H RS_process(2); (* Connection Establishments *)'• C O N N E C T U l . T S A P T O ATP.TCEP[1] ; U 2 . T S A P T O ATP.TCEP[2] ; ATP.NSAP[1] T O RS1.NCEP; ATP.NSAP[2] T O RS2.NCEP; ATP.SAPT[1] T O S l . S E P ; ATP.SAPT[2] T O S2.SEP; ATP.SAPN[1] T O S3.SEP; ATP.SAPN[2] T O S4.SEP; E N D Transportjef; Figure 2.4: An Example of Refinement Specification CHAPTER 2. ESTELLE 10 tion point, the initial condition and all possible transitions of the corresponding extended finite state machine. For each interaction point of a module, an individual queue is reserved for the queueing of incoming interactions from the peer module before these interactions are considered as input by the module. These queues are on a first-come-first-serve basis and their lengths are either infinite or zero. If the queue length is zero, an output interaction is not queued but consumed immediately as an input by the rendezvous recipient module. A process specification of a TS_user module is presented in Figure 2.5. The queueing discipline of its interaction point TSAP, local variables, primitive functions and procedures are first declared. The local variables are then initialized as the initial state of the corresponding extended finite state machine. The remaining specification is a list of transition definitions. 2.4 E x t e n d e d F i n i t e S ta te M a c h i n e The operation of a process is modeled as an extended finite state machine which is a finite state automaton extended with the addition of variables to the states, parameters to the interactions, time constraints and priorities to the transitions. The state space of a module is specified by a set of variables. One distinct variable, state, if defined, is used to represent the state of a finite state machine upon which the module is based. This major state variable, together with other context variables, determines a state of the module. The general idea to express a transition, is that W H E N an interaction arrives, a transition has to be performed, F R O M the current major state T O a new major state P R O V I D E D a condition is satisfied, through an action. The associated action of a transition is specified in terms of Pascal statements, and may include the initiation of output interactions with its peer modules. CHAPTER 2. ESTELLE 11 P R O C E S S TS_user_process ( TSindex : integer ) F O R TS_user_module; Q U E U E D T S A P ; (* Type and Variables Declarations *) (* Primitive function and procedure Declarations *) INITIALIZE B E G I N userJd := TSJndex; state := I D L E ; for qkind := Q JSfOJEXPEDITEDJDATA to Q . E X T E N D E D . F O R M A T do qual_of_service.misc[qkind] := F A L S E ; quaLoLservice.class := C L A S S . T W O ; sndcnt := 0; xsndcnt:= 0; rcvcnt := 0; xrcvcnt := 0; E N D ; (* Transition Definitions *) E N D TS_user_process; Figure 2.5: An Example of Process Specification CHAPTER 2. ESTELLE 12 Transitions are classified into input and spontaneous transitions, depending on the pres-ence of an input interaction (i.e. W H E N clause). An input transition occurs whenever there is an input interaction at a specified interaction point. A spontaneous transition lacks such a W H E N clause and may be executed regardless of any input interactions. The Estelle state machine is non-deterministic in the sense that in a given major state and at a given time, several different transitions may occur. As mentioned in the ISO F D T document, an Estelle specification must not depend on non-deterministic choices. In order to handle the non-deterministic situation, an A N Y clause is used to select a random value of the specified enumerated-type variable(s). Such an A N Y clause can only be used in spontaneous transitions. Figure 2.6 lists some transition types, which occur in a TS.user module. Transition one is an input interaction which is initiated by the Transport data arrival. The data arrival causes a cyclic transition from the major state A l i v e to itself, and an execution of procedure Store_data to store the data in a buffer pool. Transition two inherits the W H E N clause of transition one. When data arrives and the current major state is Receiving, counter rcvcnt is incremented and procedure TS_output is executed to notify the Transport service user the data arrival. The current major state is also changed into A l i v e as a result of the transition. Transition three is a spontaneous transition that is performed whenever the Transport service user has a request. Whenever the user wants to initiate a Transport connection and the present major state is Idle, it first sets up the parameters of the interaction primitive T_CONNECT_request. The request is then sent over the TS_primitives channel at interaction point T S A P and the major state of the module is changed to Wait ing . CHAPTER 2. ESTELLE T R A N S W H E N TSAP.TJDATAindicat ion F R O M Alive T O Same (* Transition One *) B E G I N Store_data ( pool, TS_user_data ) E N D ; F R O M Receiving T O Alive (* Transition Two *) B E G I N rcvcnt := rcvcnt + 1; TS_output ( userid, response ); E N D ; T R A N S P R O V I D E D T S i n p u t ( userid, request ) (* Transition Three *) B E G I N case request, kind of T . C O N N E C T : if state = Idle then begin state := Waiting; O U T TSAP.T_CONNECT_request ( local^ddr, remote_addr, quaLofjservice, request.data ) end; E N D ; Figure 2.6: An Example of Transition Specification Chapter 3 T h e Implementa t ion Strategy In automatic implementation of protocols, a generic structure and organization of the imple-mentation must be adopted. The implementation strategy adopted for our C-Estelle compiler is similar to the one used by G . Gerber in his Pascal-written Estelle compiler [Gerber83]. This approach makes use of data structures to represent module instances, interaction points, and interactions among module instances. A set of pre-written generic functions is used to allo-cate, initialize, and link data structures according to an Estelle specification. The pre-written functions also dispatch an output interaction to a recipient module, select the next available interaction, and make non-deterministic choice. Since different systems have different global environments and scheduling schemes, two special functions, namely system_init and sched-ule have to be tailored according to each specification. Figure 3.1 depicts the procedure of the semi-automatic implementation. 3.1 Data Structures There are three major data structures which represent module instances, interaction points and interactions between module instances. When linked appropriately, these data structures can represent an arbitrarily complex Estelle specification in a simple manner. 14 CHAPTER 3. THE IMPLEMENTATION ST RAT EG Y 15 P r i m i t i v e s Es te l l e S p e c i f i c a t i o n C-Estelle Compiler + Generated Code Generic + Functions Executab le 'Code C Compiler Figure 3.1: Procedure of the Semi -Automat i c Implementation In Figure 3.2, data structure signal_block represents an interact ion (i.e a signal) and is struct s ignaLblock { int s i g n a l j d ; struct signaLblock *next; union { } lvars; >; Figure 3.2: D a t a Structure of an Interaction comprised of three attributes, namely signalJd, next, and lvars. For convenience, interaction primitives, specified in channel-type definitions, are numbered. These numbers are used in signaljd to identify an interaction. The attribute next links data structures to implement the queueing of incoming interactions at an interaction point. The values of the parameters of an interaction are stored as a single attribute lvars in the data structure. A simple scheme is applied to avoid the name conflict of having identical parameter names in different interaction primitives and identical interaction names in different channel-types. Interaction primitives CHAPTER 3. THE IMPLEMENTATION STRATEG Y 16 under the same channel-type are grouped in a dummy structure which then appears as the only attribute of a variant of lvars. Similarly, parameters of an interaction primitive are grouped in a dummy structure which works as the only attribute of a variant of the interaction primitive. Representing a module instance, data structure proccss_block (Figure 3.3) consists of struct process_block { struct process_block *next; char p i d e n t [ M A X J D E N T X E N G T H + l ] ; struct channeLblock *chan_list; struct process_block *refinement; int (*proc_ptr)(); union { } lvars; }; Figure 3.3: Data Structure of a Module Instance six attributes, namely next, pJdent, chanjist, refinement, proc_ptr, and lvars. Similar to signaLblock structure, a variant is added to attribute lvars of the structure in each module type definition. Local variables are grouped in a dummy structure as a single attribute in each variant. The attribute proc_ptr is an entry point to a transition function which implements the transition process of the corresponding protocol machine. The remaining attributes are used to identify the corresponding transition function, and to build and link various data structures modeling the specified system. Representing an interaction point, data structure channel_block (Figure 3.4) contains the following attributes : target_proc, and target ^ channel are entry points to data structures which represent peer module instance and its corresponding interaction point; signalJist points to a list of incoming interaction; queued is a boolean flag that indicates the queueing discipline (queued CHAPTER 3. THE IMPLEMENTATION STRATEGY 17 struct channeLblock { struct channeLblock *next; int *signaljist; int *target_proc; struct channeLblock *target_channel; int queued; int cJd; int index_num; }; Figure 3.4: Data Structure of an Interaction Point or rendezvous) of the interaction point; cJd identifies the interaction point and additional indexjnum is used in case of multiplexing channel; finally next links all interaction points of a module-type. 3.2 Interactions As mentioned in Chapter 2, interactions can be classified into queued and rendezvous types. Output queued interactions from a module are queued in the recipient module. They are considered by the global scheduler as input interactions to the recipient module in due time. On the other hand, output rendezvous interactions are sent to and consumed by the recipient module immediately. If the recipient module is not in a state which the incoming interaction can initiate a transition, the interaction is added to the awaiting incoming interaction queue and will be considered immediately for execution in due time by the global scheduler. 3.3 Transitions In a given global system state, a number of different transitions belonging to different module instances is possible. The selection of the next available transition to be performed CHAPTER 3. THE IMPLEMENTATION STRATEGY 18 is made by a global scheduler, which is not part of the Estelle specification but part of the run-time support for the implementation. A simple round-robin scheduler is applied to choose the next available transition. For a given input interaction and a given major state of a module instance, several different input transitions may occur. Similarly, several spontaneous transitions can exist for a given major state of a module instance. For simplicity, the first possible transition in the same order as defined in the specification is selected to be performed. Hence, for each cycle, in addition to which module instance, the global scheduler selects the next input transition only based on the interaction point and the input interaction, or just determines whether a spontaneous transition to be taken next. 3.4 S y s t e m Interfaces For each implementation, the protocol implementors will have to manually look after the system-dependent portion of the implementation, i.e. interactions between the specified proto-col machine and its working environment. For instance, interactions with the operating system usually cause an undesirable blocking of the protocol machine and the solution to avoid such blocking varies largely on different machines and different operating systems. However, working environment such as the operating system is always known and its interfaces with the specified system can be well defined. This apriori knowledge can be used to simplify the system interac-tions. In our implementations, UNIX 4.2 socket primitive select is used to preview the socket so that the blocking is avoided when reading a socket. Thus, output to the environment can be implemented by invoking a set of system-dependent routines, while input from the environ-ment by including spontaneous transitions which invoke the same set of routines. The global CHAPTER 3. THE IMPLEMENTATION STRATEGY 19 scheduler is fully aware of when and which spontaneous transition should be performed. Chapter 4 T h e C-Es te l l e C o m p i l e r In order to support the implementation strategy described in Chapter 3, a C-Estelle com-piler was developed by D. Ford [Ford85] who rewrote G. Gerber's [Gerber83] Pascal-written Estelle compiler in the language C on a V A X 11/750 running UNIX 4.2bsd. The compiler was then modified by K. Chan, adding the capability of recognizing the additional scope of tran-sition group. The previous version of the C-Estelle compiler was erroneous and insufficiently tested. In order to make it useful, the performance of the compiler has been greatly enhanced by transforming the B N F grammars into L A L R grammars which best fit the Y A C C compiler for generating the parser of the C-Estelle compiler. The grammar rules were also rewritten so that the compiler supports complex data structures such as variant record and pointer which are commonly used in real-life protocol specifications. Furthermore, the translation routines were modified to produce optimized and better-organized code. During the test period, many minor problems, such as incorrect translation of Pascal for statement, have also been fixed. The enhanced compiler was later ported to several SUN Workstations and protocol implemen-tations such as hot potato, alternating bit and ISO class 2 Transport Protocol are successfully running among the V A X 11/750 and S U N Workstations. 20 CHAPTER 4. THE C-ESTELLE COMPILER 21 The enhanced C-Estelle compiler reads Estelle protocol specifications and produces C code. The generated C code is then incorporated with sets of system-dependent and pre-written generic routines into a C program which implements the specified communication protocol. This semi-automatic construction of protocol implementation is the main purpose of the development of the C-Estelle compiler. 4.1 T h e S t r u c t u r e Similar to many other compilers [Aho78], the C-Estelle compiler is partitioned into several phases as shown in Figure 4.1. Both lexical analyzer and parser were generated by the UNIX standard utilities L E X [Lesk75] and Y A C C [John75] respectively. Error handling, table man-agement and code generation were embedded in the Y A C C grammar input file. Currently, the compiler does not optimize the generated C code. It completes the translation in a single pass of the source specification. A large number of semantic analysis is left untouched to the C compiler which compiles the generated C code into executable machine code. The C-Estelle compiler only verifies the semantic conditions that would not be detected by the subsequent C compilation. For instance, the C-Estelle compiler ensures, for each connection, that the two connected module instances play the different roles of the same channel-type. On the other hand, the C-Estelle compiler does not verify that arguments are of types which are legal for an application of an assignment. 4.2 T r a n s l a t i o n Issues 4.2.1 Pascal to C Problems Since Estelle is a Pascal-based language, translating Pascal code into C code is a primary issue addressed during the implementation of the C-Estelle compiler. Although both Pascal and CHAPTER 4. THE C-ESTELLE COMPILER INPUT Lex ica l Ana lys is Tab le Management In termedia te-Code generation Error Handl ing i Code Optimization Code Generation i T O U T P U T Figure 4.1: The Structure of the C-Estelle Compiler CHAPTER 4. THE C-ESTELLE COMPILER 23 C are high-level programming languages which have similar control flow constructions and basic data types, they have enough differences which makes the direct translation a very difficult task. The following discussion has a great impact on the performance and the use of the C-Estelle compiler. First of all, both languages have very different approaches in defining the scope of objects. In Pascal, procedures and functions can be nested, and identifiers have no storage class attributes. The scope of an identifier is the block in which it is declared and every sub-block in which the identifier is not declared again. Whereas in C, only external functions are supported; function nesting is not allowed, and identifiers have a special storage class attribute. The scope of an identifier within a source file is basically the same as the one in Pascal. In addition, identifier which is not declared in any block, can be accessed within any blocks that is lexically after its declaration. Furthermore, the scope of externals, identifiers whose storage class are extern, may be defined in another source file. Two proposed solutions are to use multiple output files and to make all identifiers distinct and external. Both solutions are not straight-forward and very cumbersome to implement. For simplicity, the use of Pascal's scoping rules and nested routines is disallowed. Thus, when using the C-Estelle compiler, both global variables and nested routines are not allowed. Secondly, self-referential data structures are declared in different sequences. Due to the syntax of Pascal type declaration, self-referential data structure is defined in a way that a self-referential pointer to an object can be exceptionally defined before the object is defined. C does not have this syntax problem and an object must be defined before its reference pointer is defined. Hence, direct translation is not possible. The solution employed in the C-Estelle compiler is to define all objects first and then pointers. CHAPTER 4. THE C-ESTELLE COMPILER 24 Thirdly, the formats of input/output statements are very different. Directly translation is so difficult that only Pascal's output statements, i.e. write and wri teln statements, are supported and translated into equivalent C printf statements. Other forms of input/output statements can be embedded in primitive routines. Furthermore, Pascal's unique WITH statements and SET operations cannot be translated directly into any equivalent C statements. Additional statements and pre-written functions are required to make the translation. These Pascal features are currently not supported. 4.2.2 Estelle to C Considerations In addition to the above-mentioned difficulties of translating Pascal into C , there are certain aspects of Estelle which are very hard to handle. These are the additional Estelle scoping rules introduced by the enabling conditions of a transition type and the additional variables used by the run-time supporting routines. Some restrictions have been imposed in order to overcome these problems. First of all, the parameters of an input interaction, which are declared in the corresponding channel-type definition, are accessible within the scope of a W H E N clause. To avoid the name conflict, the parameter names cannot be used for local variables for any module-types which the interaction may occur. Secondly, if the interaction point identifier in a W H E N clause is indexed, the index identifier(s) must be declared as local variable(s) of the corresponding module-type. Thirdly, since an A N Y clause introduces additional variable(s) within the scope of the clause, a block is used to hide the new variable(s) from other transitions. The value of the variable is randomly selected from its specified domain by a pre-written function. Furthermore, addi-tional identifiers are generated by the C-Estelle compiler and used by the run-time supporting functions. These identifiers should never be in conflict with other identifiers of the specification CHAPTER 4. THE C-ESTELLE COMPILER which are still present in the generated C code. Chapter 5 I m p l e m e n t a t i o n E x a m p l e - T h e I S O T r a n s p o r t P r o t o c o l In order to evaluate the usefulness of the C-Estelle compiler, a fairly complex ISO class 2 Transport Protocol has been implemented both semi-automatically by using the C-Estelle compiler and manually in an ad hoc manner. Both implementations run on a V A X 11/750 and several S U N Workstations under the U N I X 4.2bsd operating system. After an overview of the protocol, the design of its implementation is presented. The two implementation approaches and the experience learned from the implementations are discussed, followed by a tentative comparison of these implementations. The state diagram of the protocol is depicted in Appendix A and the Estelle specification of the protocol in Appendix B. The system initializer and scheduler of the semi-automatic implementation is listed in Appendix C and those of the manual one in Appendix D. 5.1 Overview of T h e ISO Class 2 Transport Protocol The ISO Transport Protocol [CCITT85,IS082b] is a connection-oriented, end-to-end pro-tocol, providing a reliable and efficient mechanism for the exchange of data between processes 26 CHAPTER 5. IMPLEMENTATION EXAMPLE - THE ISO TRANSPORT PROTOCOL 27 in different computer systems. The class 2 protocol assumes a highly reliable network service, such as X.25, and has the ability to multiplex multiple Transport connections onto a single network connection. It also uses a credit allocation scheme to provide an explicit flow control because a single network connection flow control is insufficient to handle individual flow control of multiplexed Transport connections. Since Transport layer provides end-to-end data transfer independent of the nature of the underlying network, the Transport service is the same for all classes. The ten Transport service primitives have been listed in Figure 2.1 and Figure 5.1 displays the sequence in which these primitives are used. In order to communicate over a Transport connection, nine types of Transport protocol data units ( T P D U s ) are used. These T P D U s , shown in Figure 5.2, carry parameters which play an important role in the protocol mechanism. Each T P D U conveys a destination reference which uniquely identifies the Transport con-nection within the receiving Transport entity. Thus, multiplexing is allowed. After a Transport connection is established by exchanging C R / C C T P D U s , each data T P D U ( D T / E D T P D U ) is sequentially numbered. This sequence number is used for the flow control. A Transport connection is released whenever the Transport entity has sent or received a DR T P D U . The entity will then ignore any incoming T P D U s except D C / D R T P D U s . This explicit termina-tion mechanism allows that a Transport connection is released independently of the underlying network connection. CHAPTER 5. IMPLEMENTATION EXAMPLE - THE ISO TRANSPORT PROTOCOL 28 T C O N N request T C O N N ind ica t ion T_CONN response T_CONN request T_DISC indicat ior j T_CONN ind icat ion ^ T _ D I S C request T_CONN request T_DISC indicat ior S u c c e s s f u l E s t a b l i s h m e n t R e j e c t i o n b y T S u s e r R e j e c t i o n by T S p r o v i d e r T_DATA request T_EXPD request T_DATA ind ica t ion N o r m a l D a t a T r a n s f e r h i , T_EXPD indicat ion E x p e d i t e d D a t a T r a n s f e r T_DISC request T_D!SC ind icat ion R e l e a s e by T S u s e r T_DISC request T_DISC request T_CONN request T_CONN ind icat ion R e l e a s e b y b o t h u s e r s R e l e a s e b y p r o v i d e r T_DISC request T_DISC ind icat ion R e l e a s e b y u s e r & p r o v i d e r Figure 5.1: Transport Service — Primitive Sequence CHAPTER 5. IMPLEMENTATION EXAMPLE - THE ISO TRANSPORT PROTOCOL 29 Li cn CDT -— Source Reference Cis Op; LI C C C D T Des t ina t ion Re fe rence Source Reference CIs Opi LI DR — Dest ina t ion Re fe rence Source Reference Reason LI DC — Dest ina t ion Re fe rence Source Reference LI DT — Des t ina t i on Re fe rence 0 TPDU-NR LI ED Des t ina t i on Re f e r ence 0 T E D T P D U -NR LI A K C D T Des t ina t i on Re f e r ence YR-TU-NR LI EA — Dest ina t ion Re f e r ence Y R - E D T U -NR LI ERR — Des t ina t i on Re f e r ence Cause Figure 5.2: Transport Protocol Data Unit Fixed Header Formats CHAPTER 5. IMPLEMENTATION EXAMPLE - THE ISO TRANSPORT PROTOCOL 30 5.2 Design of the Implementation 5.2.1 S t r u c t u r e The overall structure of an Estelle specified Transport entity has already given in Figure 2.3. There are four different module types : TS_user, A T P , System and RS. Module instances of these four module types are incorporated with each other to represent a Transport entity. A TS_user module is a sub-layer which converts a Transport service user request into a well-defined Transport service primitive or changes the module state according to the request. A user task in the working environment can bind with one or more than one TS_user modules, and hence one or more than one Transport connections. An A T P module is an abstract Trans-port entity that establishes Transport connections, transfers data, and releases connections. A System module simulates a system timer for an incoming network connection or the flow control of a Transport connection. Finally, a RS module converts the network service primitives into system calls. It also sets flag and stores data whenever an incoming network event occurs. 5.2.2 Implementation Issues Since there are many unspecified properties in the protocol specification, these proper-ties have to be determined for each particular implementation such that the resulting imple-mentation best fits the working environment. Unspecified properties can be classified into implementation-defined and implementation-dependent. Implementation-defined properties are left unspecified and their definitions can vary from one implementation to another. For instance, in the TS.primitives channel definition, data type A D D R _ T Y P E is implementation-defined. Type A D D R _ T Y P E represents Transport ad-dress which may be implemented differently by different implementors. Similarly, the buffer CHAPTER 5. IMPLEMENTATION EXAMPLE - THE ISO TRANSPORT PROTOCOL 31 management and data exchanged by TS_users and a TS .provider are all implementation-defined. Their definitions and implementations are left untouched to the implementor. On the other hand, some properties are defined in the specification but their implementation is left unspecified. Examples of such properties are functions constructing Transport protocol data units. The format of a Transport protocol data unit is specified but how to construct such a T P D U is unspecified. 5.2.3 Scheduler Design A simple round-robin scheduler is employed to select the next available input interaction. This scheduler scans queues associated with each interaction point of module instances for the existence of any input interactions. The first available interaction is chosen and passed together with the information of the associated interaction point to the module instance which executes a transition. As mentioned in Section 3.3, for a given input interaction and a given module state, a number of transitions may be possible. Which possible transition is chosen to execute depends on the priority and the order it is defined in the specification. Generally, the chosen transition is the one has the highest priority and the first one which enabling condition is satisfied. At a regular time interval, a module instance which has spontaneous transitions is attempted to execute one of its spontaneous transitions. The first possible spontaneous transition which enabling condition is satisfied will be performed. This simple scheme works fine provided that the enabling conditions of the spontaneous transitions are all distinct, and spontaneous transitions are defined in a well-defined order. The above consideration of spontaneous transitions does not work satisfactorily for those initiated by the working environment. A module instance require to execute such a transition CHAPTER 5. IMPLEMENTATION EXAMPLE - THE ISO TRANSPORT PROTOCOL 32 immediately whenever the working environment notifies the module an external event occurred. The global scheduler is fully aware of the external events, and invokes the module instance to perform an action immediately whenever such event comes up. 5.3 S e m i - A u t o m a t i c I m p l e m e n t a t i o n The protocol was first specified in Estelle from the description in the ISO document [CCITT85,IS082b] and by adapting many other specification attempts [IS084,NBS83]. The Estelle specification was then compiled by the C-Estelle compiler to generate parts of the protocol implementation. After this automatic process, the generated code was incorporated with the pre-written generic routines and the system-dependent functions into a C program to implement the protocol in question. 5.3.1 The Generated Code The generated code can be classified into three types. The first type is the deftype and structure declarations which represent module instance, interaction, type and variable defini-tions. These definitions are required by the run-time executives to store the state information of the protocol machines. The second type is a set of functions which creates, initializes and constructs data structures in the specified fashion. The last type is another set of functions which implements the transition processes of the protocol machines. Most data structures are self-explanatory and the special data structures have been discussed in Chapter 3'. They are the wheels of the protocol machines which are initialized and constructed by the generated functions to implement the specified protocol. Initialization functions can be further subdivided into two types, depending on their corre-sponding Estelle specifications. A function which corresponds to an Estelle Process definition CHAPTER 5. IMPLEMENTATION EXAMPLE - THE ISO TRANSPORT PROTOCOL 33 creates and initializes a process_block data structure. This process_block represents one of the protocol machine instances in the specified system. Other type function corresponds to an Estelle Refinement definition. It creates the sub-module instances and links the instances according to the Estelle C O N N E C T and R E P L A C E definitions. Both type functions use a set of pre-written generic function to perform the creation, initialization, and integration of the specified system components. Transition functions are simply a series of conditional expressions and statement blocks. Expressions evaluate the enabling conditions of a possible transition type and block performs the associated action. Unless priority is set, input transition types are always generated ahead of spontaneous transition types. Only the first transition type, which enabling condition is satisfied, will be performed at a given time. Each transition type is generated in the same pattern. For an input transition, the operation is preceded by tests on the identity (signaUd) of the received interaction and those (cJd and indexjnum) of the interaction point at which it came. Additional tests, which correspond to P R O V I D E D clause and/or T O clause, may also preceded the operation. At the end of each transition type, a goto dispose statement passes control to the signal data structure dispose code. For a spontaneous transition, the pattern is the same except that no tests on the identities of the input interaction and the interaction point. For an A N Y clause, which requires to make a non-deterministic choice, a sub-block is created. The specified variable(s) is declared within the sub-block and its value is randomly selected from its defined domain by the pre-written function random_select. Creation and destruction of signal structures which represent interactions between module instances are implemented completely within the generated transition functions. The output CHAPTER 5. IMPLEMENTATION EXAMPLE - THE ISO TRANSPORT PROTOCOL 34 statement O U T is implemented as follows. First, a signal structure is created and initialized with the given parameters. The signal structure is then passed to a generic function out together with the information of the interaction point at which the module instance interacts with the peer. If the interaction is a queued type, the signal structure is placed in the reception queue of the peer module instance. Control returns to the initiating module instance immediately. If the interaction is a rendezvous type, the transition function corresponding to the peer module is invoked directly at this point. The destruction of the signal structure is handled by the recipient module instance. 5.3.2 Integration Process For convenience, deftype and structure definitions of the generated code were first extracted into a well-known header file defs.h. Two run-time supporting functions, s y s t e m j n i t and schedule, was then modified to suite the specified system. Finally, the generated code was incorporated with the system-dependent primitives and the run-time supporting functions into a C program to implement the protocol in question. Besides defs.h, there is another global header file listdefs.h included in all files. File listdefs.h contains macro definitions and specification-independent channel_bloek structure declaration. This structure is used to represent an interaction point of a module. Another important header file fdtglobal .h, which is required to be modified for every different specifi-cation, contains the declaration of all global variables and external functions. This fdtglobal.h file is included only in the main routine file. There are two key global variables : p_block and signal_pending. During execution, pointer p_block is an entry to the current machine in-stance, and signal_pending is a counter of interactions which have been initiated and are waiting for execution. CHAPTER 5. IMPLEMENTATION EXAMPLE - THE ISO TRANSPORT PROTOCOL 35 To execute, function s y s t e m j n i t first builds and interconnects the specified machine in-stances. The working environment is also set up so that the upcoming scheduler can be fully aware of any interested external events. Function schedule is then invoked to repeatedly scan all interaction queues associated with channels and to activate the module instances. Module instances which contain spontaneous transitions are tried at a regular time interval. Further-more, whenever an external event occurs, the scheduler will activate a proper module instance to perform a special-designed spontaneous transition. 5 . 4 M a n u a l I m p l e m e n t a t i o n Based on the same specification and the semi-automatic implementation, the protocol was re-implemented manually in an ad hoc manner. Most principles discussed in Chapter 3 and previous Section 5.2 were followed. The overall structure is similar to that of the semi-automatic implementation. The Transport entity is implemented as a single task in the operating system. It communicates with user tasks and the network service provider through operating system primitives (i.e. system calls). The major difference to the semi-automatic approach is the implementation of scheduling interactions which are initiated either by a module instance or the working environment. Instead of using a single data structure process_block, three different data structures, TS . M A C H I N E , T P _ M A C H I N E and N P _ M A C H I N E , are designed to store the state information of a Transport service user, a Transport connection and a network service provider respectively. Three global variables, tslist, tplist and nplist, are declared as head pointers of the three different control queues. The interactions between the Transport entity task and the working environment, user tasks CHAPTER 5. IMPLEMENTATION EXAMPLE - THE ISO TRANSPORT PROTOCOL 36 and the network service provider, are based on the inter-process communication primitives provided by the operating system, i.e. UNIX 4.2bsd socket primitives. Spontaneous transitions initiated by the working environment were handled in an ad hoc manner similar to that in the semi-automatic implementation. Whenever an external event occurs, the corresponding module instance is activated to perform a proper transition. A series of input transitions, initiated after this spontaneous transition, is then performed until all module instances are in a steady state. As a result of this transformation, the global scheduler is simply a loop which performs the processing for the incoming external events one after the other. 5.5 R e s u l t s The size of different parts of the resulting implementations are shown in Table 5.1. Both implementations used the same INET primitives to interact with the network service provider. This network service provider is usually a daemon process in the operating system. INET primitives provide an uniform access scheme which can be easily modified to suite different network service access schemes in different systems. Similarly, T S P primitives were used for the interactions between Transport service user tasks and the Transport entity task. Both implementations spent a large amount of code in T P D U encoding/decoding and buffer management. However, they were not very difficult to implement because of the powerfulness of the C language. The encoding/decoding of T P D U s were implemented almost the same in both implementations. Both implementations shared the same header file p d u . h and differed only in the passing parameters when decoding a T P D U . Since the buffer management was implemented intermixed with other code in the manual implementation, no separate entry for its code is in the table. CHAPTER 5. IMPLEMENTATION EXAMPLE - THE ISO TRANSPORT PROTOCOL 37 PART OF PROGRAM Number of Funct ions and Ma c r o s (A) (B) Number of Source L ines (A) (B) P rogram s i ze (in bytes) (A) (B) INET PRIMITIVES 9 509 10969 TSP PRIMITIVES 1 2 7 4 1 1707 3 ESTELLE SPECIFICATION 2 0 19 10 • 4635 1 GENERATED CODE 2 0 14 4 7 9 1421 RUN-TIME SUPPORTING ROUTINES 76 1 6 34 2 0 770 7662 1 2 1054 PRIMITIVE ROUTINES 62 30 4 9 7 1340 (A) --- M a n u a l I m p l e m e n t a t i o n (B) --- S e r n i - A u o t m a t i c I m p l e m e n t a t i o n Table 5.1: Sizes of Different Parts of Implementations CHAPTER 5. IMPLEMENTATION EXAMPLE - THE ISO TRANSPORT PROTOCOL 38 Forty two additional functions were used in the semi-automatic implementation. Sixteen of them were pre-written run-time supporting functions and the rest were specially designed for the global scheduler to activate the specific modules. During the semi-automatic implementation, the most difficult task was integrating the gen-erated code with the working environment. Both the implementation scheme using by the C-Estelle compiler and the behaviour of the working environment must be thoroughly under-stood in order to design the specific spontaneous transitions and to modify the two special run-time supporting functions : system j n i t and schedule. The weakness of Estelle forced the static allocation of data structure process_block which represents a module instance. The number of Transport service users and network connections must be pre-defined in the specification. The pre-definition was then used by the C-Estelle compiler to generate code that the corresponding process_block structures must be allocated in the global initialization phase. To execute, a pre-defined number of Transport service user tasks must be executed so that the implemented system went through the global initialization stage. The advantages of the semi-automatic approach came from the well-constructed generated code. Since the code was generated directly from a formal specification, the conformation was almost guaranteed. The well-constructed code also localized hazards and system dependent properties in a few routines, and hence, maintenance was much easier. On the other hand, the most difficult task of the manual implementation was to design the interfaces with the operating system for interactions with the user tasks and the network service provider. Interactions initiated by the working environment intermixed with other input interactions. The layer structure was less clear in the resulting code. A longer debugging period CHAPTER 5. IMPLEMENTATION EXAMPLE - THE ISO TRANSPORT PROTOCOL 39 was spent and more exceptional cases were required to be handled. Although the manual implementation was based on the same specification, no restriction on static allocation was imposed in the global initialization phase. Any number of Transport service user tasks can interact with the Transport entity. The Transport entity required no static connections to go through its initialization phase. Furthermore, any number of network connections can be established during the execution. The manual implementation is tied closer with the working environment. An interaction was implemented as simply a function call. It was always faster than the semi-automatic imple-mentation because of the reduction of a large amount of generated code which had additional swapping overhead for module interactions. It took approximately one year to study and implement the ISO class 2 Transport Protocol manually in an ad hoc manner without an Estelle specification. The protocol was subsequently specified in Estelle, and re-implemented semi-automatically in about two months. After this exercise, we gained a profound experience on protocol implementation and a good insight to the ISO class 2 Transport Protocol. Therefore, in our last attempt, it took us only one month to re-implement the protocol manually. From our experience, we think it saves protocol development times and it is good practice to start with the semi-automatic approach to protocol implementation, assuming one is familiar with the F D T compiler. The code produced this way is well structured and easy to maintain. Even if the code is not efficient enough, we can always attempt a manual implementation subsequently. Protocol implementations generally require a lot of time on the development of the interfaces with the working environment. The manual approach required additional time to implement module interactions. It also required more debugging time than the semi-automatic approach. Chapter 6 C o n c l u s i o n s 6.1 Thesis Summary This thesis has discussed a semi-automatic approach to implement a protocol. The protocol is first specified in the Estelle F D T , and translated into C code by using an automatic tool, C-Estelle compiler. The generated code is then incorporated with system-dependent primitives and run-time supporting functions into a C program which implements the protocol in question. Despite the fact that the semi-automatic implementation tends to be slow and an initial effort is required to learn the Estelle F D T and the automatic tool C-Estelle compiler, the new approach has the following benefits : 1. Easy maintenance because the generated code was constructed in a simple and easy-to-read pattern. 2. Good conformance because the specification was directly (automatically) translated into C code. 3. High portability because large amount of code was generated in standard C language and system-dependent properties were easily located and modified. 4. Less development time because large amount of code was translated directly from the specification. Experience on implementing the ISO class 2 Transport Protocol has verified the usefulness 40 CHAPTER 6. CONCLUSIONS 41 of the C-Estelle compiler and the semi-automatic approach to protocol implementation. From our experience, it is a good practice to approach a protocol implementation in the following sequence : 1. Implement the protocol semi-automatically using the C-Estelle compiler. 2. Optimize the semi-automatic implementation, especially the generated code. 3. Re-implement the protocol manually (if high performance is required.) 6.2 F u t u r e W o r k Further study on the semi-automatic implementation would be useful, in that a protocol can be implemented by two completely independent teams, one using the traditional ad hoc approach and the other, the new semi-automatic approach. This way, more concrete and objective comparisons can be made on the performance and usefulness of the new approach. Further testing of the C-Estelle compiler on complex protocols such as ISO class 4 Transport Protocol is a natural extension of our thesis. Such experiment would further demonstrate the usefulness of the compiler. Several enhancements to this technique and the compiler are under consideration. In order to enhance the C-Estelle compiler, some of the high-level code for interactions of the specified system with its working environment should be generated by the compiler. Dynamic structure, such as Process allocation should be supported by the Estelle, and hence the compiler. Since global variables, W I T H statements and S E T operations are very useful features, the compiler is also required to support them. To be realistic, the compiler should be modified to support a general multi-process struc-ture instead of the procedure-oriented structure. Since UNIX 4.2bsd is a procedure-oriented CHAPTER 6. CONCLUSIONS 42 operating system, a better working environment, such as V-system and Team Shoshin which are process-oriented , may be chosen. To overcome the Pascal-to-C problem, a C-oriented F D T would be desirable for protocol implementors who are working in C / U N I X oriented environment. However, the apparently irreversible decision by the ISO standard committee (ISO T C 97/SC 16/WG 1 - F D T Subgroup B) has been made to keep Estelle Pascal-oriented. Whenever the final Estelle standard becomes available, the compiler will have to be adapted to that (our implementation of the C-Estelle compiler is based on [IS084], not the latest [Estelle85]). As the last comment, the compiler can be well used as a simulation tool, and could be incorporated with some validation, testing and performance evaluation facilities so that we can have a complete automatic system for the design, validation, implementation, testing and performance evaluation of the communication system. B i b l i o g r a p h y [Aho78] Aho, A . and Ullman, J., "Principles of Compiler Design," Addison-Wesley, 1978. [Ansart83] Ansart, J.P., Chari, V. and Simon, D. , "From formal description to automated implementation using PDIL," Protocol Specification, Testing and Verification, ( IFIP/WG 6.1), H. Rudin and C. H. West, eds, North Holland (1983). [Blum82] Blumer, T.P. and Tenny, R., " A formal specification technique and implementation method for protocols," Computer Networks, 6 (3), June 1982, pp. 201-217. [Boch80] Bochmann, G.v. and Sunshine, C , "Formal Methods in communication Protocol Design," IEEE Trans, on communications, COM-28 (2), April 1980, pp. 624-631. [Boch84] Bochmann, G.v., Gerber, G . and Serre, J . M . , "Semi-automatic Implementation of Communication Protocols," T R 518, d'IRO,Universite de Montreal, Decem-ber 1984. [Bria86] Briand, J.P., Fehri, M . C . , Logrippo, L. and Obaid, A . , "Structure and Use of a L O T U S Interpreter," SIGCOMM '86, Symposium, Vermont, 1986. [Brin85] Brinksma, E. , " A Tutotial on L O T U S , " Protocol Specification, Testing and Veri-fication V, ( IFIP/WG 6.1), M . Diaz, eds, North Holland (1985). [CCITT85] C C I T T , Recommendations X.200 to X.250, Red Book, Geneva, 1985. [Estelle85] ISO T C 7/SC 21/WG 1 - F D T , Subgroup B, "Estelle — a formal description technique based on an extended state transition model," Feb. 1985. [Ford85] Ford, D . A . , "Semi-Automatic Implementation of Network Protocols," Master Thesis, University of British Columbia, March 1985. [Gerber83] Gerber, G .W. , "Une Methode D'Implantation Automatisq de Systemes Specifies Formellement," Master Thesis, University of Montreal, 1983. [Grog80] Grogono, P., "Programming in Pascal," Rev. ed., Addison-Wesley, 1980. 43 [Hans84] Hansson, H . , "Aspie, A system for Automatic Implementation of Communication Protocols," Uptec 8486R, Uppsala Institute of Technology, Uppsala, 1984. (IS082a] ISO T C 97/SC 16, DP 8073, "Transport Protocol specification," June 1982. [IS082b] ISO T C 97/SC 16, DP 8072, "Transport Service Definition," June 1982. [IS084] ISO T C 97/SC 16/WG 1 — F D T , Subgroup B, " A Formal Description Technique based on an extended state transition model," Working Document, March 1984. [John75] John, S . C , " Y A C C : Yet Another Compiler-Compiler," CS T R 32, Bell Labora-tories, NJ , 1975. [Kern78] Kernighan, B.W. and Ritchie, D . M . , "The C Programming Language," Prentice-Hall, 1978. [Lesk75] Lesk, M . K . , "Lex—A Lexical Analysis Generator," CS T R 39, Bell Laboratories, NJ, 1975. [Lotos84] ISO T C 7/SC 16/WG 1 - F D T , Subgroup C, N 299, "Definition of the Temporal Ordering Specification Language," May 1984. [NBS83] National Bureau of Standards, "Specification of a Transport Protocol for Com-puter Communication," I C S T / H L N P 83-2, Feb. 1983. [Rit78] Ritchie, D . M , and Thompson, K. , "The UNIX time-sharing system," Bell Sys. Tech., 57(6), July 1978, pp. 1905-1929. [Tanen8l] Tanenbaum, A.S. , "Computer Networks," Prentice-Hall, 1981. [Vuong86] Vuong, S.T. , and Ford, D . A . , " A n Automatic Approach to Protocol Implementa-tion," T R draft, Dept. of Comp. Sci., University of British Columbia, 1986. 44 Appendix A T h e I S O Class 2 Transport P r o t o c o l — State D i a g r a m 45 APPENDIX A. THE ISO CLASS 2 TRANSPORT PROTOCOL — STATE DIAGRAM T . C O N N . R E Q / N _ C O N N _ R E Q C C / T _ C O N N _ C O N P ( L /R ) --- L E n a b l i n g C o n d i t i o n R O u t p u t In te rac t ion Figure A . l : Transport Protocol State D i a g r a m Appendix B The ISO Class 2 Transport Protocol — Estelle Specification 47 MODULE T c i i n 3 p o c t _ s y s r . e m ; END T r a n s p o r t _ s y s t e m ; REFINEMENT T c a n s p o c t _ r e f FOR T r a n s p o r t _ s y s t e n i ; T c a n s p o r t P r o t o c o l machine Module (* C o n s t a n t and Type D e f i n i t i o n s *) (* C h a n n e l D e f i n i t i o n s *) CHANNEL T S _ p r i m i t i v e s ( T S _ u s e r , T S _ p r o v i d e r ) B Y T S _ u s e r : T CONNECT_request T_CONNECT_response T D A T A _ r e c u e s t T X P O r e q u e s t ( F r o m _ t r a n s p o r t _ a d d r T o _ t r a n s p o r t _ a d d r Qua i _ o f _ s e r v i c e TS_use r _ d a t a ( Qua 1 o f _ s e c v i c e T S _ u s e r _ d a t a ( T S _ u s e r _ c a t a ( TS u s e r d a t a T_DISCONNKT requesc ( T S _ u a e r _ d a t a AlWRJTTfPS; ADDR_TY?E; Q05_TYPS; D A T A T Y P E QOS_TY?E; DATA j r Y P E DATAJFYPE DATA_TY?E DATA TY?;. 3Y T S _ p r o v i d e r : T CONNECT i n d i c a t i o n T CONNECT c o n f i r m T _ D A T A _ i n d i c a t i o n T XPD i n d i c a t i o n ( r r o m _ t r a n s p o : ; _ = d c r T o _ t r a n s p o r t a d c r Q u a l _ o f _ s e rv_i.ce TS_use r _ d a t a ( Q u a l _ o f _ s e r v i c e T S _ u s e r _ d a t a ( T S _ u s e r _ d a t a ( TS u s e r d a t a T _ D I S C O N N E C T _ i n d i c a t i o n ( Season TS_use r_da ta E N D T S _ p r i r o i t 1 v e s : CHANNEL N S _ p r i m i t i v e s ( NS_user, N S _ p r o v i c e r ) ; B Y N S _ u s e r : N CONNECT_request ( From_network_addr T o _ n e t w o r k _ a d d r QOS N_CONNECT_response; N DATA_requesr. ( NS u s e r _ d a t a N_DISCONNECT r e q u e s t . B Y N S _ p r o v i d e r : N C O N N E C T _ i n d i c a t i o n ( From_network_addr — To n e t w o r k _ a d d r QOS AD DR_T':'?=.; ADDR_TYPE ; QOS__TYPE; DATA_TYPE ) QOS_TYPE; DATA_T Y P £ ) DATA_TYPE ) DATA_TY?E ) REASON _TY?E DATA TYPE j N A D D R _ T Y ? E N A D D R _ T Y ? E N Q O S T Y P E NDATA TY." NADDR_TYPE NADDR_TYPE NQOS TYPE N_CONNECT c o n f i r m ; N D A T A _ i n d i c a t i o n ( NS_use r_d<it:<» : NDATA_TYPE ); N O I S C O N N E C T _ i n d i c a t i o n ( Reason : REASON_TYPE ) :''.NL> N S p c im i i. v es ; CilANNF.l. S y s t e m p r i m i t i v e s ( S_user, 5 p r o v i d e r ) ; 3Y S u s e r : T i m e r r e q u e s t ( Name T ime Seqno T i m e r _ c a n c e L ( Name Seqno A l l s e q a Y S _ p r o v i d e r T i m e r _ r e s p o n s e ( Name Seqno TIMEK_TYPE; i n t e g e r; SEQUENCE_TYPE ) TIM£ R _ T Y P E ; SEQUENCE TYPE; boo Lean ) , TIMER_TYPE; SEQUENCE TYPE ) END System__pr i m i t i v e s ; MODULE TS u s e r _ m o d u l e ; TSAP : TS_pci.mi.ci.vss ( T S _ u s e r ) ; 2 N D T 5 u s e r module; PROCESS TS_ u s e r o c o c e s s ( T S _ i n d e x : i n t e g e r ) fOR T S _ u s e r _ m o d u l e ; END T S _ u s e r _ p r o c e s s • ; MODULE System_module; SEP : S y s t e m _ p r i m i t i v e s ( S _ p r o v i d e r ); END System_module; PROCESS S y s t e m _ p r o c e s s ( S y s _ i n d e x : i n t e g e r ) FOR System_modu1e; END S y s t e m p r o c e s s ; MODULE ATP module; TCEP NSAP SAPT SAPN ARRAY (TSAP_TYPE ) OF TS_p r i m i t i ves ( T S _ p r o v i d e r ) ARRAY(NCEP_TYPEJ OF N S _ p r i m i t i v e s ( NS_user ); ARRAY[TSA?_TYPE1 OF S y s t e m _ p r i m i t i v e s < S _ u s e r ) ; ARRAY [ NCEP TYPE] OF Sy s t ern_p r i m i t i ve s ( S u s e r ) : END A T P m o d u l e ; PROCESS A T P _ p r o c e s s FOR ATP_module; QUEUED TCEP, NSAP; (' V a r i a b l e d e c l a r a t i o n s •) t c nc TP_TABLE; NS TABLE; SO temp ndac a odu :. id :i id reason nsdu ion DATA_TYPE: NDATA_TYPE; TPDU_TYPE; TSAP_ fD_TYPE; NCF.P ID_TYPE; 0 _M t5C_K IHD ; SEQUENCE_TYPE; REASONJTYPE; intege r; (* P r i m i t i v e functions and procedures ' ) PROCEDURE Add_request( VAR tc data FUNCTION A l l o c r e f : REFERENCE_TYPE; PROCEDURE Concatenate 7. PROCEDURE Construct_AK( VAR packet crit dref seqno extended PROCEDURE Construct_CC( V A R packet bu f m qos PROCEDURE Const ruct_CR ( V A R pack.ec bu s re £ Lsuf fsuf maxs z qos data PROCEDURE Construct_DC( VAR packet dref sref PROCEDURE Construct _DR( VAR packet c re r" s ret" reason da t a PROCEDURE Construct_DT( VAR packet dref e £ lag seqno extended' data PROCEDURE Construct_ERR( VAR packet dref reason data PROCEDURE Construct_XAK( VAR packet dref xseqno extended PROCEDURE Construct_XPD ( VAR packet PRIMITIVE; PRIMITIVE; PRIMIT IVE; ; DATA_TYPE; : SEQUENCEJTYPE; : REFERENCS_TY?E; : S E Q U E N C E _ T Y P E ; : boolean ); PRIMITIVE; : D A T A _ T Y P E ; : S E Q U E N C E _ T : ? E ; : 3UF:-"I:-:_TY?E; integer; : Q O S _ f " ? E ; D A.T A T Y P E ; : SEQUENCE_Ti?E. : REFERENCE_TYPE; : SUFFIX_TYPE; : SUFFIX_TYPE; : integer; : QOSJTYPE; ; DATA_TYPE ) ; PRIMITIVE; : DATA_TYPE; : REFERENCE_TYPE; : REFERENCE_TY?E ) ; PRIMITIVE; : DATA _TYPE; : REFcRENCE_TYPr; ; : REFERENCE_TYP~. ; : R E A S O N _ T Y ? E ; : DATA_TYPE ) PRIMITIVE; : DATA_TYPE. : REFERENCE_TYPE; : boolean; ; SEQUENCEJTYPE; : boolean; : DATA_TYPE I ; PRIMITIVE; : DATA_TYPE; : REFERENCETYPE; : REASON_TYPE; : DATA TYPE ) ; PRIMITIVE; : DATA_TYPE; : REFERENCE_TYi>E; : SEQUENCE TYPE ; ; boolean ). PRIMITIVE. : DATA_TYPE; TP_MACHINE; DATA TYPE ): NSDU ( VAR nc : NS_MACHINE.• data : DATA TYPE ); SI dtef xseqrio extended data : REFERENCE_TYPE; : SEQUENCE_TYPE; : boolean; : DATA TYPE ) P R I M I T I V E ; FUNCTION Decernme_TC( tc data VAR odu TP_TAB].E; DATA_TYPE; TPDU TYPE ) TSAP ID TYPE; PR[MIT IVE ; PROCEDURE Extcdlct_NSDtl( VAR nbuffec VAR ndata NUUFFER_PTR; NDATA TYPE PRIMITIVE; PROCEDURE ExtcactTPDU( nsdata VAR tpdata VAR nslen NDATA_TYPE; DATA_TYPE; integer \ PRIMITIVE; PROCEDURE Extract_TSDU( buffer VAR tsdu VAR count BUFFERJTYPE; DATA_TYPE; SEOUENCE TYPE PRIMITIVE; PROCEDURE Gct_net_addr( VAR naddr taddr NADDR_TYPE; ADDR TYPE ) PRIMITIVE; PROCEDURE Mergef VAR buffer pdu BUFFER_PTR; TPDU TYPE ) ; PRIMITIVE PROCEDURE Release( VAR bu f f e r seqno k inc a U s ee BUFFER_PTR; SEQUENCE_TYPE; ?DU_KIND; boolean ) PRIMITIVE PROCEDURE Rel.ease_a 11 ( VAR ::c VAR r.c _MAC!i INE; MACHINE ) PRIMITIVE; PROCEDURE Resume_data( VAR tc VAR nc r?_:-'ACM INE; iS MAC!i INE ) ; PRIMITIVE; PROCEDURE Resume_xdata{ VAR tc VAR nc TP MACHINE; NS"MACHINE ) ; PRIMITIVE . PROCEDURE Retrieve) b u f f e r seqno kind' VAR data 3UFFER_PTR; SEQUENCE_TYPE; PDU_KIND; DATA TYPE ); FUNCTION Same naddr( naddrl, naddr2 : NADDR TYPE ) ; boolean; P R I M I T I V E ; P R I M I T I V E ; PROCEDURE Store( VAR bu f f e r data seqno k ind 3UEFER_PTR; DATA_TYPE; SEQUENCE_TYPE; PDU KIND PRIMITIVE; FUNCTION SEQ_ADD ( seql, seq2 extended SEQUENCEJIYPE; boolean ) : SEQUENCE TYPE, PRIMITIVE FUNCTION SEQ_MINUS ( seql, Seq2 extended SEQUENCE_TYPE. boolean ) : SEQUENCE TYPE; PRIMITIVE; PROCEDURE Uncode ( VAR pdu ndata extended TPDU TYPE; NDATA_TYPE; boolean ); PRIMITIVE; ( * " FUNCTION Acceptable CC( qos s re f pdu BEGIN QOS_TYPE; REFERENCE_TYPE ; TPDU TYPE ' ) . ' O O lea: Accept ab1e CC TRUE ; i f { pdu.ve rs ion ( pdu.data.dlen ( pdu.maxsz then <> VERSION ) or > MAX_CRCC_SZ ) or = 0 ) AtCeptabLvjZC .- = fALSt. : ( p d u . q o s . c l a s s <> q o s . c l a s s ) and ( p d u . o c l s <> qos . c l ) : ; : ; ) t h e n A c c e p t a b l e C C : = F A L S E ; i f < NOT qos ml r.c (O pdu qos m i s c I O NOT qos in i s . : |Q pdu qos mi.so !o NOT qos m i s c l Q pdu qos m i s c [Q NOT qos m i s c l Q pdu qos mist: (0 t lien A c c e p t a b l e _ C C _NO_EXPED lTt:D_.;ATA ' -mri ~ M O ~ E X P E D I T E 0 _ D A T A • ) _C. IECXSUM_IN _'JSE ] and _ C ! ! K C X S U M _ I M " V S E 1 ) NO_ r L O W _ C O N ' r R O L | and ^NO^ELOW^CONTROL] ) _EXTENDED_FORMAT] and _EXTENDED_F0RMAT1 ) = FALSE; i E p d u . d r e f <> s r e f t h e n A c c e p t a b l e _ C C := FALSE F l h M C T r O N A c c e p t a b l e _ C R ( qos : Q O S _ T Y P E ; pdu : T?DU_TYPE ) : b o o l e a n ; VAR q k i n d : Q_MISC_KINO; .5EG IN A c c e p t a b l e _ C R :~ TRUE; I? ( p c u . v e r s i o n <> VERSION ) or ( pcu . da t a . d i e n > MA.X_CRCC_SZ ) or ( pdu.maxsz = 0 ) t h e n A c c e p t a b l e _ C R :- FALSE.-if- ( pdu . qos . c l a s s <> q o s . c l a s s ) and- ( p d u . o c l s <> q o s . c l a s s there A c c e p t a b l e _ € R FALSE; i f ( NOT qos-misc[Q LNO_EXPEDITED_DATA] and pdu .qos .misc [Q!_NO_EXPEDIT£D_DATA] ) o r ( NOT qos .mise [Q_GHECKSUM_IN_USEj! and-pdu .qos .misc (Q,_CHECKSUM;_i.N_USE]- ) o r ( NOT qos .misc [Q_NO_FLOW_CONTROL] and-pdu .qos .misc (Q_NO_FLOW_CONTROL ]' ) o r ( NOT qos.misc[Q_EXTENDED_FORMAT] and pdu.qos.misc(Q_EXTENDED_FORMAT] ) t h e n A c c e p t a b l e _ C R := FALSE ( • FUNCTION C h o o s e _ c l a s s < qos : Q O S _ T Y P E ) : Q_CLASS_TYPE; BEGIN. C h o o s e _ c l a s s := q o s . c l a s s END; (....,.......... .. . . . PROCEDURE C o n s t r u c t a d d r ( VAR t r a n s p o r t a d d r : ADDR TYPE; s u f f i x n e t _ a d d r BEG IU t r a n s p o r t _add i : . su f f i x : = s u f f i x ; t r a n s p o r t _add r . p r e f i x := net_addi: END; SUFFIX_TYPE; NADDR TYPE); ( . . . . FUNCTION Get n c e p ( nc : NS_TABLE; I j i a d d r , f i M < k i r : MAl>UK_TVi'e. . : N C £ P _ i D _ r i V c ; n i d : NCEP_ID_TYPE; n o t d o n e : boo lean,-n o t d o n e := TRUE: n i d := 1; w h i l e n o t d o n e and ( n i d <- MAX NC.".P_ !D ) do beq i n i f Same n a d d r I f: naddr. n c ( n i d I . £ _ n c t _ a d d r ) t h e n b e g i n n o t d o n e := FALSE; G e t _ n c e p := n i d end e l s e n i d : - n i d + 1 end; n i d := 1; (* A new network c o n n e c t i o n is r e q u i r e d «) w h i l e n o t d o n e and ( n i d •: = M A Z _ N C E P _ I D ) do b e g i n i f n c ( n i d ) . s t a t e = NIDLE t h e n b e g i n n o t d o n e :~ FALSE; G e t _ n c e p := n i d end e 1 se n i d := n i d ± 1 end ; i f n o t d o n e t h e n G e t _ n c e p :• 0 END ; FUNCTION G e t _ s u f f i x ( t r a n s p o r t _ a d d r : ADDR TYPE ) : SUFFIX_TYPE; BEGIN G e t _ s u f f i x ;= t r a n s p o r t _ a d d r . s u f f i x END; (**..**«*.**»*..*.*.*..*,«,..«...«.,..*.*«*,***...*....*...««..* FUNCTION Min( m, n : i n t e g e r ) : i n t e g e r ; BEGIN i f m > n t h e n Min := n e l s e Min := in END ,-( . » . * . * . . . . . . . . . FUNCTION N c _ m u l t i p l e x e d ( np BEGIN i f n p . l i n k > 1 t h e n N c _ m u I t i p l e x e d e l s e N c _ m u l t i p l e x e d END ,-VAR LIE;; I N NS_MACHINE ) : b o o l e a n ; := TRUE : = FALSE FUNCTION New_nc_requ i r e d ( nc : NS_TA/3I,E; l a d d r , f a d d r : ADDR_TYPE ) : boo lean.-VAR n i d : NCEP_ID_TYPE; no t d o n e ; b o o l e a n ; BEGIN n o t d o n e := TRUE; n id . 1 ; while notdone and ( i h d <= MAX_NCEP_ID ) do beg in i f ( n c ( n i d ) . s t a t e <> NIDLE ) and Same naddr ( nc ; :i id ] . z __net_addr , f addr . p re f i :•: ) then beg in notdone := FALSE; N e « _ n c _ r e q u i r e d := FALSE end e l s e n id : = n id t- 1 e nd ; i f notdone then New nc r e q u i r e d ;= TRUE END. _ ~ FUNCTION S i z e l data .- DATA_TYPE ) : i n t e g e r ; BEGIN S i z e ;= d a t a . d l e n END; I n i t i a l i z a t i o n INITIALIZE 3EGIN for t i d beg in t c [ t i d t c [ t i d t c ( t id tc 11 i d t c [ t i c cc ( t i d t c [ t i d tc [ t i d t c [ t i d t c [ t i d t c [ t i d t c [ t i d t c ( t i d t c [ t i d 1 to MAX TSA?_ . s t a t e . n c e p _ i c . s cc re £ . d s t _ r e f . snd_uppe r_-2 . snd_sec .s nd_una . snd' nxt .rcv__nxt .rcv_upper_edge . x_seq. .x_nxt . xsnd_n>:t . x una CLOSED; 0; UNDEF r.MED_REFEREN'C:-: ; UNDEFINED REFERENCE; = 0 = 0 = 0 = 0 := 0; := DEF BUFFER M; = 0 = 0 = 0 = 0 f o r q k i n d ;= Q_NO_SX?EDITED_DATA to Q_EXTENDED_FORMAT do t c [ t i d ] .qua 1 of s e r v i c e . m i s c i q k i n d ] := FALSE; t c l t i d ] . q u a l _ o f _ s e r v i c e . c l a s s CLASS TWO; t c l t i d ] . r e a s o n := NORMAL; t c ( t i d ] . m a x _ T P D U _ siz e t c [ t id] .DT maxlen := DEF_TPDU_SZ; := DEF TPDU SZ NOR DT HEAD t c ( t i d ) . s b u f t c [ t i d ] . r b u f tc (t id) . . xbuf end; = N I L ; = NIL; = NIL for n i d beg in nc [ n nc(n id] nc I n nc | n n c [ n i d i end = 1 to MAX NCF.P ID do state l i n k nqos sbuf rbu f = NIDLE; = 0; = CLASS TWO; = NIL ; = NIL END; <* I n i t i a l i z a t i o n *) ( ' T rans ir. ions * ) ( • • ) WHEN T C E P [ t id] . T_CONNECT_request (* T r a n s i t i o n PROVIDED { ( tc 1 t i d ] . S t a t e - CLOSED ) and ( Ne-< nc required! nc, From t ranspo rt__add r, To_t ransport_addr ) ) -.: ( Choose_class( Qua1_of_service ) = CLASS TWO ) a ( Size! TS_user_data ~) <= MAX_CRCC_SZ " ) ) KEG IN t c [ t i d ) . state CALLING; t c f t i d ] . l o c a l _ a d d r t c ( t id] .remote_add r t c ( t id] . l _ s u f f i x t c ( t i d ] . f s u f f i x := Prom transport addr; := To_transport_addr; := G e t _ s u f f i x ( Erom_transport_addr ) := Get s u f f i x ( To transport_addr ); Get_net_addr( tc11id 1 .l_net_addr, From_transport_addr ) Get_net_addr( t e l t i d ] . f _ n e t _ a d d r , T o _ t r a n s p o r t a d d r ); nid := Get_ncep( nc tc11id] .ncep_i d t c [ t i d ] . q u a l _ o f _ s e r v i c e := Qual_of_service S t o r e ( t c ( t i d ] . s b u f , TS_user data, 0, 0); tc (t id] . l_net_addr, tc (t i d ) . f__not_acd r = n i d ; nc[n id] .state nc(nid] .l_net_add r nc [ n i d ] . f _ne t_add r n c [ n i d ] . l i n k nc f n id] .nqos NWAITING; t c [ t id 1 .l_ner tc [ t i.ri ] . f_net 1 .-Qua 1 of serv: _addr addr OUT NSAP [nid) .N_CONNECT_tequest ( nc { r. id) . l_r.e t_adc r , nc[nid].f net addr, nc[n id] .nqos ) END ; T R A N S WHEN NSAP[nid].N_CONNECT_confirm PROVIDED n c [ n i d ] . s t a t e = NWAITING BEGIN. n e [ n i d ] . s t a t e := NOPEN; for t i d := 1 to MAX_TSAP_ID do begin i f ( t c [ t i d ] . n c e p _ i d - nid) and ( t c [ t i d ] . s t a t e = CALLING) then begin tc [t id] . st a t e := CR_SF.NT; t c { t i d ] . s r c _ r e f := A l l o c _ r e f ; R e t r i e v e ( t e l t i d ] . s b u f , 0, 0, temp); 0, 0, TRUE); Re l e a s e ( t c [ t i d ] .sbuf Construct CR( data, ( * T r a n s i t i o n 2 t c [ t id] .rcv_upper_edge, t c ( t i d ) . s rc_re f, t c [ t i d ] . l _ s u f f i x , t c ( t i d ] . f _ s u f f i x , tcftid).max_TPDU_size, t c f t i d ] . q u a l _ o f _ s e r v i c e temp ); Concatenate_2_NSDU ( nc(nid). end (- i f CALLING *) end ( ' f o r loop *) data ) (* T r a n s i t i o n 3 *) and WHEN TCEP[tid].T_CONNECT_request PROVIDED ( ( t c ( t i d ] . s t a t e = CLOSED ) ( NOT New_nc_requi red ( nc, From__t ransport_addr To transport addr ) ) and TRANS ( Choose c l a s s ! Qua L _o t. _s e •_• v i c o ) « c;..\.->s_rw3 ) 3n</ { S i z e l T S _ u s e r _ d a t a ) <= MAX_CRCC_SZ ) ) B E G I N t.; ! i: i ri ] . s t a t e : « CR _SF.NT; t.; ( t i d | . l o c d i _ a d d r : • •': : : . . X.:: 11 id ) . remor.e_add: : - T:)_tr.ir.:i?or-:_JCc:; ! .; (t i<11 . I 3 u f f i x : * >J.;r. s u f f i x ! :-'::om_t ranspo r r._add r ); r . ( t i d 1 . f J s u f £ ix ."et s u f f i x ! I'o_t r a ns po r1 _add r ): Get n c t _ * d d r ( t c f t i d l . ! ::;:r._.iiidr, F r o m _ t r a n s p o r t _ a d d c ) ; G e t ~ n e t _ a d d r ( t c 11 i d ] . £_;-,ec _addr, T o _ t r a n s p o r t _ a d d r ) ; n i d := G e t _ n c e p ( nc, t c < t i d 1 . l _ n e t _ a d d r , t c [ t i d ] .£_net_addc ); t c ( t i d ] . n c e p _ i d := n i d ; nc I n i d 1 . L i n k : = nc ( n i d 1 . 1 i n k *• 1 ; t c [ t i d ) . q u a l _ o f _ s e r v i c e :« O u a L _ o f _ s e r v i c e ; t c 11 i d | . s rc__re f : = A l l o c r e f ; C o n s t r u c t CR( d a t a , -_ c i t i d 1 . rc v_uppe r_edge , t c i t i d J . s r c _ r e f, t ; I t i d ] - l _ s u f f i x , t c f t i d ] . r s u f f i x , t c i'ti.dl .max_TPDU_size, : c [ t i d ] .qua i _ o f _ s e rv i c e , ? S _ u s o c _ d a t a ); C o n c a t e r . a t e _ 2 NSDU i r . c i r s i d ] , d a t a ) END ; WHEN NSAP [ n i d ] . N_DATA_i.-.d i c i t i o n PROVIDED n c I n i d ) . s t a t e = NOPEN BEGIN n s d u _ l e n := 0; w h i l e ( n s d u _ l e n < N S _ u s e r _ d a t a . d l e n ) do b e g i n E x t r a c t _ T P D U 0 N S _ u s e r _ d a t a , d a t a , n s d u _ l e n ) ; t i d := D e t e r m i n e _ T C (• t e , d a t a , pdu ); i f t i d <> 0 t h e n b e g i n 1 U n c o d e ( p d u , d a t a , t c ! t i d ) .quaI_of_service.raise(Q_EXTENDED_FORMAT i f p d u . k i n d = CR C CR TPDU *) t h e n b e g i n i f t c [ t i d ] . s t a t e = CLOSED t h e n b e g i n {• t r a n s i t i o n •< ') i f A c c e p t a b l e CR( t c [ t i d ] . q u a l _ o £ s e r v i c e , pdu ) t h e n b e g i n t c ( t i d ] . s t a t e := CR_RCVD; OUT S A P N ( n i d ] . T i m e r _ c a n c e l ( INCOMING_NC, 0, TRUE ); t c ( t i d ] .£_su£ £ix := p d u . l s u f ; t c ( t i d ) . l _ s u f £ i x ;= p d u . f s u f ; t c [ t i d ] . f _ n e t _ a d d r := n c ( n i d ] . f _ n e t _ a d d r ; t c (t i d 1 . I_ne t _add r := nc ( n i d 1 . I _ n e t _ a d d r ,-t c ( t i d ) . n c e p _ i d := n i d ; C o n s t r u c t _ a d d r ( t c f t i d l . l o c a i _ a d d r , t c [ t i d j . l _ s u f f i x , t c ( t i d ] . l _ n e t _ a d d r ); C o n s t r u c t _ a d d r ( t c [ t i d ) .remote_addr, t c ( t i d ) . f _ s u f f i x , t c ( t i d ) . f n e t a d d r ); t c [ t i d ] . q u a l _ o f _ s e r v i c e := pdu.qos.-t c ( t i d ) . m a x T P D U _ s i z e := M i n ( pdu.maxsz, t c ( t i d ) .max_TPDU_siz. t c ( t i d l . d s t te£ :» p d u . s r e f ; t c ( t i d ] . s n d _ u p p e t _ e d g e ;= p d u . c d t ; OUT TCEP [ t i d ] . T _ C O N N E C T _ i n d i c a t i o n ( t c ( t i d ) . remote_add v.. t c [ t i d I . I o c a 1 add r, pdu . qo:'., pdu.da t a ! end (* A c c e p t a b l e CR *) e l s e b e g i n (* t r a n s i t i o n 5 *) t c ( t i d ] . d s t _ r e f := p d u . s r e f ; t c [ t i d ] . r e a s o n := NEGOTIATION_FAILED; E m p t y _ d a t a ( temp ); C o n s t r u c t _ D R ( d a t a , t c ( t i d ) . d s t _ r e f , 0, t c [ t i d ] . r e a s o n , temp); C o n c a t e n a t e _ 2 _ N S D U ( n c ( n i d ) , d a t a ) end (* NOT A c c e p t a b l e CR-*) e n d (* CLOSED •) end; ( * CR TPDU ») i f p d u . k i n d = CC (* CC TPDU *) t h e n b e g i n i f t e l t i d ) . s t a t e = CR_SENT (• T r a n s i t i o n i •) t h e n b e g i n i f A c c e p t a b l e _ C C ( t c f t i d ] . q u a l _ o f _ s e r v i c e , t c 11 i d ) .s r c _ r e : , pdu ) t h e n b e g i n t c [ t i d ] . s t a t e := ESTABLISHED; t c ( t i d ) . d s t _ r e f t c [ t i d ]•. s nd;_u ppe r_edge t c [ t i d ) . q u a i _ o f _ s e r v i c e t c [ t i d ] . m a x TPDU s i z e = pdu.s re f; = p d u . c d t ; = pdu.qos; = pdu.maxsz; OUT T C E P ( t i d ] . T _ C O N N E C T _ c o n f i r m ( pdu.qos, p d u . d a t a ) end. (•* A c c e p t a b l e CC * e l s e b e g i n (.* T r a n s i t i o n 7 * )• t c [ t i d ] . s t a t e := CLOSING; t c [ t i d ] . d s t _ r e f := p d u . s r e f ; t c [ t i d ] . r e a s o n ;= NEGOTI AT ION__FAILED; E m p t y _ d a t a ( temp ); OUT T C E P [ t i d ) . T _ D I S C O N N E C T _ i n d i c a t i o n ( t c ( t i d ] . r e a s o n , temp) ; C o n s t r u c t _ D R ( d a t a , t c ( t i d ] . d s t _ r e f , t c [ t i d 1 . s rc_re£, t e l t i d ] . r e a s o n , temp); C o n c a t e n a t e _ 2 _ N S D U ( n c l n i d ] , d a t a ) e n d (* NOT A c c e p t a b l e CC *) end (* CR_SENT •) e n d ; <• CC TPDU *) i f p d u . k i n d = DT (* DT TPDU *> t h e n b e g i n i f t c f t i d ) . s t a t e = ESTABLISHED (* T r a n s i t i o n 3 «) t h e n beg i n i f ( p du.seqno = t c ( t i d ] . r c v _ n x t ) and ( p du.seqno < t c ( t i d ] . r c v _ u p p e r _ e d g e ) t h e n b e g i n M erge( t c ( t i d ] . r b u f , pdu ); t c [ t i d ] . r c v _ n x t S E Q A D D ( t c ( t i d ] . r c v n x t , 1, t e l t i d ] . q u a l _ o f _ s e r v i c e . m i s c ( Q _ E X T E N D E D _ F O R M A T ] ); i f p d u . e f l a g (* a c o m p l e t e TSDU i n t h e b u f f e r t h e n b e g i n Ext r a c t _ T S D O ( t c 11; i d ] . r b u f , d a t a , n ) ; R e l e a s e ! t c ( t i d ) . r b u f , t c (t i d ] . rc v _n v. t , DT, FALSE ). <* u p d a t e t h e upper edge o f the r e c e i v i n g window ') t c I t i d ] . r c v _ u p p e r _ e d g e := SEQ A D D ( t c [ c i d ] . r c v _ u p p e r _ e d g e , n, t c ( t i d ) . q u a l _ o f Se rv i ce . m i s c [ O EXTENDED JRMAT I ) OUT T C E P [ t i d ) . T _ D A T A i n d i c a t i o n ( d a t a ) .-(* compute t h e c u r r e n t b u f f e r s p a c e M n := SEQ_MINUS( t c l t i d ] . r c v _ u p p e r _ e d g e , t c l t i d ) . r c v _ t c ( t i d ) . q u a l _ o f _ s e r v i . c e .misc (Q_EXTENDED_FORMA C o n s t r u c t _ A K ( d a t a , n, t c (t i d ] . ds t _ r e f, t c ( t i d ] . r c v _ t c l t i d ] . qua l _ o f _ s e rv i c e . rnisc (OEXTENDED FORMAT] " C o n c a t e n a t e _ 2 _ N S D U ( n c [ n i d ] , d a t a ) .-i f n = 0 t h e n OUT S A P T ( t i d ) . T i m e r _ r e q u e s t I WINDOW, WN_SVNC, 0 ) e l s e OUT SAPT [ t i d ] -T ime r _ c a n c e 1 { WINDOW, 0, TP.'JE ) end (* pdu.e f l a g •) end (* r e c e i v a b l e DT *) e l s e b e g i n (- T r a n s i t i o n 9 '} t c ( t i d ) . r e a s o n := INVALID_T?DU; C o n s t r u c t _ E R R ( d a t a , t c [ t i d i . d s t _ r e f , t c [ t i c ; . r e a s o n , o d u . d a t a ); Co n c a c e n a t e _ 2 _ N S D U I n c f n i d ] , d a t a ) end (• NOT r e c e i v a b l e DT -) end' I* ESTABLISHED ") e n d ; (* D T T P D U * ) , i f p d u . k i n d : = AK-t h e n b e g i n i f (( t c ( t i d ) . s t a t e = E S T A B L I S H E D ) o r ( t c [ t i d ] . s t a t e = C L O S I N G ) ) and (* T r a n s i t i o n 1 0 " ( pdu.seqno >= t c [ t i d ] . s n d _ u n a ) t h e n b e g i n t c ( t i d ] . s n d _ u n a := pdu.seqno; t c ( t i d ) . s n d _ u p p e r _ e d g e := SEQ_ADD( t c [ t i d ] . s n d _ u p p e r _ e d c p d u . c d t , t c l t i d ] . q u a l _ o f _ s e r v i c e .misc |Q_EXTENDED_FOR-MA R e l e a s e ! t c [ t i d ] . sbu £, t c [ t i d i . snd_una , DT, FALSE ); Resume_data{ t c l t i d ] , n c [ n i d ] ) end C ESTABLISHED and AK ok *) end. (• AK TPDU *) i f p d u . k i n d = XPD , t h e n b e g i n i f t c ( t i d ) . s t a t e = ESTABLISHED Chen b e g i n i f p du.seqno = t c ( t i d | . x _ n x t t h e n b e g i n (* T r a n s i t i o n 1 1 -] OUT T C E P ( t i d ] . T _ X P D _ i n d i c a t i o n ( p d u . d a t a ); C o n s t r u c t _ X A K ( d a t a , c c ( t i d ) . d s c _ r e f , t c l t i d ) . x nxt, t c l t i d ) . qua l _ o f _ s e r v i c e . m i s c IO_EXTF.NDED_FC'-tMAT ] ) ; C o n c a t e n a t e _ 2 _ N S D U ( nc [ n i d ] , d a t a I .-t c ( t i d ] . x _ n x t := SEQ_ADD( t c ( t i d ) . x _ n x t , 1, t c l t i d ] . q u a l _ o f _ s e r v i c e . m i s c ( Q _ E X T E N D E D _ F O R M A T ] ) end e l s e b e g i n t c l t i d ] . r e a s o n := INVALID TPDU; C o n s t r u c t _ E R R ( d a t a , t c l t i i i ) . d s t _ c e f , t e l t i d ) p d u . d a t a ) ; C o n c a t e n a t e 2 MSDU< n c l n i d l , d a t a ) end e n d (• E r i T A i M . I S i l E D and OK •) end; i f pdu . k i n d -•= X A H t hen beg i.n i f (( t c | r. i d i . s t a t-.- -•  l - : : .TA. .U.i SHED ) o r ( t c 11 i d I . s t a t e = CLOSING)) and ( pdu . seqno -• t c f t i d ] . : - ; j ina ) t h e n b e g i n (' T r a n s i t i o n t c [ t i d 1 .x_una -. = t c [ t i d ] . x s n d _ n x t ; Resume_xdata ( t c [ t i d ] , n c { n i d ] ); Resume d a t a ( t e l t i d ] , n e f n i d ] ) e n d end; i f p d u . k i n d = ERR t h e n b e g i n (* T r a n s i t i o n i f { i t c [ t i d I . s t a t e = CALLING ) o r ( t c ( t i d ] . s t a t e = CR_SENT ) or ( t c i t id ] . s t a t e = CR__RCVD ) o t ( t c [ t i d ] . s t a t e = ESTABLISHED ) o r ( t c [ t i c ] . s t a t e = CLOSING ) ) t h e n b e g i n t c [ t i d ] . s t a t e := CLOSING; Empty d a t a ! temp ) ; r e a s o n := ?ROTCC0L_ERROR; OUT T C S ? 11 i d ) . T_0 £ 3CO?JNECT_indic«ic i o n ( re a s o n , temp OUT S A ? T [ t l d i . 7 i . - e r _ c « m c e i ( ALL_TIMER, 0, TRUE ); C o n s t ruct_DR ( d a t a , t c (t i d )' . ds t _ r e f, t c i t i d ) . s r c _ r e r e a s o n , temp ) ; C o n c a t e n a t e _ 2 _ N S D U ( n e f n i d ] , d a t a ) end- {* a c t i v e c o n n e c t i o n *) en d ; (,* ERR TPDU *). i f p d u . kind- = DR-t h e n b e g i n i f ( ( t c [ t i d ) - . s t a t e = CR_RCVD ) o r (• T r a n s i t i o n ( t c [ t i d ] . s t a t e = CR_SENT ) o r ( t c ( t i d ) . s t a t e = ESTABLISHED ) ) t h e n b e g i n OUT T C E P i t i d ] . T _ D I S C O N N E C T _ i n d i c a t i o n ( p d u . r e a s o n , p d u . d a t a ); C o n s t r u c t _ D C ( d a t a , t c [ t i d 1 .dst_re£, t c 1 1 i d ) . s t c r e : C o n c a t e n a t e _ 2 _ N S D U ( n c ( n i d ) , d a t a ); OUT S A P T [ t i d 1 . T i m e r _ c a n c e l ( ALL_TIMER, 0, TRUE ); i f N c _ m u 1 t i p l e x e d ( n c [ n i d l ) t h e n b e g i n t c [ t i d ] . s t a t e := CLOSED; Re l.ease_a 1 L ( t e l t i d ) , n e f n i d ] ) end (* N c _ m u 1 t i p l e x e d *) e l s e t C ( t i d ) . s t a t e :='DISCON_WAIT en d (" CR_SENT, CR RCVD, ESTABLISHED •) en d ; (* DR TPDU *) i f t c [ t i d l . s t a t e - CLOSING t h e n b e g i n i f ( ( p d u . k i n d = DR > o r ( p d u . k i n d = DC ) ) t h e n b e g i n t c [ t i d ] . s t a t e : -- CLOSED; ( • T r a n s i t run ' ^  OUT S A P T f t i d ] - T i m e r _ c a n c e l ( ALL_TIMER, 0 , TRUE ); i f NOT Nc_mu 11 l p l e x e d ( n e f n i d ] ) t.':ea OUT NSAP|nid] N_DISCONNECT_request; Re 1 e a s e _ a I I ( t e l t i d ] , n c l n i d ) ) end (* DR TPDU, DC TPDU ') end (* CLOSING •) end (* t i d <> 0 *) e l s e b e g i n i f ( p d u . s r e f <> UNDEFINED_REFERENCE) and ( p d u . k i n d <> DR) and ( p d u . k i n d <> DC) t h e n b e g i n E m p t y _ d a t a ( temp ); C o n s t r u c t DR( d a t a , p d u . s r e f , 0 , pdu. r e a s o n , temp); C oncatenate_2_NSDU( n e f n i d ] , d a t a ) end end end (* wh i l e l o o p *) END ; TRANS WHEN NSAP[nid].N_CONNECT_ PROVIDED n c [ n i d ] . s t a t e BEGIN n c i n i d ) . s t a t e NOPEN; i n d i c a t i o n = N IDLE T r a n s i t i o n n c l n i d ) .1 n e t a d d r := To n c c u o r k a d d : ; nc [ n i d ] . f _ne t _ a d d r := F :oin_r.etuo r k _ a c c r ; r.c ( n i d ) . l i n k : - 0; OUT NS A P ( n i d ] . N _ C 0 N N E C 7 _ r e s p o n s e ; CUT SAPN(nid) .Timer_r-3cuest ( INCOMING_NC, .\'E7_WAIT, 0 ) DND; TRANS WHEN N S A P [ n i d ] . N _ D I S C O N N E C T _ i n d i c a t i o n PROVIDED ( n c ( n i d ) . s t a t e = NOPEN ) BEGIN n c ( n i d ] . s t a t e := NIDLE; (* T r a n s i t i o n 17 *) i f n c ( n i d ] . l i n k > 0 t h e n b e g i n f o r t i d := 1 to.-MAX_TSAP_ID do b e g i n i f t e l t i d ] . n c e p _ i d = n i d t h e n b e g i n (" T r a n s i t i o n 18 *) i f ( ( t c ( t i d ) . s t a t e = CR_RCVD ) o r ( t c ( t i d ] . s t a t e = CR_SENT ) or ( t c f t i d ] . s t a t e = ESTABLISHED ) ) t h e n b e g i n t c [ t i d ] . s t a t e -. = CLOSED; E m p t y _ d a t a ( d a t a I ; OUT T C E P ( t i d 1 .T_DISCONNECT_ i n d i c a t i o n ( LOSS_OF_NETWORK_CONNECTION, d a t a ); OUT S A P T ( t i d ] . T i m e r _ c a n c e l ( ALL_TIMER, 0 , TRUE ); R e l e a s e _ a l l ( t e l t i d ] , n e f n i d ) ) end; C CR_RCVD, CR_SF.NT, ESTABLISHED •) i f t c ( t i d ] . s t a t e •= CALLING (• T r a n s i t i o n 19 •) t h e n b e g i n t c [ t i d ] . s t a t e := CLOSED; Empty d a t a ( d a t a ); OUT T C E P ( t i d ] . T _ D I S C O N N E C T _ i n d i c a t i o n ( NETWORK_CONNECT_FAILED, d a t a ) ; OUT S A P T ( t i d ) . T i m e r _ c a n c e l ( ALL_TIMER, 0, TRUE ); R e l e a s e _ a l l ( t c l t i d l , n c ( n i d ) ) end; C CALLING *) i f t c f t i d l . s t a t e •> CLOSING (* T r a n s i t i o n 20 •) t h e n b e g i n t c ( t i d 1 . s t a t e := CLOSED; i f Reason NORMA!, t hen be'; : n Empty_data I d a t a ) ; OUT TCEP i t i d I . T_D I SCONN'rXT_ i n d i c a v. i o n ( LOSS_OF_NETWORK_CONNECTION, d a t a ) end; Re l e a s e _ a 1.1 I t c l t i d ] , nc [ n i d ] ) end; <• CLOSING *) i f t c ( t i d ] . s t a t e = DISCON_WAIT I* T r a n s i t i o n 21 •) t h e n b e g i n t c l t i d ] . s t a t e := CLOSED; R e l e a s e _ a l l ( t c l t i d ] , n c [ n i d ] ) end (• DISCON_WAIT ') end (" m a t c h i n g t r a n s p o r t c o n n e c t i o n *) end (* f o r l o o p "! end ( " l i n k > 0 -) e l s e OUT SAPN | n i d ! . T irr.e r _ c a n c e l ( iNCOMING_NC, 0, TRUE ) END ; WHEN T C E P [ t i d ) . T _ C O N N E C T _ r e s p o n s e ' (" T r a n s i t i o n 22 -) PROVIDED <• ( t c [ t i e ] . s t a t e = CR_RCVD ) and ( Choose_c l a s s (• Qua i _ o f _se r v i c e ) = CLASS_TWO ) and ( S i z e ! T S _ u s e r _ d a t a ) < = MAX_CRCC_SZ- ) ) BEGIN t c [ t i d ] . s t a t e := ESTABLISHED; t c [ t i d ] ' . s r e _ r e f := A l l o c _ r e f ; t c 11 i d ] . . qua l _ o f _ s e r v i c e ;= Q u a l _ o f _ s e r v i c e ; C o n s t r u c t _ C C ( d a t a , t c [ t i d ] . r c v _ u p p e r _ e d g e , t c [ t i d ] .s r c _ r e f - , t c [ t i d ] - . d s t _ r e f , t c ( t i d ]' . i _ s u £ f i x, t c [ t i d ] : . E _ s u f f i x , t c [ t i d ] . m a x _ T P D U _ s i z e , t c l t i d ) . qua l-_of se rv i c e , T S _ u s e r _ d a t a ); nid- := t c l t i d l . ncep_id-; C oncatenate_2_NSDU ( n c ( n i d ] , d a t a ) END; WHEN T C E P ( t i d ] . T _ D I S C O N N E C T _ r e q u e s t (* T r a n s i t i o n 23 PROVIDED t c 1 t i d ] . s t a t e = CR_RCVD BEGIN t c [ t i d ] . s t a t e := DISCON_WAIT; t c ( t i d ] . s r c _ r e f := A l l o c _ r e f ; t c ( t i d ] . r e a s o n := CONN_REJECT; C o n s t r u c t _ D R ( d a t a , t c 1 1 i d ) . d s t _ r e f , t c It i d ] . s r e r e f , t c l t i d ] .rea son, T S _ u s e r _ d a t a ) ; n i d := t c ( t i d ] . n c e p _ i d ; C o n c a t e n a t e 2 NSDU ( n c ( n i d ) , d a t a ); Release a l l ( t c f t i d ] , n c ( n i d ) ) END; P R O V I D E D ( ( t e l t i d ! . s t a t e ( t c l t U i ! . s t i t e 3 EG I N t c ( t i d ] . s t a t e C W S If!' t c 1 1 i d ] . r e a s o n C o n s t r u c t DR( * NO R M A L ; t c 11 i d ] .:.; rc__::e t , tc; ( t i d | . r e a s o n , TS u s e r d a t a ) : S t o r e f t c ( t i d ] . s b u f , d a t a , 0, DR ) ; n i d := t e l t i d ] . n c o p _ i d ; R e s u m e _ d a t a ( t c ( t i d ] , n c l n i d ] ) ; OUT S A P T [ t i d ) . T i m e r c a n c e l ! A L L TIME! E N D ; WHEN T C E P ( t i d ) . T _ D A T A _ r e c ; u e s t P R O V I D E D t e l t i d ] . s t a t e = E S T A B L I S H E D B E G I N A d d _ r e q u e s t ( t e l t i d ] , TS u s e r d a t a ) ; n i d := t c ( t i d J . n c e p _ R e s u i n e _ d a t a ( t c [ t i d ] , LND; : [ n i d ] ) WHEN T C E P [ t i d ] . T _ x ? D _ r e q u e s t <- 7 : 2 f ! S i r . i o n P R O V I D E D ( t e l t i d ] . S t a t e = E S T A B L I S H E D ) a.-.d ( S i z e ( TS u s e r d a t a ) < = MAX_:<7SDU_SZ 1 B E G I N C o n s t r u c t _ X ' P D ( d a t a , t c 11 i d J . d s t _ r e f , t c '• z i d ] . :-:_seq, t c [ t i d ) . q u a l _ o f _ s e r v i c e . m i s c [Q_EXTENDED_roR. M-AT j , T S _ u s e r _ d a t a ) ; t c [ t i d ] . x _ s e q := SEQ_ADD( t c ( t i d ) . x _ s e q , 1, t e l t i d ] . q u a l _ o f _ s e r v i c e . m i s c [ Q _ E X T E N D E D _ E O R M A T ] ) S t o r e f t c ( t i d ) . x b u f , d a t a , t c [ t i d ) . x s n d _ n x t , XPD ) ; n i d := t c ( t i d ) . n c e p _ i d ; R e s u m e _ x d a t a ( t e l t i d ] , n c l n i d ] ) END; WHEN S A P N ( n i d ] . T i m e r _ r e s p o n s e P R O V I D E D ( Name = INCOMING_NC ) a n d ( n c [ n i d ] . s t a t e = NOPEN ) B E G I N n c [ n i d ] . s t a t e := N I D L E ; L r a n s L t L O : I OUT N S A P ( n i d ) . N _ D I S C O N N E C T _ r e q u e S t END; WHEN S A P T ( t i d ] . T i m e r _ r e s p o n s e {* T r a n s i t i o n 28 P R O V I D E D ( Name = WINDOW ) a n d ( t e l t i d ] . s t a t e = E S T A B L I S H E D ) B E G I N n := SEQ_MINUS ( t c ( t i d ) . r c v _ u p p e r _ e d g e , - c 11 i d ] . r c v _ n : - ; t . t e l t i d ] . q u a l _ o f _ s e r v i c e . m i s c ( Q _ E X T E N D E D _ F O R M A T ] i f n > 0 t h e n b e g i n C o n s t r u c t _ A K ( d a t a , n, t c ( t i d ) , d s t _ r e f , t c ( t i d ) . r c v _ n x t , t e l t i d ) - q u a l _ o f s e r v i c e . m i s c [ Q EXTENDED FORMAT) ) n i d t c ( t i d ) . n c e p _ i d ; Concatenate 2 N:'.DU ( nclnici), data ) OUT S APT (t id ] . T ime ::_cance 1 ( WINDOW, end T R U E ) OUT SAPTItidl E N D ; { * spontaneou VP A N.S t ransit ion Leanest ( W I N D O W , WN SV.VC, Send the network data anyway ') M A X N C E P r D do PROVIDED TRUE BEG IN for nid 1 begin if ncInid).sbuf <> NIL then begin Extract_NSDU( nclnid] .sbuf, ndata ) ; OUT NSAP1nid).N_DATA_request( ndata ) end end END; END ATP_process; MODULE RS_module; NCEP : NS primitives END RS_-;oduie; PROCESS RS_process ( RS_incex QUEUED NCEP; ( NS >rovide integer ) "OR mocuie; V A R rs_td local, remote qos reason data integer; NADDR_TYPE; NQOS_TYPE; REASON_TYPE; NDATA TYPE; (* Primitive functions and procedures FUNCTION Net_accept( rs_id VAR local, remote VAR qos PROCEDURE Net_close( rs_id FUNCTION Net_confirm( rs_id PROCEDURE Net_connect( rs_id loca 1 remote qos integer; NADDR_TYPE; NQOS TYPE ) integer ); integer ) : boolean; intege r; NADDRJTYPE; NADDR_TYPE; NQOS TYPE ) ; FUNCTION Net_disconnect( rs_id VAR reason integer; REASON TYPE ) ; boolean;PRIMITIVE PRIMITIVE PRIMITIVE PRIMITIVE boolean; PRIMITIVE FUNCTION Net_recv( rs_id VAR data integer; NDATA TYPE ) boolean; PRIMITIVE PROCEDURE Net_send( rs_id data intege r; NDATA TYPE ) PRIMITIVE INITIALIZE BEGIN rs_id := RS_index END; (* Initialization *) TRANS WHKN N C E P . N _ C O N N E C T _ r e q u e s t BEG IN l o c a l := F c o n _ n o i : w o r k _ a d d r ; r e m o t e := T o _ : i e t w o r k a d d r ; q o s : --• COS ; N e t c o n n e c t ( r s _ i . d , l o c a l , r e m o t e , c o s ) END; TRANS WHEN N C E P . N J . X N N E C T _ r e s p o n . s e B E G I N < « Do n o t h i n g : t h e N e t w o r k p r : :n i t i v e s h a n d l e : t. ') END; TRANS WHEN N C E P . N _ D A T A _ r e q u e s t B E G I N d a t a :~ N S _ u s e c j j a t a ; N e t s e n d ( r s _ i d , d a t a ) END ; TRANS WHEN N C E P . N D I S C O N M E C T _ r e q u e s t B E G I N N e t _ c l o s e ( r s _ i d ) END; TRANS P R O V I D E D N o t a c c e p t ( r s _ i d , l o c a l , r e m o t e , c o s ) BEG I N OUT M C E ? . H C C N S i C T i n d i c a t i o n ( r e m o t e , i o c a i , q o s ) END; TRANS P R O V I D E D N e t _ c o n f i r m i r s _ i d ) BEGIN-OUT NCEP . N_C0N'.V'ECT_ c o n f i rm END ; TRANS P R O V I D E D N e t _ r e c v ( r s _ i d ' , d a t a ) B E G I N OUT N C E P . N _ D A T A _ i n d i c a t i o n ( d a t a ) END; TRANS P R O V I D E D N e t _ d i s c o n n e c t ( r s _ i d , r e a s o n ) B E G I N OUT N C E P . N _ D I S C O N N E C T _ i n d i c a t i o n ( r e a s o n ) END; END R S _ p r o c e s s ; U l : TS u s e r m o d u l e w i t h T S _ u s e r__p r o c e s s ( 1 ) ; U2: T S _ u s e r _ m o d u l e w i t h T S _ u s e r _ p r o c e s s ( 2 ) ; A T P : A T P _ m o d u l e w i t h A T P _ p r o c e s s ; S I : S y s t e m _ m o d u l e w i t h S y s t e m _ p r o c e s s ( 1 ) ; S 2 : S y s t e m _ m o d u l e w i t h S y s t e m _ p r o c e s s ( 2 ) ; S 3 : S y s t e m _ m o d u l e w i t h S y s t e m _ p r o c e s s ( 3 ) ; S4 : S y s t e m _ m o d u l e w i t h S y s t e m _ p r o c e s s ( 4 ) ; R S I : R S _ m o d u l e w i t h R S _ p r o c e s s ( 1 ) ; R S 2 : R S _ m o d u l e w i t h R S _ p r o c e s s ( 2 ) ; CONNECT U l . T S A P TO A T P . T C E P ( l ) ; U2.TSAP TO A T P . T C E P 1 2 ) ; ATP.NSAP(1) TO RS1.NCEP ATP.NSAPI 2] TO RS2.NCEP ATP SAPT(1] TO S 1 SEP ; ATP SAPT(2) TO S2 SEP; AT P SAPN( I ! TO S3 SEP; ATP SAPN(2) TO SA SEP; END T c.inspo r t _ r e t; Appendix C System Initialization and Scheduler — For Semi-Automatic Implementation 66 fdtiutLL.c - , s y s t e m _ i n i t , schoduLo '4 I n c l u d e < ;> v s / £ yii.; ! ;i . ri> ? i. r.clude < s / s o c !-. er. . h inc: l u d e •' :>y J /' u i o . h > * i r u : Hide; < s y s / C i me b . h > s i n c L u d e < s y s / c i m e . h > if i n c l u d e < s y s / u n . h > « i n c l u d e <nef iner . / i n . h> S i n c l u d e < n e t d b . h > * i n c l u d e < e r r n o . h > H i n c l u d e < s i q n a 1 . h > J i n c l u d e < s t d i o . h > # i n c l u d e < s t r i n g s . h > ninclude "' . . / i n e u / i n e t . h* if i n c l u d e " l i s t d e f. s . h " S i n c l u d e " d e £ s . h " S i n c l u d e " C p d e f s . h " ? i n c l u d e " . . / t s p / t s p . h " / K D e f i n e Che o u t e r m o s t r e f i n e m e n t name * / " d e f i n e REF_NAM£ i o T r a n s p o r t _ r e f e x t e r n i n t s i g n a 1 _ p e n d i n g ; e x t e r n s t r u c t p r o c e s s _ b l o c k * p _ b l o c x . -e x t e r n N C O N N c o n n ( ] ; /, T h i s r o u t i n e c a u s e s t h e gen-: f o r d a n g l i n g c h a n n e l c o n n e c : s t r u c t p r o c e s s _ b i o c k * s y s t e r o _ i . - . i t () [ s t r u c t process block * p t r , - p r o c e s s l i s t , «remove header <! ; s t r u c t c h a n n e l _ b l o c k * c _ p t r ; s t r u c t i t i m e r v a l v a l u e ; i n t i , j ; / * u s e r i n c l u d e d d e l * / s t r u c t p r o c e s s _ b l o c k * R E F _ N A M E ( ) ; p r o c e s s _ l i s t = r e m o v e _ h e a d e r ( R E F _ N A M E ( N U L L ) ) ; f o r ( p t r = p r o c e s s _ l i s t ; p t r != N U L L ; p t r = p t r - > n e x t ) • ( i f ( s t r c m D ( p t r - > p _ i d e n t , " T S _ u s e r _ o r o c e s s " ) == 0 ) ( i = p t r - > 1 v a r s . s _ T S _ u s e r _ p r o c e s s . u s e r _ i c - 1; u p r o c e s s ( i ) = p t r ; I i f ( s t rcmp (pt r - > p _ i d e n t , " 5 vs t e m _ p r o c e s s " ) 0) ( i = p t r - > 1 v a r s . s _ S y s t e m _ p r o c e s s . s y s _ i d - 1; s p r o c e s s ( i ) = p t r ; ) i f ( s t r c m o ( p t r ~ > p _ i d e n t , " R S _ p r o c e s s " ) == 0) ( i = p t r - > l v a r s . s _ R S _ p r o c e s s . r s ^ i u - 1; r p r o c e s s f i ) = p t r : I f o r ( c j ) t c « p t r - > e h a n _ l i s t ; c _ p t r ! - N U L L ; : ; j i u -- c _ut r - :-ne :-:i:) ( i f ( c _ p t r - > t a r g e t _ c h a n n e 1 = = NULL) I / * o o p s a d a n g l i n g c o n n e c t i o n * / f p r i n t f ( s t d e r r , " \ n S Y S T E M I N I T I A L I Z A T I O N ERROR: d a n g l i n g " ) ; f p r i n t f ( s tde r r , " channel in an i n s t a n c e o f V S s V . " . p t r - > p _ i d e n t ) ; f p r i n t f ( s tde r r , "channel number %d, Lnd i d \ n " , c _ p t r - ><:_ id . c__pt r -> i n d e x j iuml I / ' j o i n t h e e n d s o f t h e p r o c e s s l i s t i n t o a l o o p * / f o r ( p t r = p r o c e s s _ l i s t ; p t r - > n e x t '= N U L L ; p t r = p t r - > n e x t ) ; p t r - > n e x t = p r o c e s s _ l i s c ; E s t a b l i s h i n g c o n n e c t i o n t o t h e s y s t e m e n v i r o n m e n t / / " f i r e up a c l o c k * / v a l u e . i t _ i n t e r v a l . t v _ s e c = v a 1 u e . i t _ v a l u e . t v _ s e c = 1 1 ; v a l u e . i t _ i n t e r v a 1 . t v _ u s e c = v a l u e . i t _ v a l u e . t v _ u s e c = 0 1 ; s e t i t i m e r ( I T I M E R V I R T U A L , S v a l u e , ( s t r u c t i t i m e r v a l M O ) ; s i g n a l ( 5 IGVTALRM", c l o c k ) ; / * s e t up t i m e r l i s t s * / f o r ( i = 0 ; i < N T I M E R ; i * - + ) t irrter l i s t I i ) = N U L L ; / * o p e n a n e t w o r k l i s t e n e r * / i f ( ( i = N _ o p e n ( S c o n n [ 0 ] , NSNAME) ) != MET_OK) i n p r i n t f ( s t d e r r , " > > > N ooers p r o b l e m ' i d \ n " , i ) ; e x i t ( 1 ) ; } n e t m a s k - ( 1 << c o n n ! 0 ] - > s o c k e t ) ; r!C i n u s e = 0 ; f o r ( r = 0 ; i < M A X _ N C E ? _ I D ; : * r ) { n e t p o o l [ i ] . f i l l = F A L S E ; n e t r e a s o n ( i ) = N E T _ O K ; n e t _ s t a t u s [ i ] = N E T _ N O R M A L ; ) / * o p e n a UNIX l i s t e n s o c k e t * / i f ( ( u s o c k ( 0 ) = TS o p e n ( T S N A M E ) ) < 0 ) ( f p r i n t f ( s t d e r r , " > > > T S _ o p e n p r o b l e m % d \ n " , u s o c k ( 0 ) ) , -e x i t ( 1 ) ; I / * e s t a b l i s h t h e i n t e r - p r o c e s s c o n n e c t i o n s " / f o r ( u s e r m a s k = 0 , i = 1 ; i <= M A X _ T S A P _ I D ; i++) ( s t r u c t s o c k a d d r _ u n f r o m ; i n t l e n = s i z e o f ( s t cue t s o c k a d d r _ _ u n ) ; 1 = 1 - 1 ; u s e r p o o l ( j ) . f i l 1 = F A L S E ; e r r c l o s e ( j ) = F A L S E ; u s o c k [ i ] = a c c e p t ( u s o c k ( 0 ! , ( s t r u c t s o c k a d d r ' I S f r o m . s l e n ) i f ( u s o c k [ i ] < 0 ) I p e r r o r ( " U N IX d o m a i n ; a c c e p t " ) ; e x i t ( 1 ) ; I u s e r m a s k |= (L << u s o c k I i 1 ) ; I c l o s e ( u s o c k ( 0 ) ) ; / • c l o s e t h e l i s t e n e r * / r e t u r n ( p r o c e s s _ l i s t ) ; / " This i s the main d r i v i n g routine. schedule(p roces s_L i st) s t r u c t proces.-5_bl.ock * p rocess_ L i s t : I extern i n t signal_pending; extern s t r u c t process_block *p_block; s t r u c t channel_block *c_ptr. s t r u c t s i g n a l _ b l o c k *s_ptr, *get_s ignaI () ; s t r u c t process_block *p_ptr, *p_ptr2; s t r u c t timer_block ' t p t r l , *tptr2; s t r u c t timeval timeout; i n t i , j , n, mask, notdone; p_pt r = p_ptr2 = p r o c e s s _ l i s t ; c_ptr = p_pt r->chan_ i. i s t; signaImpending = 0; while ((usock[l] != -1) I! (usock(2) != -1)) /* while there is a. us ( i f (signal_pending > 0) I s_ptr = get_signa1(Sc_ptr, £p_ptr); s ignal_pencing--; /* c a l l the t r a n s i t i o n routine */ p__'olock = p_otr; ("(p_pt r->proc_pt r) ! (c_pt r, s_ot r) ; /• move on to the next channel for the st a r t o f the ::e:-:t so. i f (c_ptr->next !* NvLI») e l s e 1 p_ptr - p_pc r - >r.e:-:t; c_ptr = o_ot r->c'nan_l i s t ; I } /* i n t e r n a l input s i g n a l pending */ /* spontaneous t r a n s i t i o n s are handled below */ /* TS_user_process "/ mask • iisermask; timeout.tv_sec = 0; timeout.tv_usec = 501; i f ( s e l e c t ( 1 6 , Smask, 0, 0, itimeout) < 0) I p e r r o r ("UNIX domain : s e l e c t " ) ; e x i t ( 2 ) ; ! for ( i = 1; (mask > 0) SS ( i <= MAX_TSAP_ID) ; i + + ) ( i f ((usock(i) != -1) Si (mask S (1 << u s o c k ( i ) ) ) ) /* Incoming request */ ( j = i - 1; i f ((n = TD_input(usock|i|, userpoc1|j].datum, TS_MAX_LENGTiU2) ) >= s i zeof (st ruct data__hcr)) ( u s e r p o c 1 ( j I . f i 1 1 = TRUE; userpooi!j] . I en - n; I e l s e I e r r c l o s e l j l = TRUE; ) p_block = uprocess[jJ; ( • (p_block->proc_ptr) ) (NULL, NULL); I /* RS_process */ mask = net mask .-:. imoout . c'-_ sec •- 0 ; imcout . c v_usec = SO I; it (select: (16, (.mask, 0, 0, Stimoout) < 01 I p e r t o r C ' l N E T domain : s e l e c t : " ) ; e x i t (?) ; I iC ((mask > 0) i i (nc_inuse < MAX_NCEP_ ID) ) /» network channel Jvni.ljbl I i f (mask & (1 << conn(0)->socket)) I for (notdone = TRUE, i MAX_NCEP_ID; notdone i s d > 0); i--) I i f (conn ( i j == MULL) I notdone = FALSE; j = i - 1 ; i f (N a c c e p t ( i c o n n ( i ] , conn(0]->socket) == NET_OK> 1 n e t _ s t a t u s I j ) = NET_NEWCOMER; nc_inuse++; netmask 1= (1 << ( c o n n [ i j - > s o c k e t ) ) : o_biock = r p r o c e s s ( j 1 ; ( • (p _bioc>- > ?roc_?t r) ) (NULL, NULL) ; j /•> i f acceptance is OK - / for ( i = i ; i <= MAX_.NCI?_ ID; i r + > ( j = i - 1 ; i f ( (conn[ i) != NULL) ii / * the network channel i s mus (mask & (1 << conn[ i ] ->socket ) ) ) /* Incoming request */ ( i f ((n = N _ r e c e i v e ( c o n n ( i ] , ne tpoo l f j ] .da tum, NET_DATA_SIZE)) >= NET_OK) ( n e t p o o l [ j ] . f i l l = TRUE; n e t p o o l [ j ] . l e n = n; I e l s e I net reason( j) = n ; 1 p_block = r p r o c e s s I i ! ; ( * (p bl.ock->prOC ptr) ) {NULL, NULL) ; i f ( (net reason( j ) != .\'ET_OK) II (net_status( j1 == NET_CONFIP.M)) ( p_block = r p r o c e s s ( j ) ; ( " (p_block->proc_ot r) ) (NULL, NULL) ; ) ) /* for i - l o o p */ /« ATP process */ i f (st rcmp (p_pt r2->p_ident, " ATP_process " ) == 0) I p_block = p_ptr2; (* (p_ptr2->proc or. r ) l (NULL, NULL) ; I p_ptr2 = p_ptr2->next; /* System_process */ for ( i = 0 ; i < NTIMER; i + + ) I t o r ( t p t c l = t i m e d i s t • i ! / t p c r l ! • r.VU.: t p t r ! = t p c c l - > n e s c ) f o r ( r . p t r 2 » cpc r 1; - p t r t ! - N(<!.:.; I ? t v 2 = t o t r2->ne>:t) I ( t ;> t r2- : - t •>•-• 01 •' • t •• . ' : • •••! * ' p b l o c k s p i a o e s s f : ' : ( " r ( p _ b l o c k - : - p r o i : p t : . ! ) (Mi ; : . ; . , N U M . ) ; • / * t Lino oi;r. * / I / A e a c h t Line r * / ) / * e,i<: h t i m e r 1. i : : . t • / I / " e a c h s y s t e m p r o c e s s * / / ' f o r e v e r l o o p * / Appendix D System Initialization and Scheduler — For Manual Implementation 72 T S _ i n i t s y s ( p r i v i t e ) TS s c h e d u l e ( o r i v a t e ) ? i n c i u d e •rsys / t y p e s . h> ? I n c l u d e < s y s / s o c k e t . h > S i n c l u d e < s y s / u i o . h > l i n c i ' - i d e < s y s / t i m e . h > if i n c l u d e < s y s / u n . h > S i n c l u d e < n e t i n c t / i n . h > s i n c l u d e < e r r n o . h > S i n c l u d e < s i g n a l . h > • i n c l u d e < s t d i o . h > ( ( i n c l u d e " . . / i n e t / i n e t . h " S i n c l u d e " t p d e f s . h " S i n c l u d e " t p . h " S i n c l u d e " . . / t s p / t s p . h " " i n c l u d e " t p v a r . h " / * * T S _ i n i t s y s ' T r a n s p o c t S t a t i o n i n i t i a l i z a t i o n ( GLOBAL ) * 1. H a n d l i n g t h e S I G I N T 5 S1GCHLD s i g n a l s 2 . I n i t i a l i z e T S , TP a n d NP q u e u e s . * 3 . O p e n TS l i s t e n e r . " 4 . O p e n NP l i s t e n e r . ' / r s ^ i n 11 s y s () s t r u c t i. t i m e r v a l t i m e : i n t n ; t i m e . i t _ i n t e r v a l . t v _ s e c = c i m e . i c _ v a i u e . c v _ s e c = 11; t i m e . i t _ i n c e r v a l . t v _ u s e c = t i m e . i t _ v a l u e . t v _ u s e c = 0 1 ; s e t i t ime r ( I T I M E R V I R T U A L , i t i m e , ( s t r u c t i t i m e r v a l * ) 0 ) ; s i g n a l ( S I G V T A L R M , T M _ c l o c k ) .-/* * O p e n a NSNAME s e r v e r l i s t e n i n g t o t h e NP p r o v i d e r s . * / i f ( ( n = N _ o p e n ( S ( n o l i s t . n c o n n ) , NSNAME)) != NET_OK) ( f p r i n t f ( s t d e r r , " > > > N _ o p e n p r o b l e m S d \ n " , n ) ; e x i t ( 1) ; ) / * * O p e n a TSNAME s e r v e r l i s t e n i n g co t h e TS u s e r s . « / i f ( ( t s 1 i s t . t s a p = T S _ o p e n ( T S N A M E ) ) < 0) I f p r i n t f ( s t d e r r , " > > > T S _ o p e n p r o b l e m ^ d \ n " , t s 1 i s t . t s a p ) e x i t (1) ; I / « I n i t i a l i z e t h e g l o b a l Q u e u e s . * / t s l i s t . p r e v = t s 1 i s t . n e x t = i t s l i s t t p l i s t . p r e v = t p l i s t . n e x t = k t p l i s t n p l i s t . p r e v = n p l i s t . n e x t = S n p l i s t T S _ s c h e d u l e ( p r i v a t e ) T h i s i s t h e s c h e d u l e r o f t h e i n t e r a c t i o n s ; s c h e d u l e ! ) t s t r u t : ! : t i m e v a I t i m e ; s t r u c t s o c k a d d r _ u n f r o m ; i n t n , f i e r i , ma s k, s o c k ; c h a r d a t u m [ T S _ M A X _ L E N G T H + 2 ) , n d a t u m ( N E T _ O A T A _ S IZE ] ; TSCONN t s p , t s p n e x t ; TPCONN t p , t p n e / . t ; NPCONN n p , n p n e x t ; N D A T A _ P T R n p t r ; NCONN a c o n n ; f o r ( ; ; ) ! / • T r a n s p o r t s e r v i c e u s e r s * / mask = T S _ b u i l d m a s k ( ) ; t irne . t v__sec = 0 ; t i m e . t v _ u s e c = 5 0 0 1 ; i f ( (n = s e l e c t (16, i m a s k , 0, 0, i t i m e l ) < 0) i f ( e r r n o != EINTR) T S _ e r r o r s h u t d o w . n ( ) ; i f (n > 0) i f (mask S (1 << ( t s I i s t . t s a p ) ) ) I f l e n = s i z e o f ( s t r u e t s o c k a d d r _ u r . ) ; i f ( ( s o c k = a c c e p t ( ( t s 1 i s t . t s a p ) , ( s t r u c t s o c k a d d r i ) 5 f r o £ f l e n ) ) < b) T S _ e r r o r s h u t d o w n ( ) ; e l s e I i f ( T S _ n e w u s e r ( s o c k ) == NULL) ( s h u t d o w n ( s o c k , 2); c l o s e ( s o c k ) ; ) I 1 / * new TS u s e r * / f o r ( t s p = t s l i s t . n e x t ; t s p != S t s l i s t ; t s p = t s p n e x t ) I t s p n e x t = t s p - > n e x t ; i f (mask £ (1 << t s o - > t s a p ) > I i f ( ( n = T D _ i n p u t ( t s p - > t s a p , d a t u m , T S _ M A X _ L E N G T H + 2 ) ) < s I z e o f ( s t r u c t d a t a _ h d r ) ) T S _ d i s c o n n e c t ( t s p , UNKNOWN_ERROR); e l s e ( v o i d ) T S _ i n p u t ( t s p , d a t u m , n ) ; ) I / * f o r t s l i s t • / ) / * n > 0 * / / * S e n d . . t h e f i l l e d n e t w o r k o u t g o i n g b u f f e r s V f o r (np = n p l i s t . n e x t ; np != i n p l i s t ; no = n p n e x t ) I n p n e x t = n p - > n e x t ; i f ( n p - > s b u f != NULL) ( n p t r = n p - > s b u f - > d a t a ; i f ( N _ s e n d ( n p - > n c o n n , n p t r - > d a t u m , n p t r - > d l e n ) != NET_OK) N P _ c l o s e ( n p ) ; e l s e NP r e l e a s e (S ( n p - > s b u f ) , F A L S E ) ; I I / * n e t w o r k p r o v i d e r * / mask - N P _ b u . i Idmask () ; i. i me . t; v_.se c -= 0 ; t ime . t v _ u s c c = S001 ; i E ( ( n = s e l e c t ( 1 6 , Smask, 0, 0, S t i m e ) ) < 0) i f ( e r r n o != EINTR) T S _ c r r o r s h u t d o w n ( ) ; i £ (n > 0) I i £ (mask S (1 << (np 1 i s t . n c o n n - > s o c k e t ) ) ) I i £ ( N _ a c c e p t ( S n c o n n , n p l i s t . n c o n n - X s o c k o t ) ! " N F . T O K I T S _ e r r o r s h u t d o w n ( ) ; e l s e I i £ ( N P _ a c c e p t (nconn) != NET_OK) N _ c l o s e ( n c o n n ) ; I I / ' new TS u s e r * / f o r (np = n p l i s t . n e x t ; np != S n p l i s t ; np - n p n e x t ) ( n p n e x t = n p - > n e x t ; i f (mask 6 (1 << n p - > n c o n n - > s o c k e t ) ) I i f ( (n = N _ r e c e i v e ( n p - > n c o n n , ndatum, NET DATA S I Z E ) ) < NET_OK) N P _ c l o s e ( n p ) ; e l s e N? i n o u t (np, ndatum, n) ; I ) / • f o r n p l i s t -I I I- n > 0 V / * t i m e r s * / f o r ( t p = t p l i s t . n e x t ; t p != S t p l i s t ; t p = t p n e x t ) f t p n e x t = t p - > n e x t ; i f ( ( t p - > t i m p != NULL) s& ( t p - > t i m p - > t i m e == 0)) T P _ e x p i r e d ( t p ) ; ) f o r (np = n p l i s t . n e x t ; n p != S n p l i s t ; np = n p n e x t ) ( n p n e x t = n p - > n e x t ; i f ( ' (np->t imp != NULL) SS (np->t imp->t ime == 0)) N P _ e x p i r e d (np) ; I ( / * f o r e v e r l o o p * / 

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
https://iiif.library.ubc.ca/presentation/dsp.831.1-0051901/manifest

Comment

Related Items