UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

An experiment in high level protocol design Scotton, Geoffrey Richard 1981

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

Notice for Google Chrome users:
If you are having trouble viewing or searching the PDF with Google Chrome, please download it here instead.

Item Metadata

Download

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

Full Text

AN EXPERIMENT IN HIGH LEVEL PROTOCOL DESIGN by GEOFFREY RICHARD SCOTTON B.A.Sc, Royal Melbourne Institute of Technology, 1978 A THESIS SUBMITTED IN PARTIAL FULFILMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE in THE FACULTY OF GRADUATE STUDIES Department of Computer Science We accept t h i s thesis as conforming to the required standard THE UNIVERSITY OF BRITISH COLUMBIA December 1981 (c) Geoffrey Richard Scotton, 1981 In presenting t h i s thesis i n p a r t i a l f u l f i l m e n t of the requirements for an advanced degree at the University of B r i t i s h Columbia, I agree that the Library s h a l l make i t f r e e l y a v a i l a b l e for reference and study. I further agree that permission for extensive copying of t h i s thesis for scholarly purposes may be granted by the head of my department or by his or her representatives. It i s understood that copying or pu b l i c a t i o n of t h i s thesis for f i n a n c i a l gain s h a l l not be allowed without my written permission. Department of <j*!otvvpvo(-<2-r' Qc-ies\<2e-~ The University of B r i t i s h Columbia 2075 Wesbrook Place Vancouver, Canada V6T 1W5 Date \Uy/1-2-/Sri* • Abstract. High l e v e l communication system design is of increasing interest as the interconnection of computer systems becomes more widespread. High l e v e l communication , systems provide users/applications with a convenient v i r t u a l communication environment that i s an abstraction of the underlying transport communication mechanism. Examples include high l e v e l protocol support for f i l e transfer, v i r t u a l terminal and mail delivery applications. We describe the implementation of communication software support for the ITI v i r t u a l terminal protocol using an existing X.25 protocol implementation. The design and implementation of a high l e v e l communication system using an experimental research computer system is described within t h i s thesis. We also present a design that is a generalization of the model implemented and compare th i s with other communication models, notably the ISO Open Systems Interconnection model and the Xerox Pup internetwork architecture. In pa r t i c u l a r we address the following issues: (a) Dynamic protocol layer i n i t i a t i o n from an incoming c a l l . (b) U t i l i z a t i o n of a uniform interface between protocol layers and at the user interface. Within the implementation described this is achieved using a interprocess message based I/O protocol. (c) The suspension of higher layers and application processes after a transport l e v e l f a i l u r e and the subsequent i i reconnection when the transport connection is reestablished. The design u t i l i z e s layered communication modules that provide external (high level) protocol support or al t e r n a t i v e l y may provide l o c a l services and functions such as l o c a l data transformation and reconnection functions. The u t i l i z a t i o n of a uniform interface between modules and at.the user interface allows the l i b e r a l interconnection of modules to provide the required communication services with a minimum of overhead. Table of Contents. Abstract i i Table of contents.. iv L i s t of figures v i i Acknowledgements. v i i i 1 Introduction.. 1 1.1 Objectives. . . . . . 2 1 .2 Motivation 5 2 High Level Protocols - an Overview 7 2.1 • Higher Level Protocols. 7 2.1.1 Topology Independence 8 2.1.2 Device Independence 11 2.1.3 Data Representation Independence 12 2.2 The Open System Interconnection Architecture. . 14 2.2.1 ISO Protocol Standards A c t i v i t i e s 14 2.2.2 Layered Protocol Design 18 2.2.3 The OSI Layer Architecture 18 2.3 OSI Architecture Constraints 22 2.3.1 Layering Constraints 22 iv 2.3.2 OSI Model Constraints 23 2.4 The Pup Internetwork Architecture. 25 3 A Verex Communication Model Implementation . 29 3.1 The Server Model 29 3.1.1 The Verex System Servers 29 3.1.2 The Uniform Server I/O Interface 31 3.1.3 Static and Dynamic Servers 36 3.1.4 R e l i a b i l i t y and Dependency 37 3.2 The Communication Model Implementation 39 3.2.1 The ITI Server. 40 3.2.2 The Session Server 46 3.2.3 The Network Server 48 3.3 Error Recovery 51 3.3.1 Session Recovery 51 3.3.2 Garbage Collection and Resource Reclamation. 53 4 A Dyamic Communication System Design 56 4.1 A Modular System Structure 56 4 . 1 . 1 Protocol Management and F i l t e r Modules. . . 57 4.2 Transformation Level Functionality 60 v 4.2.1 A Uniform Communication Module Interface. . 60 4.2.2 Data Transformation and Transparency. . . . 63 4.2.3 Error Recovery and Session Management.. . . 64 4.2.4 Blocking and Segmentation 67 4.3 Transformation Level Components.. . 69 4.3.1 Data Transformation Modules 70 4.3.2 Incoming C a l l Handler 72 4.3.3 The Session Manager 74 4.4 Comparison with OSI and Pup Architectures.. . . 76 5 Conclusion. 81 5.1 Conclusions 82 5.2 Future Research Areas 84 Bibliography. . 86 Appendix.A. Session Reconnection.Sequence. 90 v i L i s t of Figures. 1 Protocol/interface communication.. . 17 2 OSI layer architecture.. . . 21 3 The Pup Protocol Hierarchy. [Boggs et a l 1980] . . . . 26 4 Service requests and server invocation 39 5 The ITI server design 42 6 X.25 c a l l frame and resulting session server requests. 50 7 Functional levels and sub-level layers 56 8 Terminal support communication modules 60 9 Multiple transport/application sessions. . . . . . . . . 65 10 C a l l establishment phase. 70 11 Alternate communication system configurations 72 12 Session reconnection sequence 93 v i i Acknowledgements. I would l i k e to sincerely thank my supervisor David Cheriton, who was able to direct my work on thi s thesis when I needed i t most. I greatly appreciate Steve Deering for the discussions that gave ri s e to many parts of thi s thesis, for proof reading the f i n a l draft and the use of his software. Thanks to David Cheriton, Pat Boyle, John Demco and Steve Deering for having the time to answer my questions. I would also l i k e to thank Debbie Kinzel and everyone from the o f f i c e , David Booth, Kathy Lee, Marc Majka and Wendy Moore for their encouragement. Special thanks to Gerry Neufeld for reading and commenting on the f i n a l d r a f t . v i i i 1 Chapter 1. Introduction. This thesis i s concerned with the design and implementation of a communication system framework for supporting high level protocol communication. High l e v e l protocols enhance the data transport services provided by lower level protocols, adding greater f u n c t i o n a l i t y to the communication services. The communication system structure described within t h i s thesis provides a f l e x i b l e host environment for the implementation and use of high l e v e l protocols. Chapter 2 of t h i s thesis reviews the development of high l e v e l protocols and describes some higher l e v e l protocol oriented communication architectures. In p a r t i c u l a r the OSI [ISO 1981] and Pup communication architectures [Boggs et a l 1980] are reviewed and form the basis for a comparison within chapter 4. Chapter 3 describes the implementation of a communication system model within the Verex- research computer system. The-communication model provides a system structure that i n i t i a l i z e s and links high l e v e l protocol layers at the time an external request to establish a connection is received. Connectionless protocols are not currently supported within the implementation. The implementation u t i l i z e s a uniform interface between layer e n t i t i e s (modules) to allow a f l e x i b l e interconnection of system components. The ITI v i r t u a l terminal protocol is implemented u t i l i z i n g an existing X.25 protocol implementation as the transport l e v e l . We include within a l l lower l e v e l protocols (transport level) those protocols concerned only with moving 2 data between, endpoints. In terms of the OSI reference model (see section 2.2) this- represents the transport protocol and a l l lower protocol layers. Chapter 4 generalizes the implementation model of chapter 3 and presents a more general communication system design. The design defines the high l e v e l communication support in terms of the f u n c t i o n a l i t y of the component modules. Protocol management modules and f i l t e r modules are defined. A uniform module interface provides a uniform access method for both the intermodule interface and the application interface. A comparison of this design with the OSI and Pup models i s made in the f i n a l section of chapter 4. Chapter .5 reviews the communication system implementation and design and proposes future areas of research. 1.1 Object ives. The objective of t h i s work was to provide a remote access and intersystem communication f a c i l i t y within the Verex operating system. The implementation u t i l i z e s a f l e x i b l e system model that allows the structure of the communication system to be configured dynamically by invoking, i n i t i a l i z i n g and link i n g communication modules at the time a connection request is rece ived. The issues that are of concern within this model are: 3 (a) The determination of incoming c a l l requirements and. the dynamic configuration of the communication service support modules. (b) The provision of a uniform module interface using the l o c a l I/O protocol that u t i l i z e s interprocess messages for I/O requests. (c) Error recovery functions that allow high level applications to be suspended when the transport system f a i l s and then reactivated when the transport connection i s reestablished. The thesis i s not concerned with the development of new high l e v e l protocols, but in providing an environment in which existing (and future) protocols can be supported. The modularity of the communication design favours protocols with a minimum of f u n c t i o n a l i t y , so that these can be s e l e c t i v e l y applied in an additive manner to provide the complete communication requirements. However no r e s t r i c t i o n s are assumed upon the complexity of the protocols within the model. The communication system model i s characterized by the following a t t r i b u t e s . (a) Protocol layer independence. (b) Variable number of protocol layers. (c) Uniform layer interface. (d) U t i l i z a t i o n of dynamic e n t i t i e s . (e) External state dependent protocol management modules. (f) Internal state dependent f i l t e r modules. 4 The layer independence and the uniform layer interface attributes permit the stacking of communication modules in an (almost) a r b i t r a r y manner. The uniform I/O interface can be used to provide applications with a l o c a l perspective for non-local I/O operations. Only those applications or protocol layers that must s p e c i f i c a l l y u t i l i z e communication dependent f a c i l i t i e s need be aware of the difference between the l o c a l and remote I/O services. The uniform I/O interface used within the Verex implementation provides I/O operations using interprocess messages. The objective of the dynamic structure i s to allow the system to respond to demand and reduce the overhead of i d l e communication modules. Static communication modules consume some (possibly minimal) system resources and tend to c l u t t e r the system with idle processes. Dynamic invocation reduces the amount of idle process overhead. Additional benefits may be gained i f the communication system structure is not predetermined, but is configured on demand based upon the. communication requirements of an incoming c a l l . As within the Pup internetwork architecture there may exist many interchangeable components corresponding to each layer of the communication structure. The configuration of protocol components is determined by the c a l l i n g system, based upon the application requirements, the system resources and the application performance requirements. The f l e x i b i l i t y of the communication structure allows standard protocols to be supported in addition to l o c a l l y defined, non-standard 5 protocols. . 1.2 Motivation. The primary motivation for developing the communication structure was to provide a simple communication environment that is e a s i l y adaptable for a variety of applications. The Verex research system provided a v e r s a t i l e environment for exploring alternative communication system designs and their integration within the operating system. As within the Pup.architecture, si m p l i c i t y i s viewed as a desirable aim in i t s e l f and a necessary path towards f l e x i b i l i t y . The complexity of implementing the multilayered communication design such as the OSI architecture i s an imposing task. The OSI reference model [ISO 1981] i s indicative of the trend towards highly layered communication systems. The reference model represents a design framework (model) within which the communication system implementation i s made. With the s p e c i f i c a t i o n of high l e v e l protocols (at the session layer and above) the model w i l l achieve greater physical r e a l i z a t i o n . Within the OSI model the .user interface is defined at the topmost layer only and thus by d e f i n i t i o n does not allow user or user defined protocol access to lower layers where t h i s is desirable. A generalized communication system based upon a s t a t i c design is subject to c o n f l i c t i n g constraints that affect i t s performance and v e r s a t i l i t y . F i r s t l y a model with i n s u f f i c i e n t 6 generality may exclude applications requiring s p e c i f i c performance requirements. Secondly the provision of s u f f i c i e n t generality within a s t a t i c model implies increased complexity at each l e v e l and some degree of performance tradeoff. A l t e r n a t i v e l y , a dynamically structured communication system may avoid these problems by providing only those services and service modules that are required to f u l f i l l the communication requirements of the applicat i o n . In summary, the motivation for the development of a dynamically structured communication system was to: (a) Reduce the complexity of the communication system as a whole. (b) Increase f l e x i b i l i t y by greater use of modularity. (c) Decrease overhead bu u t i l i z i n g dynamic structuring. 7 Chapter 2. High Level Protocols - an Overview. 2.1 Higher Level Protocols. A communication system incorporating both high and low le v e l protocols provides the communication services necessary for a l l levels of intersystem interaction. We define a high l e v e l protocol as a protocol that provides more than a means of transparently exchanging b i t s or bytes between remote location. A high l e v e l protocol provides higher order (application dependent) services. A high l e v e l protocol provides topology, device and data representation independence to the application, whilst low level protocols provide a user independent transport mechanism. The communication system must provide a means to establish, maintain and terminate a conversation with a remote entity. These services are provided in a form convenient to the appl i c a t i o n . The communication mechanism may be connection based or connectionless at lower l e v e l s . (Possibly providing v i r t u a l connections at higher levels.) By abstracting the communication mechanism and providing an environment that i s t a i l o r e d to the application, the high l e v e l protocol provides a manageable and v e r s a t i l e tool for dis t r i b u t e d system design and implementation. The high level protocol provides the user with a communication environment suitable for the given application. This implies that at least some part of the communication system w i l l be application dependent. The application dependent part of 8 a high l e v e l communication system provides data transformation services, whilst other high l e v e l protocols may provide general services required by many applications. The application dependent nature of high l e v e l protocols is apparent in applications such as a di s t r i b u t e d f i l e system. Such an application requires not only a f i l e transport mechanism, but also a f a c i l i t y for managing f i l e s on the remote system. Operations upon a f i l e , such as f i l e creation, renaming, querying and release do not require transmission of the f i l e but are basic operations upon a remote f i l e system. These operations are provided within the high l e v e l protocol in addition to a f i l e transport mechanism. In the following sections we describe the means by which the communication- system u t i l i z e s high l e v e l protocols to provide topological, device and data representation abstract ions. 2 . 1 . 1 Topology Independence. Many dis t r i b u t e d applications, such as a di s t r i b u t e d f i l e system that u t i l i z e s a v i r t u a l f i l e protocol, are based upon dist r i b u t e d resources whose physical locations are not known by the appli c a t i o n . Within such a dis t r i b u t e d application, l o g i c a l i d e n t i f i e r s may be used to identif y resources within the distr i b u t e d system. The communication system may provide the mapping function necessary to map a l o c a l l y known l o g i c a l i d e n t i f i e r into a l o c a l or remote physical address. The physical address may include addressing components for the network, 9 system, port and resource i d e n t i f i e r or may be represented by a non-hierarchical address. Shoch [Shoch 1978] defines a name as ident i f y i n g a pa r t i c u l a r entity, the address of which i d e n t i f i e s where i t is located and whose route is the means of getting to i t . Of these, both names and addresses are of concern to higher level protocols. Routing is a function of lower (transport) level protocols. Hierarchical and non-hierarchical ( f l a t ) address spaces can be used to represent the address domain. Hierarchical addresses are useful in routing as they contain topographical and geographical information within the address. A f l a t address space does not provide any topological information but represents a more.flexible address base. Name and address pairs must at some time be bound so as to f i x (at least temporarily) the relationship between them. A binding agent [Abraham and Dalai 1980], i s able to map the resource name to i t s address. Binding- agents1 may be centralized or d i s t r i b u t e d . The Xerox Pup internet [Boggs et a l 1980] u t i l i z e name servers located throughout the internet to perform the name to address mapping. The Pup service addresses are i d e n t i f i e d by socket numbers that represent generic, service points. The binding of names ' and addresses may be performed at various times over the network operation. (a) Static binding. 10 Static binding is performed at system generation and is fixed u n t i l the system is regenerated. In a dynamic environment this would soon result in out-of-date address mapping functions. (b) Early binding. Static binding is performed when the system is i n i t i a l i z e d and remains fixed from that point onward. (c) Late binding. Late binding at runtime provides up-to-date address mapping but may require s i g n i f i c a n t overhead to be maintained. By combining early binding with late binding when an address is found to be incorrect, dynamic f l e x i b i l i t y i s provided with manageable overhead [Abraham and Dalai 1980]. Whichever addressing mechanism is used within a dynamic environment, the addressed resource is not always to be found at that location. This may be due to relocation, f a i l u r e or other reasons. Al t e r n a t i v e l y the address- may- have been- reallocated' to a new resource. In both cases the inclusion of the resource name within the connection request would be helpful in detecting and correcting these situations. Shoch [Shoch 1980] maintains that the address be used as a hint in locating the resource, but that alternatives should be provided i f the resource cannot be located. The independence of the application from the physical topology of distributed systems resources greatly f a c i l i t a t e s the design, implementation and p o r t a b i l i t y of distributed 11 applications. 2.1.2 Device Independence. A high l e v e l communication system should provide the user with device independent communication so that device c h a r a c t e r i s t i c s are not apparent at the user l e v e l . Two methods of device abstraction are performed by high l e v e l protocols. The f i r s t of these requires the implementation of a ' v i r t u a l device by both l o c a l and remote communication participants. (The v i r t u a l device abstraction is provided by the high l e v e l protocol, not the application.) The second means of device abstraction involves a parametric approach to device management. Both means of device abstraction as -applied to terminal communication are described below. The v i r t u a l terminal protocol (VTP) establishes a data structure that i t views as representing the terminal. This data structure i s recognized by both the l o c a l and remote protocol e n t i t i e s . The l o c a l system application may work d i r e c t l y with the ' v i r t u a l ' terminal data structure or may u t i l i z e a l o c a l terminal data structure that i s some transformation of that provided by the VTP. Simi l a r l y the VTP/terminal interface requires a v i r t u a l to physical terminal translation that u t i l i z e s the physical c h a r a c t e r i s t i c s of the terminal. From the viewpoint of the application and the terminal, the VTP provides a standard device d e f i n i t i o n . It i s a function l o c a l to both the terminal and the l o c a l system to transform the v i r t u a l terminal to the l o c a l representation. So long as the application i s able 1 2 to manipulate the v i r t u a l device provided by . the high l e v e l protocol, a much wider variety of- devices, with markedly d i f f e r i n g c h a r a c t e r i s t i c s may be used. Neither the application nor the remote device need be e x p l i c i t l y aware of any of the transformations required as these are provided by the VTP data transformation functions. A second approach to providing device independence within high l e v e l protocols is to provide a parametric interface to the protocol manager, whereby the entity n o t i f i e s the protocol manager of i t s own physical c h a r a c t e r i s t i c s . The protocol may use t h i s information to transform exchanged data to the required form. This approach is used within CCITTs recommendation X.28 and X.29 terminal interface and the Interactive Terminal Interface (ITI) [Datapac 1978].. A parametric protocol handler may take advantage of known c h a r a c t e r i s t i c s of a device to improve the service or performance that i t provides. A disadvantage of the parametric approach i s that the number of parameters t y p i c a l l y w i l l grow, causing greater variety and complexity within the protocol. 2.1.3 Data Representation Independence. Non-homogeniety amongst communication participants w i l l result in data representation differences at the hardware and software l e v e l s . The l o c a l system data representation is made transparent to a remote entity in much the same manner that v i r t u a l device abstraction is provided. Heafner and Wood [Heafner and Wood 1980] have i d e n t i f i e d three levels of 1 3 d i f f i c u l t y in data transformation, these are : (a) The transformation of data containing unstructured single, data types. This includes character, numeric, boolean or other simple data types. (b) The transformation' of data containing structured, pointer free data. Data structures such as records and arrays are included within t h i s category. (c) The transformation of data containing structured types that do include pointers. Data structures such as l i s t s and trees include pointers that may have d i f f e r i n g language and implementation representations. Ideally data transformations should be isomorphic. Isomorphic transformations allow an inverse transformation to be applied to the transformed data that would return the data to i t s o r i g i n a l form. Ty p i c a l l y t h i s is not possible, as many transformations have no unique inverse transformation. As long as the data semantics remain unchanged by the transformation, i t is not necessary that the data transformation be completely isomorphic. The data transformation may i t s e l f introduce errors. Range errors may occur for numeric data where d i f f e r e n t wordsizes are used. Type incompatibility and format conversion (from one base to another) are other sources of error. 14 2.2 The Open System Interconnection Architecture. 2.2.1 ISO Protocol Standards A c t i v i t i e s . In 1976 the International Standards Organization (ISO) established a new subcommittee (ISO/TC97/SC16) for the purpose of developing communication protocol standards [Bachman 1978], [ H o l l i s 1980], [Schindler 1981]. Their most s i g n i f i c a n t result to date has been the development of a reference model [ISO 1981] for what has been c a l l e d the 'Open Systems Interconnection' (OSI) architecture. This ISO action was in anticipation of current and future problems apparent in interfacing the growing number of incompatible communication protocols. Standardization of high and low le v e l protocols was seen as a means of providing greater interaction between otherwise incompatible systems and networks. The extent of the OSI architecture encompasses a l l interactions between systems. Applications such as remote terminal support, f i l e transfer, remote job entry and electronic mail are applications for which standards are being considered. The model does not exclude the p o s s i b i l i t y of non-standard protocols being used between systems for reasons of convenience, e f f i c i e n c y or security. Non-standard networks that remain unstandardized may also offer member systems the f a c i l i t i e s of the OSI environment by providing a single (possibly more) OSI node, through which the OSI environment i s accessable. The ISO subcommittee ISO/TC97/SC16 is composed of 1 5 representing bodies from interested nations and has urged cooperation with other standards organizations in an attempt to establish a worldwide set of protocol standards. The American National Standards Institute (ANSI) i s currently working in p a r a l l e l with the ISO and has likewise created a new technical committee, ANSI/X3T5, to investigate the OSI proposal [desJardins and White 1980], The International Telegraph and Telephone Consultative Committee (CCITT) has shown interest in t h i s area but has as yet not formed any working group to study the matter. The CCITT has taken a supportive position and i s also proposing cooperation with the ISO [Steel 1980], CCITT's primary interest in protocol standards development to date has been in the area of lower l e v e l protocol standards where the c i r c u i t switching V series protocols and the packet switching X series protocol standards are in widespread use. Systems supporting the OSI architecture are said to be 'open' in the sense that they are ( e l e c t i v e l y ) available to cooperating systems. The 'systems' portion of the t i t l e has-changed from singular to p l u r a l in later ISO documents, indicating a revision of the i n i t i a l concept of an encompassing single 'system' to that of many cooperating systems. The 'interconnection' term does not necessarily imply that a l l OSI systems be physically connected, but that l o g i c a l connections can be established between OSI systems. The OSI model does not specify the means by which the data i s to be physically transported between systems. The ISO reference model [ISO 1981] defines the framework of 1 6 the OSI architecture but does not define the protocols themselves. The model i s s t i l l under review whilst additional f a c i l i t i e s such as datagram and broadcast communication support are considered. Burkhardt and Schindler [Burkhardt and Schindler 1981] present an alternative perspective on the OSI architecture by defining the architecture in terms of the interactions and interface points (cuts).that exist in the model. They discuss the p o s s i b i l i t y of u t i l i z i n g both s t a t i c and dynamic system e n t i t i e s to implement the model. The reference model does not d i f f e r e n t i a t e between the s t a t i c and dynamic system components as t h i s i s implementation dependent. The reference model has adopted a layered design incorporating seven independent layers each of which communicates with equivalent (remote) layers. Each layer supports a protocol that provides the means by which the remotely located layer e n t i t i e s interact and also provide v e r t i c a l functional support for higher layers. The reference model defines a protocol as horizontal communication between one (n) layer entity and another equivalent entity at the same l e v e l . The interaction between an (n) layer entity and a (n-1) layer entity is defined as an interface. These d e f i n i t i o n s are applied to the design and implementation described in chapters 3 and 4. The nature of the interface is not spec i f i e d by the reference model as this relationship is l o c a l l y defined. The interface/protocol interactions between layers are depicted below in Fig 1. layer (n) entity < PROTOCOL > INTERFACE V layer (n -1) entity < PROTOCOL > 1 7 layer (n) entity INTERFACE V layer (n-1) entity System A. System B, Figure 1 Protocol/interface communication. The attributes of an (n) layer protocol may be defined by the set of services that i t provides to the next higher layer. An (n) layer protocol i s dependent only on the services provided by lower layers. Any (n) layer protocol may be replaced without af f e c t i n g the other layers, as long as the equivalent functional support is provided to the higher layer. To allow (n) layer e n t i t i e s to communicate, two things are required: (a) Each n layer entity supports the same (or a working subset of the same) (n) layer protocol. (b) The (n - 1 ) layer entity provide the services necessary to allow the transportation of (n) layer data and control information. 18 2.2.2 Layered Protocol Design. A layered protocol design reduces the problem of managing a large complex protocol to the task of managing many smaller, simpler parts. The development and v e r i f i c a t i o n of each layer then becomes an easier task. Because of the independence of layered modules, system correctness can be shown inductively by showing each layer correct. The layered framework permits simple maintenance of an evolving communication system in which the functional requirements of a protocol may change over time. Within a layered architecture the proportion of the software that must be changed i s reduced when implementation or protocol s p e c i f i c a t i o n s are modified. The implementation of the protocol should r e f l e c t the structure of the protocol, so that protocol modifications of a single layer may be constrained to implementation alt e r a t i o n s within a single layer entity. A disadvantage of layered protocols is that duplication of functions may be necessary at higher levels when the services required by an (n) layer entity are inadequately provided by an (n-1) layer e n t i t y . . 2.2.3 The OSI Layer Architecture. The reference model defines seven layers within the OSI architecture. The services provided by each of the seven layers is b r i e f l y summarized below. More detailed descriptions of the 19 f u n c t i o n a l i t y of each layer can be found within the reference model i t s e l f [ISO 1981]. .-(1) Application Layer. The application layer provides the end user (application) with the access point to the OSI environment. It i s at this l e v e l that a l l user services are provided (although some may not be implemented at t h i s l a y e r ) . Some node management tasks also reside at thi s l e v e l . (2) Presentation Layer. . The presentation layer i s responsible for transforming standard format data to or from a l o c a l format that is used by the application. The transformation should leave the data semantically equivalent. Data transformations may be required for text, numeric data,, command, data structures or any other' form, of data that the application requires. (3) Session Layer. The session layer i s responsible for binding two presentation layers for the duration of a session. Additional services may provide- application dependent data* i n t e g r i t y and security. Sessional address mapping between l o g i c a l and physical addresses is provided by the session layer so that resources are made available independent of their physical location (topologically independent). (4) Transport Layer. The transport layer provides an error free end-to-end communication channel. Data delivery and flow control of messages is assured despite an underlying error-prone communication mechanism. End-to-end acknowledge ensures the f i n a l delivery of data at the remote endpoint. 20 (5) Network Layer . The network layer manages network dependent addressing, routing and flow control. Also i t provides a v i r t u a l c i r c u i t between two endpoints over a supplied connection. Some error detection and correction may be provided. (6) Data Link Layer. The data link layer provides a basic means of establishing a connection between endpoints and exchanging data over t h i s connection. Some error detection and correction i s performed by t h i s layer. (7) Physical Layer. The physical layer performs the physical data transfer across the medium. The e l e c t r i c a l , interface i s defined within t h i s layer. The protocol layers are designed so that each provides services to the layer above. Each peer layer u t i l i z e s these services and enhances them by adding i t s own services. The seven protocol layers are i l l u s t r a t e d below- in Fi;g* 2. 21 Application Presentat ion Transport layer Application layer Presentat ion layer . Session layer Transport layer Network layer Link layer Physical layer < > Network layer Link layer Physical layer < > < > Session layer Network layer Physical layer < > Link layer System A. Intermediate node. System B. Figure 2 OS:I layer a<rohi feature. The OSI reference model sp e c i f i e s many services and functions that must be supplied by a communication system. The services provided within the OSI model include: (a) Connection establishment/release. (b) Data transfer. (c) Control data transfer. (d) Application dependent services. Functions performed by a given system entity are not the 22 result of any s p e c i f i c request, but are actions taken in the provision of requested services. The OSI model includes such functions as: (a (b (c (d (e (f (g (h ( i Data transformation. Error detection/correction, Mult iplexing. M u l t i l e v e l addressing. Parameter negotiation. Segmenting/blocking. Flow Control. Sequenc ing. Routing. 2.3 OSI Architecture Constraints. 2.3.1 Layering Constraints. The layered nature of the model adopted by the ISO for the OSI reference model has several constraining factors that affect the model design, implementation and performance. (a) Functional duplication. The services provided by a subordinate layer within the reference model may prove to be inadequate for a given s i t u a t i o n . The fu n c t i o n a l i t y must then be provided by the higher layer. An example of this is that flow control is generally only applied at the transport l e v e l , yet must be provided within the session layer l e v e l i f downward 23 multiplexing is provided by that layer. Similarly upward and downward multiplexing functions at the session layer require sequencing operations to be performed, despite sequencing provided by lower layers. (b) Increased overhead. Each successive layer adds more control information to the application data being exchanged, thereby increasing the control data overhead. One study of the ARPANET [Pouzin and Zimmermann 1978] showed that only 24 per cent of the transmitted b i t s were made up of user data. This figure excludes internal network t r a f f i c and represents the overhead due to headers, t r a i l e r s and acknowledgements. When performance i s of primary importance, a means of meeting the performance requirements is necessary. (c) Buffering requirements. Protocol layer e n t i t i e s can only be ensured to be truly independent i f no common data is shared. As a result of th i s , independent layer e n t i t i e s require multiple buffers and instances of the- same message. A- relaxation of the layer independence c r i t e r i a allows data to be shared. Data sharing is used in Squire [Chesley and Hunt 1981] to reduce buffering requirements and data movement. 2.3.2 OSI Model Constraints. The OSI model poses many problems for design and implementation. The layering constraints mentioned in the previous section apply to the model due to the multilayered nature of the model. Other problems inherent in the OSI model 24 are described here. (a) Model complexity. The OSI model is a large and complex communication system framework. It requires each layer to be implemented before the communication system may interact with other OSI systems. The models complexity is then not related to the complexity of the required communication task. The model represents a s i g n i f i c a n t fixed overhead for even r e l a t i v e l y simple communication requirements. Less sophisticated systems, (ie small systems without the necessary resources) may be excluded from the OSI environment because they are unable to support or implement the complete OSI model. (b) Model generality. The generality of the OSI model allows i t the f l e x i b i l i t y to meet the demands of a wide variety of applications. However s p e c i f i c applications require s p e c i f i c performance c r i t e r i a that are d i f f i c u l t to meet within a generalized system. Such applications may fi n d i t necessary to implement non-standard communication protocols and protocol frameworks i f the application requirements cannot be met within the OSI environment. (c) Ambiguous layer f u n c t i o n a l i t y . The OSI model defines seven layers within the model and attempts to define the boundaries between them by defining the services and functions that each performs. The f u n c t i o n a l boundary i s not always c l e a r , n o t a b l y in the case of the transformation/application layer interface. Moulton [Moulton 1980] defines the transformation l e v e l as being 25 concerned with data syntax whereas the application layer as being concerned with the data semantics. 2.4 The Pup Internetwork Architecture. The Pup (PARC Universal Packet) internetwork architecture developed at Xerox PARC [Boggs et a l 1980], provides an alternative layered protocol design for intra/internetwork communication. The Pup architecture i s designed on the basis of sim p l i c i t y and f l e x i b i l i t y of operation. Protocol s i m p l i c i t y is viewed a means of providing f l e x i b i l i t y for intersystem communication, whilst at the same time providing high performance by reducing the processing overhead. Network dependent encapsulation techniques are used to transport packets over d i s s i m i l a r networks. The encapsulation/decapsulation process is transparent to the user. The Pup design consists of four basic levels (0 to 3) as shown below in Fig- 3. Levels 0 and' 1 provide a Inter net work-transport mechanism. Levels 2 and 3 provide host to host 26 intersystem communication protocols Level 3 Document printing Telnet Woodstock Data, structure and process interact ion conventions. Level 2, EFTP RTP BSP WFS Interprocess communication primitives. Internetworking Datagram (Pup) Levels 1. Internetwork packet format. Ethernet Arpanet leased 1 ines Packet radio Level 0. Packet transport mechanism. Figure 3 The Pup Protocol Hierarchy. [Boggs et a l 1980] The higher l e v e l protocols that make up levels 2 and 3 support both connection-based and connectionless protocols. Connection-based protocols provide greater r e l i a b i l i t y and performance for high volume data transport applications. Connectionless protocols are used to support query/transaction oriented applications. 27 The l e v e l 2 communication primitives provide alternative intersystem data transfer techniques. The choice of level 2 protocol may be made based upon the application, host resources and performance c r i t e r i a . An example of alternate intersystem communication protocols i s provided by a f i l e transfer application that uses the EFTP (Easy F i l e Transfer Protocol) under some conditions and the BSP (Byte Stream Protocol) at other times. The EFTP provides very basic f i l e transfer operations that may be used as a bootstrap and down-line-load for node i n i t i a l i z a t i o n whereas the BSP provides a faster more sophisticatd data transfer f a c i l i t y (with s i g n i f i c a n t additional resource demands). The RTP (Rendezvous and Termination Protocol) provides application support for addressing well known socket addresses and requesting a pa r t i c u l a r service. (The service i s represented by the socket address, but i s not necessarily provided by the addressed entity.) Once addressed, the entity may invoke a new server and return a unique connection'* i d e n t i f i e r that represents the new server. The RTP entity then provides the application with the means of interaction with the new server. Dynamic service support is provided by the RTP and each addressed socket server, allowing the communication requirements to be met upon demand rather than being established in a predetermined manner. A similar feature for dynamic protocol structuring is described in chapters 3 and 4 of t h i s thesis. Unlike the OSI model, the Pup networking model is designed to provide many dedicated protocol services at the 28 sub-application oriented l e v e l . The Pup l e v e l 2 provides end to end acknowledgment, similar to the OSI transport l e v e l , but also provides a variety of dedicated protocols at this l e v e l . The advantage of t a i l o r e d 'transport' service is that of increased performance. The disadvantage is that very many such protocols may r e s u l t . The Pup architecture allows great f l e x i b i l i t y for host to host interactions due to the simple and f l e x i b l e nature of the communication structure. The sophistication of the communication system can be adapted to suit the sophistication, resource and performance requirements of a given application.. Where high performance is required, protocol s i m p l i c i t y is of primary importance and the communication services can be allocated accordingly. 29 Chapter 3. A Verex Communication Model Implementation. 3.1 The Server Model. 3.1.1 The Verex System Servers. The Verex operating system [Lockhart 1981] has i t s basis in the Thoth operating system [Cheriton 1979]. Verex is a multiprocess operating system providing kernel support for message-based interprocess communication. Multiple address spaces are provided so than many processes can share a single address space to form a team. System services are provided upon request by system teams (servers) or a l t e r n a t i v e l y by kernel operations. System servers remain in an i d l e state u n t i l their services are requested by a user. The . communication system is implemented following t h i s server design within both the transformation and transport l e v e l s . Each layer within these levels may i t s e l f form a server for one or more users. The message passing primitives supported within Verex require processes to block awaiting message events. A process remains blocked following a message.SEND u n t i l the addressed process r e p l i e s to the sending process. Sim i l a r l y the receiving process can block awaiting a message from a p a r t i c u l a r process or may await a message from any process (selective and non-selective RECEIVE). The SEND, RECEIVE and REPLY message primitives, although not the only message primitives supported within Verex, form the basis for most of the interprocess communication. 30 The blocking nature of the message primitives within Verex gives r i s e to the server model of system service support. Other than the message, process and device management operations provided within the kernel, most system services are provided by system servers. System services are requested using interprocess message requests made d i r e c t l y to the appropriate system server. I/O services are requested of I/O servers using a uniform I/O protocol [Cheriton 1981 ] that does not d i f f e r e n t i a t e between device types. A team of processes use the same address space, thereby allowing data to be shared between processes but not across team boundaries. Data sharing between server processes within the same team increases the interdependence of these processes, but reduces' the overhead that would otherwise be incurred in moving and duplicating data. The three X.25 protocol layers of the X.25 server [Deering 1981] occupy the same team and reduce data movement between layers by allowing shared data access. Higher le v e l protocol servers do not allow data sharing as currently these ( i f more than one) are implemented as separate teams. A l l data must be moved into the team's address space before i t may be accessed. The server model provides a uniform means of access (see section 3.1.2) to the communication services using the message-based I/O protocol. Due to the nature of the message passing primitives provided by Verex, the requesting process remains blocked u n t i l the server r e p l i e s . This allows the server two courses of action in providing the requested service. These 31 are: (a) Reply to the requesting process only when the request has been f u l l y completed. (b) Reply immediately to the blocked process and queue the request so that the requested action may be performed at a later time. The former approach (a) allows the server s t r i c t control of the rate that service requests are accepted from individual processes. Read requests are generally replied to only when f u l l y s a t i s f i e d . The second approach (b) allows the requesting process greater latitude in operation, with the possible consequence of swamping the server i f service requests can be generated faster than they can be f u l f i l l e d . Write requests may be handled in such a manner. The choice of approach used in replying to service requests is dependent upon the nature of the application, the type of request, the queueing f a c i l i t i e s available and l o c a l system bounds (such as memory s i z e ) . 3.1.2 The Uniform Server I/O Interface. Within Verex processes request I/O operations using a message-based I/O protocol [Cheriton 1981]. This I/O model allows any process to perform the function of an I/O server by supporting the I/O protocol. User I/O requests are made by a message SEND to the I/O server with information containing the I/O request, and the f i l e i d e n t i f i e r . Buffering and data length information are included within the request message for read and 32 write operations. The uniform I/O protocol allows I/O services to be provided consistently by a l l . I/O servers. The user and I/O server interface i s well defined and independent of the f i l e type c h a r a c t e r i s t i c s . Communication I/O services are provided on the same basis as l o c a l I/O operations. A uniform interface between users and the communication system and between layers within the communication system f a c i l i t a t e s the interchangeability of the communication system components. The I/O requests used in the I/O protocol are: (a) Create instance. The create request creates a. new f i l e instance with the attributes given within the request. The f i l e instance represents the object implemented by the I/O server. The a p p l i c a b i l i t y of this request to an existing communication link ( f i l e instance) i s discussed below.. (b) Release instance. The release instance request releases resources committed to the f i l e instance and invalidates the instance i d e n t i f i e r . When there is concurrent use of a single f i l e instance, for example a communication connection, the instance is released when a release request is received from any user process. This is generally undesirable for applications such as remote terminal s u p p o r t where d i s c o n n e c t i o n , o t h e r t h a n b y e x p l i c i t user request, is not tolerated. The resolution of this problem, -as used within the communication model 33 implementation is discussed below. (c) Read instance. Read the specified amount of data from the f i l e instance and return i t to the requesting process. (d) Write instance. Write the specified data to the given f i l e instance. (e) Query instance. Return information concerning the given f i l e instance to the requesting process. (f) Set instance owner. Indicate to the server which process 'owns' the f i l e instance. (The absence of an owner process i s the basis upon which non-released communication links are cleared.) (g) Set break process. This request indicates that the specified process i s to be destroyed on the receipt of an interrupt or other exceptional event. D i f f i c u l t i e s arises in the concurrent use of a single communication connection. Unlike the f i l e system that may create a new f i l e instance on each create instance request, the communication system uses the same physical f i l e (the communication link) for each user. The problem of concurrent access manifests i t s e l f when any user application performs a release instance that releases the communication link for a l l other users. One solution is to perform s u f f i c i e n t permission checking on each user's release request. Finding permission conditions 34 that are s u f f i c i e n t l y f l e x i b l e i s not necessarily an easy task. Permitting processes belonging to the the owner user (and an authorised 'super user') eliminates interference from other users but does not protect the remote user from inadvertently causing the connection release. (Redirecting output to the users own terminal would release the connection.) On the other hand allowing release requests from the f i l e instance's owner process i s provides adequate connection protection but i s unnecessarily r e s t r i c t i v e . An alternative solution used within the ITI (Interactive Terminal Interface) protocol server u t i l i z e s primary and secondary f i l e i d e n t i f i e r s to ide n t i f y a communication f i l e instance. The primary and secondary f i l e i d e n t i f i e r s refer to the same physical f i l e and are indistinguishable by user processes. Seperate f i l e i d e n t i f i e r s provide a means of identifying requests from a 'primary' application from those of secondary users. Both f i l e i d e n t i f i e r s are recognized by the communication servers for n o n - c r i t i c a l requests (such as- read-and write requests), whilst only the primary f i l e id i s accepted for c r i t i c a l requests (such as the release request). The secondary f i l e i d e n t i f i e r i s returned to the requesting process on create instance and query instance requests that do not provide the primary f i l e i d e n t i f i e r with the request. The secondary f i l e i d e n t i f i e r s are also returned on f i l e i d e n t i f i e r queries addressed to the name server. (The Verex name server allows objects to be i d e n t i f i e d by name and - i f known - to have the associated server and f i l e i d e n t i f i e r returned on query 35 requests.) The primary f i l e i d e n t i f i e r is known only by the o r i g i n a l owner (and any process that i t chooses to send this information to) and represents the authority for performing c r i t i c a l service requests. As the o r i g i n a l 'owner' process is the only process given the primary f i l e i d e n t i f i e r , the provision of connection security without interference from other users is the r e s p o n s i b i l i t y of the owner applicat i o n . This approach is consistent with the handling of f i l e s when a unique f i l e instance i s provided on each create instance request. The secondary f i l e i d e n t i f i e r allows the communication servers to manifest i t s services in a manner i d e n t i c a l to other system I/O servers. In achieving this the ITI server eliminate apparent differences between l o c a l and remote I/O operations. In addition to the standard I/O requests, there are non-standard requests that are supported by some communication e n t i t i e s . Non-standard requests are necessary for non-standard I/O services provided by the*- communication servers ' i These, include: (a) Control request. The control request is used to change the mode of operation of the communication en t i t y . (eg. Transparent to non-transparent operation mode.) (b) Control query. Query the specified f i l e instance for f i l e type dependent information, ( i e . For communication f i l e types this includes providing c a l l o r i g i n address, f a c i l i t i e s requested etc.) 36 The ITI server/X.25 server interface uses the I/O protocol in a non-standard manner by appending an additional byte to the user data that is interpreted by the X.25 server as control data for setting the Q and M control b i t s within the X.25 packet le v e l header. This i s a result of the interdependence of the ITI protocol upon the underlying X.25 protocol. The non-standard nature of thi s interface precludes most applications from using the standard I/O protocol to d i r e c t l y access the X.25 level services. 3.1.3 Stati c and Dynamic Servers. We define s t a t i c server processes as those processes that execute at a l l times whilst the. system i s running. Dynamic servers are created when their services are required and are subsequently released when no longer needed. The Verex communication structure uses both s t a t i c and dynamic service e n t i t i e s to implement higher l e v e l service support. The choice between providing s t a t i c or dynamic servers is based upon the following considerations: (a) The frequency of invocation. A server w i l l not benefit from dynamic invocation i f i t is required on a very frequent basis. Incoming c a l l s are s u f f i c i e n t l y infrequent events that the dynamic invocation of these transformation servers frees system resources that would be committed but otherwise be unused. (b) The duration of service and state information. 37 When a server must provide services to users, at a l l times and must maintain state information for a number of users a s t a t i c model serves best. If the services are required over a fixed duration of time, bounded in this case by the c a l l establishment and.the c a l l release, the server may be released during the i d l e times, (c) Variable number servers. Providing equivalent services many d i f f e r i n g servers requires growing numbers of servers i f these are s t a t i c a l l y maintained. Dynamic servers respond to demand as they are created only as required. Subsequently they do not represent additional overhead when multiple servers are required at each l e v e l . The dynamic creation of servers allows their dynamic destruction, thereby providing automatic cleanup of unused server processes. The communication system is made up of dynamic server processes that provide the model with f l e x i b i l i t y without redundant server modules. The ITI server, and other transformation l e v e l servers are created upon demand so that unused servers do not exist for i d l e l o g i c a l channels. 3.1.4 R e l i a b i l i t y and Dependency. The r e l i a b i l i t y of the communication system in general i s enhanced i f the communication servers and their dependent servers can be v e r i f i e d . Each server i s dependent upon the services and r e l i a b i l i t y of any subordinate server from which i t requires services. To avoid c i r c u l a r dependency each server 38 makes requests of lower l e v e l servers only. Asynchronous event n o t i f i c a t i o n from a lower to higher l e v e l is achieved in two ways without v i o l a t i n g these dependency conventions. These are: (a) The destruction of processes associated with a higher l e v e l . This i s used within the communication system to indicate that an . interactive break or other asynchronous event has occurred at the lower l e v e l . (b) The invocation of a higher l e v e l entity. The invocation process does not require invoking server to commit i t s e l f by way of making i t s own address space accessable to the newly created server or by blocking on the new server. Server invocation i s used by the X.25 l e v e l server when the required higher l e v e l server must be dynamically created following the. reception of an incoming c a l l . Figure 4 i l l u s t r a t e s the downward di r e c t i o n of service requests within the communication system and the upward server invocation that performs event n o t i f i c a t i o n to higher l e v e l s . 3 9 Application service request Network Server server invocation service requests V Session Server Transport F a c i l i t y . ( X.25 Server ) server invocation service request Figure 4 Service requests and server invocation, 3.2 The Communication Model Implementation, The communication model consists of three e n t i t i e s . These are b r i e f l y l i s t e d below and described more f u l l y in the remainder of thi s chapter. (a) The ITI server. The ITI server provides the user with an addressable I/O server for remote I/O operations. It supports the ITI (Interactive Terminal Interface) protocol and provides basic terminal oriented I/O fu n c t i o n a l i t y which includes some 40 l o c a l character translations. A l t e r n a t i v e l y i t operates in a transparent mode of operation thereby having additional f u n c t i o n a l i t y provided by higher layers. (b) The session server. The session server maintains l o c a l and remote user session records. Remote session records are used to establish, reconnect and release higher l e v e l v i r t u a l connections and perform the l o c a l administrative functions. The session server is d i r e c t l y responsible for dynamically creating the protocol and application servers as requested by an incoming c a l l . (c) The network server. The network server determines the c a l l requirements from the X.25 c a l l frame and sends the appropriate service requests to the session server to establish the required higher l e v e l communication layers. 3.2.1 The ITI Server. The ITI server is a transformation l e v e l protocol server dynamically created as a result of receiving an incoming c a l l . It i s used to support the ITI protocol as defined in [Datapac 1978], and provides remote terminal and intersystem communication services. The ITI server provides the NIM (Network Interface Machine) to NIM interface necessary for parameter negotiation and data exchange. NIM control data management for interrupt recognition is also provided by the ITI server in addition the exchange of user data. 41 The ITI server is composed of four processes as depicted in Fig. 5 below. The main ITI server process i s the process addressed by user processes when I/O services are required over the l o g i c a l channel in use. The I/O request involves a message SEND to the ITI server process indicating the request type and buffer areas i f these are required. The ITI server process does not communicate d i r e c t l y with the lower l e v e l server but uses additional slave reader/writer processes to do t h i s . The multiprocess server implementation allows concurrent service requests to be made of the ITI server. The additional reader and writer processes block awaiting the service reply from the underlying X.25 l o g i c a l channel server whilst allowing the ITI server to accept other user requests. The timer process i s used to notify the main ITI server process of timeouts that may occur under various conditions for resource reclamation (see section 3.3.2). 42 user > write user ITI -read Server other > user req's wr 1 te requests read requests timeout Writer Reader Timer write > requests X.25. Logical Channel Server read request Figure 5 The ITI server design. (Arrows indicate data flow.) The reader and writer processes i n i t i a l l y SEND to the ITI process indicating their a v a i l a b i l i t y thereby blocking u n t i l the ITI process r e p l i e s . When a read/write request i s received by the ITI server a reply i s made to the reader/writer process giving the nature of the request and the location the user data. The user data has the necessary data transformations applied (to remove l o c a l system idiosyncrasies) and a I/O request i s sent to the X.25 server. While the reader and writer processes remain blocked awaiting the reply of the lower transport l e v e l server, the ITI server is free to accept other user requests. The reader and writer processes send a read/write complete event n o t i f i c a t i o n to the ITI server when the transport l e v e l request has been s a t i s f i e d . The ITI server re p l i e s to a read request only when the read operation has been completely s a t i s f i e d . Read requests received when a read request i s currently oustanding are not accepted. 43 Write requests may be queued, but o n l y t o allow multiple users concurrent access to the communication l i n k . Individual process write requests are replied to only when the request has been accepted by the lower l e v e l . This prevents any single process from swamping the ITI server with an unmanageable amount of write requests. The ITI server provides the standard I/O services to the user and additional non-standard control requests that allow the user to specify or a l t e r the mode of operation. The ITI server also performs the following functions. (a) Local/external data transformation. Local system c h a r a c t e r i s t i c s are removed from user data. Tab characters are expanded and CR LF pairs inserted for NL (newline) characters on output. On input l o c a l l y recognized NL characters are exchanged for CR characters. (b) Control data interpretation. User breaks are forwarded by the NIM as INDICATION-OF-BREAK packets. This is recognised by the ITI server and replied to by sending a control packet indicating that output should be resumed. (c) Error and resource recovery procedures. The ITI server provides the f a c i l i t y to 'suspend' a user's terminal session when the underlying transport connection f a i l s . The user then resumes the terminal session by reestablishing the transport connection and the ITI server (with the help of t h e session s e r v e r ) u s e s t h e n e w l y established transport connection for the duration of the terminal session. 44 The data transformation and control data interpretation are functions that may be i n d i v i d u a l l y enabled or disabled as required by higher l e v e l users. The modes of operation are: Transparent input (a) and transparent output (b) modes allow the ITI server to transport data unedited. This allows higher l e v e l data transformations to be applied that do not necessarily correspond to the terminal data transformations otherwise applied by the ITI server. The transparent mode of operation (c) allows end to end communication without data transformation or l o c a l or remote NIM interpretation of special control characters. For example XON and XOFF are not recognised as control data. In thi s mode of operation the interpretation of control data is performed by higher layers from the contents of the user data. The ITI server i s asynchronously n o t i f i e d of exceptional events at the transport l e v e l by the destruction of i t s timer process. This event is detected by the ITI server which responds by recreating the timer process and issuing a read request to the transport l e v e l i f none was currently outstanding. The reply to the read request indicates the nature of the event. Possible exceptional conditions include: the reception of an interrupt n o t i f i c a t i o n and the f a i l u r e (or remote disconnection) of the transport connection. The error recovery procedures following (a) Transparent input. (enabled/disabled) (b) Transparent output. (enabled/disabled) (c) Transparent mode. (enabled/disabled) 45 transport connection f a i l u r e are described in section 6. The ITI server provides the higher l e v e l user a s u f f i c i e n t l y large block size so that the high u t i l i z a t i o n of the transport frame may be achieved. This large block size can be segmented and forwarded to the transport l e v e l in a block size amenable to the lower l e v e l protocol server. As the ITI server performs data substitution that w i l l a l t e r the length of the data, (tab ; expansion and CR,. LF substitution for NL) i t i s not possible to allocate an optimum block size for the user. It is interesting to observe that the i n i t i a l block size chosen provided the user with the maximum X.25 single packet data size (255 bytes). This produced near to worst case r e s u l t s . The incidence" of tabs and NL (newline) substitutions is common in textual data, so that most frames required some expansion, thereby requiring a second n o n - f i l l e d packet. A compromise between a limited amount of free buffer space and the use of a large block size which would allow N f u l l transport frames to be transmitted for each non-full packet was made. A block size of 600 bytes was used, thereby allowing two f u l l X.25 frames to be transmitted for each n o n - f i l l e d frame that included leftover text plus any characters that came about as a result of data expansion. 46 3.2.2 The Session Server. The session server is a s t a t i c system server that provides both communication and application sessional services. The communication sessional services are provided over the complete duration of the c a l l , including periods where the communication connection has been lost due to transport system f a i l u r e . The session services provided at each phase of the communication session are given below. (a) C a l l establishment. i . Invoke the service module for each required protocol layer as requested by the network server, i i . Invoke the service application i f the c a l l i s accepted. (b) C a l l maintenance. i . Maintain c a l l information concerning communication sessions. (Includes the user, c a l l o r i g i n , f a c i l i t i e s requested, I/O server. ) (c) C a l l Reconnection. i . Maintain a record of the suspended application sessions, i i . I n i t i a t e session reconnection i f connection i s reestablished. (d) C a l l release. i . Maintain an access log to record remote user access. Protocol servers are invoked by the session server on behalf of the network server because team destruction within Verex also removes a l l descendants that have been invoked. (Thereby removing unused process teams and servers.) The session 47 server is s t a t i c a l l y maintained and so may invoke protocol servers on behalf of the network server. In addition to performing the protocol server and application invocation functions, the session server maintains l o c a l and remote session information in the form of two l i s t s composed of both l o c a l and remote session records respectively. Remote users are represented within both l i s t s , whilst l o c a l users are represented within the l o c a l l i s t only. The remote session records are used for query and administrative functions. Local users have query access to the information of both l i s t s , whilst the remote l i s t i s also used in the c a l l session establishment, reconnection and release functions. The remote session record is created when the c a l l has been accepted, and the requested application has been invoked. When a transport connection f a i l u r e causes- the- application to be suspended, the transformation l e v e l server (the ITI server is currently the only transformation l e v e l server offering this function) sends a suspension n o t i f i c a t i o n to the session server and awaits i t s response. The session server w i l l reply to the suspended server only when the same user has reestablished the connection and has requested the same applicat i o n . When this occurs the session server i n i t i a t e s the reconnection by replying to the suspended server module and the entity that requested the new session connection. Once th i s is done the r e s p o n s i b i l i t y for the formal transfer of ownership of the transport connection is 48 performed between equivalent protocol servers. The release of the network connection w i l l result in the removal of the appropriate session from the remote session l i s t . The information from the deleted record is written to a network log that is maintained to record system access by remote users. 3.2.3 The Network Server. The network server i s dynamically invoked and provided with the contents of the incoming c a l l frame when the underlying transport system (in t h i s instance an X.25 service) receives an incoming c a l l . The network server retrieves from the c a l l frame the higher l e v e l service and protocol requirements for the c a l l , as well as other c a l l dependent information (charging, c a l l p r i o r i t y , c a l l o r i g i n address, etc) and uses these to establish the communication f a c i l i t i e s as required. The remote user may choose to specify each protocol layer (and is responsible for selecting a meaningful construction of protocol layers) or may use the default protocol and service s p e c i f i c a t i o n . The default protocol and service f a c i l i t i e s within Verex are the ITI protocol and the invocation of a system login service respectively. The protocol requirements are specified in ascending sequence (lower to higher level) within the incoming c a l l frame. These are terminated by the application service s p e c i f i c a t i o n . Each protocol layer s p e c i f i c a t i o n i s interpreted by the network 4 9 server from a string of characters denoting the generic protocol name. The protocol layer is b u i l t upon the existing protocol layers by invoking a new protocol module that uses the lower module as i t s own I/O server. The highest l e v e l protocol module is the only v i s i b l e point of access to the communication system. This access point w i l l change with the addition of each protocol layer u n t i l the service application i s invoked. The highest l e v e l module provides the user interface to t h e communication system I/O services. F i g . 6 below i l l u s t r a t e s an example X.25 c a l l frame that requires an ITI protocol, a terminal handling (TTY) f a c i l i t y and the standard system login service. These requests are translated into service requests that 50 X.25 Incoming c a l l frame, X.25 header F a c i l i t i e s ITI TTY LOGIN Send session server request. Request type Protocol type Network server id Network f i l e i d INVOKE PROTOCOL ITI <-X.25 server X. 25 f i l e id Send session server request. Request type Protocol type Network server id Network f i l e i d INVOKE.PROTOCOL TTY •<• ITI server ITI f i l e id Send session server request Request type Service type Network server id Network f i l e id F a c i l i t i e s C a l l o r i g i n NETWORK CALLIN LOGIN <• TTY server TTY f i l e i d from c a l l frame from c a l l frame Figure 6 X.25 c a l l frame and resulting session server requests. The c a l l i s accepted only i f each layer can be successfully b u i l t and the session server allows the connection. The f a i l u r e to successfully invoke any protocol layer or the refusal of the c a l l (as determined by the session server) results in the release of a l l established communication components. Releasing the current network access server results in the release of a l l subordinate layers and their associated modules. Static servers within the transport level return to an idle state. The network server is required, only during' the c a l l establishment phase, and terminates following the acceptance or f a i l u r e of the connection to be established. 51 3.3 Error Recovery. The error recovery functions of the transformation system provide a means of error recovery from complete transport system f a i l u r e . The transport system i t s e l f i s considered as being error free but prone to occasional f a i l u r e . Error recovery at higher levels provides higher level sessions that are maintained over transport system f a i l u r e s and are transparent at the application l e v e l . Resource recovery functions are provided by the ITI server to release idle processes following transport f a i l u r e and f a i l u r e of the user-application to d i r e c t l y release the l o g i c a l channel. 3 . 3 . 1 Session Recovery. The ITI server provides sessional error recovery functions that allow transformation sessions to be maintained over disruptions caused by connection f a i l u r e at the transport l e v e l . (Transport connection f a i l u r e may* be the result of li n e f a i l u r e , intermediate node f a i l u r e , a deliberate transport connection release or other action.) The application i s unaware of any disruption to the I/O service and executes u n t i l a read or write operation is requested of the ITI server. When this occurs the application is blocked u n t i l the transport connection i s reestablished. If the connection i s reestablished the application w i l l be unaware that any disruption has occured. If the connection is not reestablished (after a predetermined period of time) the outstanding I/O requests w i l l return an end-of-fi l e condition when the communication I/O server 52 terminates. The ITI server detects the f a i l u r e of the transport system when timer process is destroyed by the lower transport level server. The timer process destruction indicates that an exception condition has occured at the transport l e v e l . The ITI server subsequently issues a read request to the transport l e v e l server i f i f none was outstanding. The reply to the read request indicates i f an. interrupt has been received, the transport connection has been cleared or other exceptional event. Once the ITI server i s aware of the transport f a i l u r e , a l l subsequent user requests are blocked. The session server i s n o t i f i e d by a message SEND that the transport connection has been l o s t . The ITI server i s then suspended, awaiting reconnection at the transport l e v e l . ' The suspended ITI server remains blocked u n t i l either of the following two events occur. (a) The transport l e v e l connection i s reestablished. This includes v e r i f i c a t i o n that the new transport l e v e l connection represents the same remote user and user application. (b) A timeout (of arb i t r a r y length determined when the system is generated ) occurs that is used as the basis for releasing any resources committed to the suspended session. Race conditions between the timeout and the reconnection always result in favour of the timeout. Once a timeout occurs 53 any subsequent remote connection (by the same user) establishes a new application session. The session server v e r i f i e s the identity of the new remote user as the same user whose session was suspended. This involves the remote user in the usual user/password login sequence. When the session server i s s a t i s f i e d that the new remote user is the same user, the suspended ITI server is given the server i d e n t i f i e r of the corresponding new ITI server. N o t i f i c a t i o n of the pending reconnection i s also returned to the entity addressing the session server on behalf of the new connection establishment. (For interactive user sessions the login server is the server responsible for thi s action.) The reconnection i t s e l f i s performed by the cooperating ITI servers ( i e . the previously suspended ITI server and the ITI server representing the newly established connection). The complete sequence of events that occur in the reconnection process are described and i l l u s t r a t e d 1 in Appendix: A. 3.3.2 Garbage Coll e c t i o n and Resource Reclamation. Committed but unused resources and id l e communication servers may exist within this implementation for two reasons. F i r s t l y the suspension of user sessions does not guarantee that the user may i n i t i a t e the transport l e v e l reconnection, thereby leaving those servers and resources committed to the idle connection. Secondly an application may f a i l to release those resources that are used by the communication f a c i l i t y (as is 54 allowed by the Verex I/ O protocol where formal release is considered more as a courtesy action than a necessary one). Non-released communication f a c i l i t i e s , such as unused l o g i c a l channels at the transport l e v e l , can be recovered by lo c a l system applications for outgoing c a l l s as required. However incoming c a l l s w i l l be denied access i f a l l l o g i c a l channels are in a non-idle state. The approach used for resource reclamation by the ITI server is to identif y one application process as the application session 'owner'. This process may elect another as owner i f the connection is to be used by multiple sequential applications. The connection is considered idle either when formally released by a primary user process, ( i e . a process that supplies the primary f i l e i d e n t i f i e r ) or when no owner process e x i s t s . The existence of the owner process is regularly checked by the timer process of the ITI server (see Fig. 5). If after the timeout period has elapsed the owner application no longer exists the communication resources and servers are released. Session suspension, due to transport connection f a i l u r e , also results in the maintenance of unused communication and application resources whenever the user chooses not to reestablish the connection. The transport l e v e l l o g i c a l channels are not committed, so incoming c a l l s are accepted despite the existence of a higher l e v e l suspended session. The committed resources are those currently held by the application, (which is in a blocked state i f any request has been made to the communication system) and the suspended transformation l e v e l 55 server processes. Suspended sessions are maintained for an arbitr a r y length of time (in the order of minutes rather than seconds). This time must be s u f f i c i e n t for the user to reestablish the connection and v e r i f y himself to the system as the same user as that of the previous suspended session. The timer process of the ITI server w i l l release the suspended ITI server when suspended session timeout occurs. This action causes an e n d - o f - f i l e condition for any outstanding I/O requests. The function of the timer i s not inhibited when the ITI server is blocked. 56 Chapter 4. A Dyamic Communication System Design. 4.1 A Modular System Structure. The communication model that we propose i s comprised of three p r i n c i p l e levels of f u n c t i o n a l i t y , these being the application l e v e l , the application dependent data transformation le v e l f a c i l i t y and the data transport l e v e l . The application dictates the nature and quality of service that i s provided by the subordinate transformation and transport l e v e l s . The relationship between these levels is shown below in Figure 7. application user communication system services t ran s format ion l e v e l transformation layer n transformat ion layer n-1 transport l e v e l transport layer n transport layer n-1 Figure 7 Functional levels and sub-level layers. Each of the transformation and transport levels are 57 composed of n (one or more) layers that in t o t a l provide the services and functions for a given application. A s i g n i f i c a n t aspect of this design is the varying composition of the transformation l e v e l . Unlike the OSI model, with a fixed number of layers (seven), each having an associated protocol, this structure allows the communication components to be established in response to the service requirements of a par t i c u l a r application. The determination of the i n i t i a l composition of the transformation l e v e l i s made during the i n i t i a l connection establishment phase. 4.1.1 Protocol Management and F i l t e r Modules. The design we propose provides s i m p l i c i t y and f l e x i b i l i t y by structuring the communication system to provide only those services necessary for a p a r t i c u l a r a p p l i c a t i o n . The f l e x i b i l i t y i s achieved by allowing an almost arbi t r a r y interconnection of communication modules that together provide the necessary communication f u n c t i o n a l i t y . System overhead* is reduced by eliminating unused communication modules. F l e x i b i l i t y i s enhanced by providing dynamic communication structuring. Two types of communication modules are defined within the design. Both present a uniform interface to the user and therefore are not v i s i b l y distinguishable to the user, yet there are s i g n i f i c a n t differences within the fu n c t i o n a l i t y of either module type. F i r s t l y a protocol management module is an entity responsible for managing an interactive (possibly symmetric) protocol. A l l layer e n t i t i e s within the OSI model would f a l l 58 under th i s category of communication module. The second form of communication module does not necessarily support s p e c i f i c protocol, but provides data transformation and service functions that require l o c a l knowledge only. We define the second form of communication modules as f i l t e r modules because they a l t e r the perceived nature of the communication mechanism. F i l t e r s can be used to isol a t e device dependencies and l o c a l system data representation c h a r a c t e r i s t i c s (see section 4.2.2) and to provide l o c a l services such as session reconnection. Protocol management modules are functionally s p e c i f i e d by the protocol they support. F i l t e r modules have l o c a l l y defined f u n c t i o n a l i t y and may be applied to a l t e r the perceived nature of the lower l e v e l services. The f i l t e r modules that are used within t h i s design are functionally similar to f i l t e r s as used within the Unix operating system. The communication structure is composed' only of the communication modules that are e x p l i c i t l y required by the active application to provide the necessary communication services. Each module provides a uniform interface for the interaction between modules and the application (see section 4.2.1). The structure of the communication system is determined dynamically during the i n i t i a l connection establishment phase. F i l t e r and protocol management modules are invoked and linked as required. The two types of communication modules are used in the example shown below. The f i l t e r module i s applied to provide 59 f u l l screen terminal support when the underlying, v i r t u a l terminal protocol module provides only s c r o l l mode or transparent f u n c t i o n a l i t y . Example 1. A f i l t e r module is applied to a terminal support (ITI) protocol so as to provide f u l l screen, f u l l duplex operation whilst using an underlying protocol that provides only s c r o l l mode terminal support or a transparent mode of operation. When the terminal (TTY) f i l t e r module is invoked i t requests that the subordinate protocol (ITI) module enter the transparent mode of operation. The ITI protocol module then does not provide data translation but continues to perform protocol control management functions. Exception conditions, such as interrupts are interpreted by the ITI module and the higher l e v e l TTY module is n o t i f i e d by means of the l o c a l interface. A l l data transformation is performed by the higher l e v e l f i l t e r module. Fi g . 8 i l l u s t r a t e s the communication system construction for the described terminal support. 60 Command Interpreter Application l e v e l . TTY _ tty f i l t e r Transformation l e v e l . ITI protocol X.25 protocol Transport l e v e l , (multiple modules) Figure 8 Terminal support communication modules. In F i g . 8 the ITI module and X.25 module(s) are responsible for supporting the ITI protocol and the three X.25 protocol layers respectively. The TTY module performs data interpretation and translation functions that are l o c a l functions and do not require s p e c i f i c protocol data to be exchanged. 4.2 Transformation Level Functionality. 4.2.1 A Uniform Communication Module Interface. Standard system services can be conveniently represented by those services that are supplied by any I/O process. A standard 61 I/O interface can be used for both l o c a l and remote I/O operations. If the d i s t i n c t i o n between loc a l and remote I/O operations is not apparent at the application l e v e l then the application may use either environment transparently. The d i s t r i b u t i o n of services and resources i s f a c i l i t a t e d by providing a standard I/O interface applicable to both the communication system services and the l o c a l I/O operations. We define the basic services provided upon request by a l l transformation l e v e l communication modules to be those given below. These are: (a) Open connection. (system/application dependent) (b) Close connection. (c) Write data. (d) Read data. (e) N o t i f i c a t i o n of interrupt. (f) Query response. (g) Alter 'ownership' of the f i l e (connection). These services apply both to communication related ' f i l e s ' as well as the established I/O f i l e s . Both f i l e types appear i d e n t i c a l to application I/O requests, thereby allowing applications access to a d i s t r i b u t e d environment that is apparently l o c a l . Non-standard services are provided because some applications may recognize the d i s t i n c t i o n between l o c a l and remote communication fu n c t i o n a l i t y and require alternative 62 services. A l t e r n a t i v e l y some communication modules may make non-standard communication requests amongst themselves. The nature of these non-standard services w i l l be system dependent. Some t y p i c a l non-standard services would include: (a) Alter mode of operation request. (b) Send interrupt. (c) Query connection dependent information. (d) Reconnect to new subordinate module. Applications that make use of non-standard I/O services provided by the communication modules are not immediately interchangable between a l o c a l and di s t r i b u t e d environment. These are primarily applications designed to operate and manage functions that are relevant to the di s t r i b u t e d environment. For example, an interactive f i l e transfer program may translate a user interrupt as an interrupt directed towards the f i l e transfer i f one is current. A 'send interrupt' request is. directed to the communication module that manages the application session concerned with the f i l e transfer. The 'send interrupt' request is not a standard I/O request as i t does not correspond to l o c a l I/O function as we have defined them, but is necessary for synchronization between remote interactive processes. A standard interface for communication modules i s necessary to support the f l e x i b i l i t y of the (almost) arbitrary module interconnection provided within t h i s design. Without a standard interface between a l l modules, the interconnection of 63 communication modules would be possible only on a greatly r e s t r i c t e d basis. Where modules support non-standard services in addition to supporting the standard I/O interface, the f u l l f u n c t i o n a l i t y of the module may not be available for those modules that u t i l i z e standard I/O requests only. Alte r n a t i v e l y those modules that make non-standard requests to the subordinate layer must have those requests s a t i s f i e d i f they are to operate c o r r e c t l y . For example a request for a subordinate module to operate in a transparent mode w i l l not succeed . i f the module does not support transparent operation. Modules cannot be interconnected in a f u l l y a r b i t r a r y manner because of t h i s . 4.2.2 Data Transformation and Transparency. The primary function of the transformation l e v e l modules is to provide the user application with data in the format with which i s most convenient. Whilst doing t h i s the transformation modules perform the higher l e v e l protocol management. Data must be translated by transformation- l e v e l modules- to/from- an-established 'standard' data representation so that system and device dependencies can be avoided. The transformation module is required to . do two things. F i r s t l y to perform data transformation between a l o c a l and standard format and secondly to provide the high level protocol management functions. The protocol management and data transformation functions can be separated so that a protocol management module performs the protocol management functions alone and system dependent data transformations are performed by a separate f i l t e r module. 64 System dependencies are then encapsulated within f i l t e r modules. The v e r s a t i l i t y of protocol management modules is enhanced, as sp e c i f i c l o c a l data transformation functions are removed. F i l t e r modules then become simpler to develop as they do not require the complexity of providing interactive protocol management. The data transformation function can be performed by a higher l e v e l f i l t e r module or by the application i t s e l f . When the data transformation f u n c t i o n a l i t y of a subordinate f i l t e r i s not required an alternative mode of operation i s necessary within the lower l e v e l f i l t e r module that allows data to be passed unaltered. This mode of operation, c a l l e d transparent mode, i s required i f multilevel f i l t e r modules are to be allowed to coexist in a non-interfering h i e r a r c h i c a l structure of f i l t e r and protocol management modules. Stacking f i l t e r modules does not necessarily imply the need for a transparency function as higher l e v e l f i l t e r s may s t i l l require these functions, but i t provides a means of bypassing the data transformation process when thi s i s not required. 4.2.3 Error Recovery and Session Management. The transformation system design presumes the presence of a transport f a c i l i t y that is error-free (within allowable bounds) although prone to f a i l u r e . F a i l u r e of the transport f a c i l i t y may be the result of li n e f a i l u r e , system f a i l u r e or other unexpected disruption. It is thi s error situation that is of concern at the transformation system l e v e l . 65 The objective of the error recovery c a p a b i l i t i e s at the transformation l e v e l is to al-l-ow applications continued operation over disruptions to the service provided by the transport system. This requires the transformation level modules to maintain state information u n t i l the transport connection can be reestablished. The application session may exist over many transport sessions. A l t e r n a t i v e l y a single transport session may exist over several application sessions yet must have at least one active application session active to be considered as s t i l l a c tive. Inactive transport sessions may result .from f a i l u r e to release a communication I/O connection at the application l e v e l , thus requiring transformation l e v e l garbage c o l l e c t i o n . Fig 9 i l l u s t r a t e s the n :n relationship between application and transport sessions. application session application sessions transport sessions < > < > < > transport session Figure 9 Multiple transport/application sessions, To provide transport f a i l u r e error recovery the communication system u t i l i z e s the concept of an application session. The application (or higher l e v e l transformation e n t i t i e s ) are unaware of the disruption of service due to a transport session f a i l u r e . Reconnection of a transport session 66 to an existing transformation session w i l l require the intervention of another system management entity, the session manager. This session management entity is described in section 4.3.3. Error recovery due to transport f a i l u r e imposes two levels of complexity, both of which are dependent upon the nature of the appli c a t i o n . The simplest of these is the n o n - c r i t i c a l data application, in which loss of data due to exceptional conditions i s acceptable. An example of an application for which data loss i s acceptable (as an alternative to session termination) is timesharing support for a remote terminal users. The alternative condition i s that in which loss of data (or duplication of data) i s unacceptable. In this case the complexity of the error recovery procedures provided is considerably greater. Data sequencing i s necessary so as to ensure data consistency. Sequencing data requires additional complexity and protocol overhead on the existing- transformation system. An additional protocol layer w i l l be necessary to provide the sequencing f u n c t i o n a l i t y i f not already provided and thus ensure no loss or duplication of data on transport system f a i l u r e . The implementation described in chapter 3 takes only the former approach allowing possible data loss and duplication. Multiple application sessions per transport session can be achieved either by multiplexing application " sessions over the transport connection, or by allowing the application session to be changed at the dis c r e t i o n of the applicat i o n . An application 67 is free to terminate the application session at any time or to pass 'ownership' of the communication f a c i l i t i e s to another application process thereby i n i t i a t i n g another application session. This is the normal course of events within the implementation described in chapter3 in which the i n i t i a l application that interacts with the remote user i s a system entry and user v e r i f i c a t i o n (login) procedure. When the user has i d e n t i f i e d him/herself to the s a t i s f a c t i o n of the l o c a l system the next application process is allocated the connection session ownership priviledgess. The other alternative i s to allow multiple transport sessions per application session. This i s achieved when the transport f a c i l i t y i s lost and subsequently reconnected. The application processes (and higher l e v e l transformation modules) are unaware that the reconnection has occurred. The reconnection is provided by the transformation module that manages the transformation/transport l e v e l interface with the cooperation of some coordinating, system service. (In this case the session server may f u l f i l t h i s function.) 4.2.4 Blocking and Segmentation. The approach to blocking and segmentation taken within this design is to provide as few blocking/segmenting operations as possible within the communication system i t s e l f . The transmission block size is determined by the transport l e v e l . This presents an upper bound upon the data unit size that can be transmitted. Blocking/segmentation is performed at the 68 transformation/transport level interface. Transformation l e v e l block size is not r e s t r i c t e d by the transport block size as this l e v e l of f u n c t i o n a l i t y i s inherently v i r t u a l and may provide a r b i t r a r i l y large block sizes to higher l e v e l users. The choice of block size should be chosen f i r s t l y to be suitable for the application and secondly to attempt to u t i l i z e the transport f a c i l i t y as f u l l y as possible. As the transformation l e v e l has no upper or lower bound (within system li m i t s ) each transformation module can provide and use the same user data block s i z e . S u f f i c i e n t buffer expansion must be provided i f additional protocol header information is appended. Blocking/segmentation i s then required only i f the layer performs data expansion/contraction as a result of i t s data transformation functions and at the transformation/transport le v e l interface where the transport l e v e l protocol dictates the block size. This approach appears to be less f l e x i b l e than that u t i l i z e d by the OSI model whereby- data- units of d i f f e r i n g size-are allowed at each layer interface. Within the OSI model the data unit may be altered three times or more times in the exchange of data between layers. The OSI .model spec i f i e s the protocol data unit (PDU) of the f i r s t layer, which may be blocked/segmented to the interface data unit size (IDU), which then must conform to a given service data unit size (SDU) before being accepted at the next layer entity in protocol data units (PDU) s i z e . Given the number of layers in the OSI model, such f l e x i b i l i t y in segmenting and blocking becomes more burdensome than useful. 69 4.3 Transformation Level Components. The three types of components that cooperate to provide the services of the transformation l e v e l within this design are the transformation l e v e l modules, an incoming c a l l handler and a session manager. The c a l l handler i s required only during the c a l l establishment phase and the session manager is a system management entity that provides sessional services upon request to a l l users. Fi g . 10 i l l u s t r a t e s a t y p i c a l sequence of events required to e s t a b l i s h an application session after an incoming c a l l is received by the transport system. 70 Applicat ion le v e l Application Step # 5. Interact with remote user Transformat ion le v e l Transformat ion modules Session Manager C a l l Handler Perform protocol dependent i n i t i a l i z a t i o n . Provide user request servicing. Create or allocate the required application, transformation components. Determine c a l l requirements. i e . Application, protocol, operation mode, c a l l c h a r a c t e r i s t i c s etc. Transport l e v e l Transport system 1. Receive incoming c a l l . Notify c a l l handler. Figure 10 C a l l establishment phase. 4.3.1 Data Transformation Modules, The transformation level i s composed of n (one or more) transformation modules. Each module is layered so as to u t i l i z e the services of the layer below and enhance the provided services with i t s own f u n c t i o n a l i t y . The topmost data transformation module is the only communication system entity 71 through which users request communication services. Application access to subordinate e n t i t i e s is not defined within this design although any transformation layer module or basic transport module may present i t s e l f as the topmost communication layer i f requested. Unlike the OSI model the composition of the transformation l e v e l i s not fixed. F i g . 11 depicts three possible transformation l e v e l configurations, each based upon an X.25 transport f a c i l i t y and an ITI protocol at. the transformation l e v e l . Fig 11(a) provides simple terminal access to a timesharing application using the ITI protocol transformation l e v e l module. Fig 11(b) provides enhanced terminal access using the ITI protocol in a transparent mode of operation by adding a terminal handler f i l t e r . Fig 11(c) i l l u s t r a t e s a f i l e transfer application, again using the ITI protocol in transparent mode. A f i l e transfer f i l t e r applies a l o c a l system f i l e interface that is used to transform data to l o c a l f i l e system formats. Each of these configurations u t i l i z e s a-reconnection/segmentation/blocking f i l t e r at the transformation and transport l e v e l interface. 72 command interpreter command interpreter f i l e transfer Applicat ion l e v e l . ITI Reconnection/ Segmenting/ Blocking f i l t e r terminal handler f i l t e r ITI (transparent) Reconnection/ Segmenting/ Blocking f i l t e r f i l e transfer f i l t e r ITI (transparent) Reconnection/ Segmenting/ Blocking/ f i l t e r Trans-formation l e v e l . X.25 X.25 X.25 Transport l e v e l . (a) (b) (c) Figure 11 Alternate communication system configurations.. 4.3.2 Incoming C a l l Handler. The incoming c a l l handler is a s t a t i c or dynamically created service f a c i l i t y that i s used to determine the nature of an incoming c a l l and i t s service requirements. The incoming c a l l handler is designed as a separate entity because: (a) The determination of the incoming c a l l requirements may be dependent upon the underlying transport mechanism and as such the transformation protocol dependencies are 73 encapsulated with the c a l l handler. In the implementation described in chapter 3 the incoming c a l l handler is dependent upon the underlying X.25 incoming c a l l frame, (b) The incoming c a l l handler i s required only during the c a l l establishment phase. It serves no function in subsequent interactions. Isolating the transport system dependence within the c a l l handler allows a l l other system components to be designed independent of the pa r t i c u l a r transport system. The c a l l handler, is simple to implement so that the overhead in development for any new transport f a c i l i t y is minimal. Ideally a l l transport protocol dependencies can be removed i f the transport protocol entity assumes the r e s p o n s i b i l i t y of performing the interpretation of the c a l l requirements from the c a l l frame and forwarding these requests in a protocol independent manner. Given the temporary fu n c t i o n a l i t y of the incoming c a l l handler, i t i s convenient to: allow the. c a l l handler to be-created dynamically and then disposed of once the application session and communication system structure has been established. An alternative is to allow a s t a t i c c a l l handler that provides the service of incoming c a l l establishment upon request and i s maintained continuously. The c a l l establishment phase requires that several, actions "be taken by the incoming c a l l handler. These r e s p o n s i b i l i t i e s are to: 74 (a) : Determine the transformation modules that are required for interaction with the remote user. This s p e c i f i e s the high level protocols to -be used and may require one or more transformation modules to provide these f a c i l i t i e s . (b) Determine the nature of the requested a p p l i c a t i o n . Possible alternatives include an interactive timesharing session, an inter-system mail f a c i l i t y or an inter-system f i l e transmission f a c i l i t y . (c) Determine the transport f a c i l i t y requirements. Charging, c a l l o r i g i n and p r i o r i t y f a c i l i t i e s may affect, whether the. c a l l is accepted by the l o c a l system. (d) Forward th i s information to the session management ent i t y . (e) Complete the transfer of transport connection 'ownership' to the newly created transformation module(s). 4.3.3 The Session Manager. The session manager i s a system management entity responsible for the establishment, reconnection and release of higher l e v e l connections (application sessions). Application sessions represent v i r t u a l connections between applications during which time the applications may exchange information. The application session i s terminated when the application releases the connection by a release request directed to the communication access point. Ultimately the release of the higher l e v e l connection causes the release of the underlying transport connection. Applications may transfer 'ownership' of the application session between themselves and are responsible for ensuring that the connection is not inadvertently released. 75 The session manager, as the name implies, provides sessional services and functions for the transformation level modules in addition to any other system services that i t provides. These services and functions may vary with implementation. The fu n c t i o n a l i t y of the session manager may include the following (non exhaustive) services and functions. (a) Session security and v a l i d a t i o n . Determine the acc e p t a b i l i t y of the c a l l given the f a c i l i t i e s requested, i t s o r i g i n etc. (b) Session establishment functions. Aid the c a l l handler in the i n i t i a t i o n of the application and the' transformation level modules as required. (c) Sessional error recovery. Perform reconnection services for transport connection following a transport l e v e l connection f a i l u r e . The application session is maintained over this time. (d) Session termination functions. Release the transport connection or perform other termination functions as required when the application session i s released. (e) Perform l o c a l system security and query tasks. Supplying c a l l information and logging incoming c a l l s are examples of l o c a l query and security functions used within the implementation described in chapter 3. 76 4.4 Comparison with OSI and Pup Architectures. The design described within t h i s thesis, the OSI model and the Pup architecture share some points of commonality. Each communication architecture provides a basic layered structured in which successive layers provide enhanced f u n c t i o n a l i t y . These layers communicate with equivalent layer e n t i t i e s at a remote system using protocols and use interface interactions between layers. Whereas the OSI design designates a single layer (the transformation layer) to provide data transformation and protocol management fun c t i o n a l i t y , the design we have described separates these functions, and allows l o c a l data transformation functions to be performed within independent f i l t e r modules. Data transformation is provided at one or more levels within the communication system. Stacking f i l t e r modules allows new applications to use previously established f i l t e r modules in addition to any new data transformation f u n c t i o n a l i t y they provide. Our design u t i l i z e s dynamic layering of communication modules that are established when an incoming c a l l i s received. This i s similar to the provision of generic socket numbers within Pup that can be addressed .to request p a r t i c u l a r application and protocol services using the rendezvous and termination protocol. The Pup architecture establishes several well known socket addresses that each represent a generic service type, our model provides a single addressable access 77 point. Higher level protocols and services are requested using information contained in the i n i t i a l c a l l frame. Whereas the c a l l establishment mechanisms d i f f e r within both our model and the Pup model, both u t i l i z e generic i d e n t i f i c a t i o n of services. Addressing protocol layers and applications by generic name does not necessitate that each layer address be known by the c a l l i n g system. Generic protocol s p e c i f i c a t i o n also removes the p o s s i b i l i t y of incorrect addressing i f the address is reused by another e n t i t y . On the other hand the ISO model proposes individual layer (as well as other OSI resources) addressing rather than generic service requests. This requires a greater amount of global knowledge to be shared. Like Pup, our design supports many interchangeable components within the communication structure. The choice of protocol support can be made on the basis of application needs, performance requirements, resource. a v a i l a b i l i t y or other considerat ion. However unlike the OSI and Pup models our design is not r e s t r i c t e d to a s p e c i f i c number of layers, nor does each transformation layer represent s p e c i f i c services. A uniform interface between a l l transformation l e v e l modules allows these transformation modules to be l i b e r a l l y interconnected. This f l e x i b i l i t y allows new communication services to be developed from existing services, or to form alternate functional levels with d i f f e r i n g performance c h a r a c t e r i s t i c s thereby allowing 78 several interchangeable protocol modules at one functional l e v e l . This design shows greater s i m i l a r i t y to the Pup architecture than to the OSI model, yet proposes greater f l e x i b i l i t y than available within both designs. The OSI model (and to a lesser degree the Pup design) does not allow applications to access lower l e v e l communication services even when the f u n c t i o n a l i t y required by the user is f u l l y provided by the lower l e v e l . The u t i l i z a t i o n of a uniform I/O interface at a l l l e v e l s of the communication system allows both user access (without application modification) and a r b i t r a r y layer interconnection. The OSI model in p a r t i c u l a r does not provide a s i m p l i f i e d ' mode of operation that requires minimal protocol complexity and overhead. Whereas in this respect the aims of our design and the Pup architecture are similar ( i e . to increase f l e x i b i l i t y by maintaining s i m p l i c i t y ) , the OSI has compromised on s i m p l i c i t y and provides a complex general purpose communication framework. The system complexity i s reduced within our design by providing fewer fixed layers with fewer basic services than provided by the OSI model. Many services required by the OSI reference model, such as downward multiplexing, have limited use and are complex to implement. (For example downward multiplexing requires additional flow control and resequencing f u n c t i o n a l i t y to provide multiplexing services.) Duplication of functions, such as multiplexing, at multiple layers within the architecture 79 increases f l e x i b i l i t y at the expense of greater complexity within each layer that provides this function. Many functions provided within the session layer of the OSI model are required by a minority of applications and could be provided by the application or by higher layers where necessary. One example of t h i s i s the 'quarantine' function of the OSI session layer. The quarantine function has many uses within di s t r i b u t e d applications where data consistency must be ensured. However the quarantine function is apparently an application dependent feature and as such could be provided at a higher layer. The session management functions provided within our design are provided by a management entity as opposed to their provision by a 'session layer' (as proposed by the OSI model). The sessional .manager i s similar in notion of a management entity that resides within the application layer of the OSI model. However', as the session manager provides services (in p a r t i c u l a r the reconnection service) to transformation modules such as the ITI server we implemented, i t resides at a l e v e l below the transformation modules. As i t does not take part in the progress of data through the layered communication structure, the positioning of the sessional manager i s only of significance when considering component interdependencies. The design we have described attempts to minimize the number of redundant services that are provided by a given configuration of the communication system and in doing so 80 provide a simpler, more f l e x i b l e tool for remote access and system interconnection. As within the Pup architecture this design presents a model that allows the dynamic selection of communication services and functions that are d i r e c t l y applicable to the task at hand. 81 Chapter 5. Conclusion. We have used the Verex research computer system as a host environment for an experimental communication system design and implementation. The communication system model described within this thesis represents the f i n a l , but not necessarily ultimate, design that resulted from many i t e r a t i v e refinements to both the implementation and design. This communication model provides a f l e x i b l e framework for the support of high l e v e l protocols. The implementation includes the implementation of the ITI v i r t u a l terminal protocol using an existing X.25 implementation as a transport f a c i l i t y . Extended application f u n c t i o n a l i t y was achieved by the addition of higher order protocols. F u l l screen support was provided by applying a terminal data transformation f i l t e r upon the basic ITI protocol services. A f i l e transfer service also u t i l i z e s the ITI protocol and enhances i t s services by applying i t s own f i l e transfer protocol. The design described within t h i s thesis is a generalization of the Verex communication model implementation. The dynamic communication system structure used within the design and implementation model provides greater f l e x i b i l i t y than i s possible within a s t a t i c structure. The modular structure of the design i s well suited to implementation within a multiprocess design. The server model used within the Verex implementation provides a convenient model for the u t i l i z a t i o n of the uniform module interface. 82 From this experience we have learned that the f l e x i b i l i t y of the communication system is enhanced by the modular (layered) system design. We have found that the uniform module interface greatly enhances the v e r s a t i l i t y of user and interlayer interactions thereby allowing the almost arbitrary interconnection of modules. This uniform module interface allows users to access the communication system at a le v e l that is adequate for the services that they require, thus eliminating unused higher l e v e l protocol layers. The following section reviews the s i g n i f i c a n t issues were addressed within this work. 5.1 Conclusions. The communication system implementation model and design described within t h i s thesis provides a v e r s a t i l e structure for the implementation of high l e v e l protocols. The most important points of the model, and the significance of these are reviewed below. These are: (a) Dynamic i n i t i a l i z a t i o n and linkage of communication modules. Structuring the" communication protocol layers at the time an incoming c a l l is received allows fewer resources to be committed to i d l e communication channels. In addition the requirements of the c a l l are determined at the time of c a l l reception. Communication service modules may be invoked and linked as required to provide the necessary application service support. 83 (b) U t i l i z a t i o n of uniform module interface. The provision of a uniform interface between modules allows almost arbi t r a r y interconnection of modules within the communication system. Within the Verex implementation a l o c a l device independent I/O protocol i s supported by communication modules and other system I/O servers. (c) Application session error recovery. Application session error recovery operations provide applications with some degree of security over transport layer f a i l u r e . The duration of the. application session is determined by the applicat i o n . The communication system and host environment provide a means of maintaining application state when the transport connection f a i l s . The application and higher l e v e l communication modules are suspended u n t i l another transport connection is established. When (and i f ) this occurs the transformation/transport l e v e l interface module reconnects the suspended higher l e v e l modules to the new transport connection thereby allowing continued operation. The communication model that we have described presents an alternative model to that proposed by the OSI reference model. Our model more closely resembles the Pup architecture in that i t provides alternative communication service components at each layer of the model. It is due to the v e r s a t i l i t y of run-time layered modular structuring and the interchangeability of communication modules that provides the f l e x i b i l i t y of the model. 84 5.2 Future Research Areas. The design we have described within t h i s thesis u t i l i z e s many established communication design techniques such as independent layer construction and functionally defined modules. It presents some new communication system design concepts with interesting research p o s s i b i l i t i e s . The provision of a uniform layer (module) interface provides the communication system designer with a powerful tool for the design and implementation of communication, system components and applications. The uniform interface i s used at the application interface l e v e l and the intermodule interface. The application can use the same interface conventions to access the commmunication system at the support l e v e l i t requires. Applications requiring s p e c i f i c performance requirements can d i r e c t l y apply these services at the required l e v e l i f the service requirements cannot be met by existing communication service modules. As in the Pup architecture, application dependent communication services may be s e l e c t i v e l y applied as required and new services developed for new applications. An applied extension of the uniform I/O interface to the X.25 transport l e v e l within the current implementation in Verex would allow direct applications access to the transport l e v e l . Higher l e v e l protocol overhead is therefore reduced to a minimum. Much work needs to be done in assembling a reasonable number of protocol support modules that would form the basis for the communication support services. An interesting application 85 within the Verex system would be to extend the interprocess --message passing c a p a b i l i t i e s (supported by the Verex kernel) to allow remote process message based communication. Direct message passing between a process and a l o c a l 'agent' (representing the remote process) would be supported by l o c a l kernel operations. The remote process agents (one representing each p a r t i c i p a t i n g process) communicate using a remote message protocol. Variable length messages (not supported within Verex) allow data longer than the fixed message length to be passed between remote processes, thereby eliminating the need for interprocess data transfer f a c i l i t y . The multilayered communication system design imposes additional processing overhead at each layer interface when data must be moved across layer boundaries which may span separate address spaces. A means of data sharing (as used in Squire [Chesley and Hunt 1981]) would s i g n i f i c a n t l y reduce this overhead. Data sharing increases the interdependence of separate layers, thus making system v e r i f i a b d l i t y a-more d i f f i c u l t task, but reducing the system overhead incurred in data movement. 86 Bibliography. [ Abraham and Dalai 1980 ] Steven M Abraham and Yogen K Dalai. Techniques for Decentralized Management of Distributed Systems.. IEEE Comcon 80 Spring. San Francisco Feb 25-28 1980. [ Bachman 1978 ] Charles W Bachman. Domestic and International Standards A c t i v i t i e s for Distributed Systems. IEEE Compcom 78 F a l l . Washington Sept 5-8, 1978. [ Bachman and Canepa 1978 ] Charles Bachman and Mike Canepa. The Session Control Layer of an Open System Interconnection. IEEE Compcon 78 F a l l . Washington, Sept 5-8 1978. [ Boggs et a l 1980 ] D.R Boggs, J.F Shoch, E.A Taft and R.M Metcalfe. Pup: An Internetwork Architecture. IEEE Transactions on Communications. A p r i l 1980 [ Berglund 1978 ] Ralph G Berglund. Comparing Network Architectures. Datamation. Feb 1978. [ Burkhardt and Schindler 1981 ] H J Burkhardt and S Schindler. Structuring P r i n c i p l e s of the Communication Architecture of Open Systems - A Systematic Approach. Computer Networks. May 1981. [ CCITT 1980 ] CCITT Study Group VII. Draft Revised CCITT Recommendation X.25. Computer Communications Review. Jan/April 1980. [ Cheriton 1979 ] David R Cheriton. Multi-Process Structuring and the Thot'h Operating System University of B r i t i s h Columbia. Department of Computer Science Technical Report 79-5. 1979. 87 [ Cheriton 1981 ] David R Cheriton. Distributed I/O using an Object-based Protocol. University of B r i t i s h Columbia. Department of Computer Science. Technical Report 81-1, 1981. [ Chesley and Hunt 1981 ] H R Chesley and V B Hunt. Squire - A Communications-Oriented Operating System. Computer Networks. Vol 5. No 5. Sept 1981. [ Datapac 1978 ] The Computer Communications Group; TransCanada Telephone System. Datapac Interactive Terminal Interface. Oct 1978. [ Day 1979 ] John D Day. Resource Sharing Protocols. Computer. Sept 1979. [ Deering 1981 ] Stephen Deering. A Message Based Design for X.25 Software.. University of B r i t i s h Columbia. Department of Computer Science. M.Sc. Thesis (in progress) 1981. [ desJardins 1981 ] Richard desJardins. Overview of the ISO Reference Model of Open Systems Interconnection. Computer Communications Review. A p r i l 1981. [ desJardins and White 1980 ] Richard desJardins and George W White. ISO/ANSI Reference Model of Open Systems Interconnection. IEEE Trends and Applications: Computer Network Protocols 1980. [ Fletcher and Watson 1980 ] John G. Fletcher and Richard W Watson. Service support in a Network Operating System. IEEE Compcon 80 Spring. San Francisco Feb 25-28 1980. [ Grieb 1980 ] Gertrude P Grieb. Open Systems Interconnection -Management and Application Layer Protocol Issues. IEEE International Conference on Communications. Seattle June 8-12 1980. 88 [ Heafner and Wood 1980 ] John F Heafner and Helen M Wood. ISO Presentation Layer Protocol Issues. IEEE international Conference on Communications.. Seattle June 8-12 1980. [ HOllis 1980 ]• Lloyd L H o l l i s . Open Systems Interconnection Upper Layers Ac-tivity. IEEE Compcon 80 F a l l . Washington Sept 23-25 1980. [ ISO 1980 ] ISO/TC97/SC16/N537. Open Systems Interconnection - Basic Reference Model. Computer Communication Review. A p r i l 1981. [ Lauer ] Hugh C Lauer. Decentralized Assignment of Names in Networks. Xerox Corporation. [ Lockhart 1979 ] T W Lockhart. The Design of a V e r i f i a b l e Operating System Kernel. University of B r i t i s h Columbia. Department of Computer Science. Technical Report 79-15, 1979. [ McGovern 1980 ] Joseph P McGovern. A Distributed Communications Architecture. IEEE Trends and Applications 1979. Gaithersburg May 17, 1979. [ McGovern and Basu 1980. ] Joseph P McGovern and Dipak Basu. Middle Layers of Open System Interconnection: Session and Transport. IEEE Compcon 80 F a l l . Washington Sept 23-25 1980. [ Moulton 1980 ] James Moulton. High Level Protocol Boundaries in the ISO Model. IEEE Trends and applications: Computer Network Protocols, 1980. [ Pouzin and Zimmermann 1978 ] Louis Pouzin and Hubert Zimmermann. A T u t o r i a l on Protocols. Proceedings of the IEEE. Nov 1978. 89 [ Schindler 1981 ] S Schindler. Open Systems, Today and Tomorrow - A Personal Perspective. Computer Networks. May 1981. [ Shoch 1978 ] John F shoch. Internetwork Naming, Addressing and Routing. IEEE Compcon 78 F a l l . Washington Sept 5-8 1978. [ Sproull and Cohen 1978 ] Robert F Sproull and Dan Cohen. High Level Protocols. Proceedings of the IEEE. Nov 1978. [ Steel 1980 ] Thomas B Steel. CCITT Perspectives on Higher Level Protocols. IEEE International Conference on Communications. Seattle June 8-12 1980. [ Tripathi et a l 1980 ] Anand R T r i p a t h i , Edwin T Upchurch. and James C Browne. An Overview of Research Directions in Distributed Processing. IEEE Compcon 80 F a l l . Washington Sept 23-25 1980. [ Walden and McKenzie 1979 ] David C Walden and Alexander A McKenzie. The Evolution of Host-to-host Protocol Technology. Computer. Sept 1979. [ Zimmermann 1980 ] Hubert Zimmermann. OSI Reference Model - The ISO Model of Architecture for Open Systems Interconnection. IEEE Transactions on Communications. A p r i l 1980. 90 Appendix A. Session Reconnection Sequence. The sequence of actions taken by the ITI server when performing the session reconnection i s given below and i l l u s t r a t e d in F i g . 12. The steps that follow the transport le v e l f a i l u r e may be broken up into the following four phases. 1. O r i g i n a l ITI server detects transport system f a i l u r e and blocks a l l user applications. (a) The ITI server is n o t i f i e d of an exception condition by the destruction of the timer process. The transport connection release status i s returned on the following X.25 read request. (b) Any.outstanding or additional application requests are blocked. Requesting applications must await ITI server reply. (c) The ITI server sends a suspension n o t i f i c a t i o n to the session server. The ITI server remains blocked u n t i l authorized to reconnect by the session server or a l o c a l timeout occurs. 2. Establish new transport connection and higher level services. V e r i f i c a t i o n of o r i g i n a l user and authorization to proceed with reconnection is performed by session server. (a) A new incoming c a l l i s received by the X.25 l e v e l . This causes the generation of new upper layers including ITI and login servers. (b) A login request is sent to the session server. The user is v e r i f i e d to be the same as that whose session was 91 suspended. (c) The suspended ITI server is returned the authorization to reconnect and w i l l await a reconnection request. (d) The session server re p l i e s to the login server to i n i t i a t e reconnection to the i d e n t i f i e d (suspended) ITI server. • (e) The login server requests the ITI server to reconnect to the suspended ITI server.This is a non-standard I/O request supported by the ITI server only. 3. Synchronization handshaking between ITI servers and transfer of connection ownership to the previously suspended session. (a) The 'new' ITI server sends a 'RECONNECT QUERY1 to the suspended ITI server. This i s necessary to establish that the suspended ITI server i s s t i l l a ctive. (b) The suspended ITI server r e p l i e s that the reconnection . may proceed. If the suspended ITI server is no longer active a 'RECONNECT UNSUCCESSFUL' reply i s returned to the login serve causing a new application session to be established. (c) The X.25 server i s requested to a l t e r the 'ownership' of the transport l e v e l connection to the previously suspended ITI server. (d) The X.25 server r e p l i e s to t h i s request. If successful reconnection continues. If unsuccessful a new application session i s established. (e) The suspended ITI server i s informed that i t now 'owns' the transport l e v e l connection. (f) The suspended ITI server n o t i f i e s the X.25 server of the break process that is to be destroyed for asynchronous 92 event n o t i f i c a t i o n . (g) The X.25 server replies to t h i s request. (h) The suspended ITI server r e p l i e s to the new ITI server that the reconnect is complete. 4. Reconnection reply status. If successful the now unused services are released. If unsuccessful another login service request i s made to the session server. (a) The login server i s given a reply indicating a successful reconnect. The login server and new ITI server are released. (b) The previously suspended ITI server r e p l i e s to any outstanding requests and accepts I/O requests using the new transport l e v e l connection. 93 Session server Application 1 (c) 1 (b) V 4(b) c) < — 3 ( a ) - - -3(b)—> .<—3(e) — 3 ( h ) — > 2(b) 2(d) V Login server 2(e) V 4(a) ITI server (new) A 3 c) 3(d) I V X.25 server A 2 U ) Figure 12 Session reconnection sequence. 

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}]}"
                            data-media="{[{embed.selectedMedia}]}"
                            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-0051824/manifest

Comment

Related Items