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.

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 . S c , Royal Melbourne I n s t i t u t e 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  We accept  Science  t h i s t h e s i s as conforming  to the r e q u i r e d standard  THE  UNIVERSITY OF BRITISH COLUMBIA December 1981  (c) G e o f f r e y R i c h a r d Scotton, 1981  In p r e s e n t i n g  this thesis i n partial  f u l f i l m e n t o f the  requirements f o r an advanced degree a t the U n i v e r s i t y o f B r i t i s h Columbia, I agree t h a t the L i b r a r y s h a l l make it  f r e e l y a v a i l a b l e f o r reference  and study.  I further  agree t h a t p e r m i s s i o n f o r e x t e n s i v e copying o f t h i s t h e s i s f o r s c h o l a r l y purposes may be granted by the head o f my department o r by h i s o r her r e p r e s e n t a t i v e s .  Iti s  understood t h a t c o p y i n g o r p u b l i c a t i o n o f t h i s t h e s i s f o r f i n a n c i a l gain  s h a l l n o t be allowed without my  permission.  Department o f  <j*!otvvpvo(-<2-r' Qc-ies\<2e-~  The U n i v e r s i t y o f B r i t i s h 2075 Wesbrook P l a c e Vancouver, Canada V6T 1W5 Date  \Uy/1-2-/Sri*  •  Columbia  written  Abstract.  High l e v e l communication system  design  is  of  increasing  i n t e r e s t as the i n t e r c o n n e c t i o n of computer systems becomes more widespread.  High  level  users/applications environment  with  that  a  communication convenient  virtual  for  file  a p p l i c a t i o n s . We software  transfer, v i r t u a l  d e s c r i b e the  support  e x i s t i n g X.25  protocol  using  an  experimental  other  the  communication  Interconnection  models,  model  described this based (c)  The after  I/O  user is  research  communication  computer  system  is  a l s o present a design that i s a  the  the  ISO  Xerox  initiation  Pup  achieved  Systems  internetwork  the f o l l o w i n g i s s u e s : from an incoming  i n t e r f a c e between  interface.  Open  Within  using  a  call.  protocol  the  layers  implementation  interprocess  message  protocol.  suspension a  communication  of a high l e v e l  notably  and  (b) U t i l i z a t i o n of a uniform the  of  model implemented and compare t h i s with  (a) Dynamic p r o t o c o l l a y e r  at  protocol  t e r m i n a l p r o t o c o l using an  a r c h i t e c t u r e . In p a r t i c u l a r we address  and  level  implementation.  implementation  of  high  implementation  d e s c r i b e d w i t h i n t h i s t h e s i s . We generalization  communication  t e r m i n a l and m a i l d e l i v e r y  f o r the ITI v i r t u a l  The design and system  provide  i s an a b s t r a c t i o n of the u n d e r l y i n g t r a n s p o r t  communication mechanism. Examples i n c l u d e support  , systems  of higher l a y e r s and a p p l i c a t i o n  transport  level i i  failure  and  the  processes subsequent  reconnection  The  when the t r a n s p o r t connection  design  utilizes  layered  communication  provide e x t e r n a l (high l e v e l ) p r o t o c o l support may  provide  local  services  t r a n s f o r m a t i o n and reconnection uniform  interface  allows the l i b e r a l  between  and  i s reestablished.  or  modules that alternatively  f u n c t i o n s such as l o c a l  f u n c t i o n s . The u t i l i z a t i o n  modules  i n t e r c o n n e c t i o n of  and  a t . t h e user  modules  to  data of  a  interface  provide  r e q u i r e d communication s e r v i c e s with a minimum of overhead.  the  Table  of Contents.  Abstract Table List  i i  of c o n t e n t s . .  iv  of f i g u r e s  vii  Acknowledgements. 1  2  viii  Introduction..  1  1.1  Objectives.  1 .2  Motivation  .  . . . .  5  High L e v e l P r o t o c o l s - an Overview 2.1  7  • Higher L e v e l P r o t o c o l s .  7  2.1.1  Topology Independence  2.1.2  Device Independence  2.1.3  Data Representation  2.2  The  2  8 11  Independence  Open System I n t e r c o n n e c t i o n  Architecture. .  14  2.2.1  ISO  2.2.2  Layered P r o t o c o l Design  18  2.2.3  The  18  2.3 2.3.1  OSI  P r o t o c o l Standards A c t i v i t i e s  12  OSI  Layer A r c h i t e c t u r e  14  Architecture Constraints  22  Layering  22  Constraints  iv  2.3.2 2.4 3  23  The Pup Internetwork A r c h i t e c t u r e .  A Verex Communication Model Implementation 3.1  25 .  The Server Model  29 29  3.1.1  The Verex System Servers  29  3.1.2  The Uniform Server I/O I n t e r f a c e  31  3.1.3  S t a t i c and Dynamic Servers  36  3.1.4  Reliability  37  3.2  and Dependency  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  4  OSI Model C o n s t r a i n t s  E r r o r Recovery  51  3.3.1  Session Recovery  3.3.2  Garbage C o l l e c t i o n and Resource Reclamation. 53  A Dyamic Communication System Design 4.1 4.1.1 4.2  A Modular System S t r u c t u r e P r o t o c o l Management and F i l t e r Modules. . . Transformation L e v e l F u n c t i o n a l i t y  v  51  56 56 57 60  4.2.1  A Uniform Communication  4.2.2  Data Transformation and Transparency. . . .  63  4.2.3  E r r o r Recovery and Session Management.. . .  64  4.2.4  B l o c k i n g and Segmentation  67  4.3  .  Transformation L e v e l Components.. .  60  69  4.3.1  Data T r a n s f o r m a t i o n Modules  70  4.3.2  Incoming C a l l Handler  72  4.3.3  The Session Manager  74  4.4 5  Module I n t e r f a c e .  Comparison  with OSI and Pup A r c h i t e c t u r e s . .  Conclusion.  . .  76 81  5.1  Conclusions  82  5.2  F u t u r e Research Areas  84  Bibliography. Appendix.A.  .  86  Session Reconnection.Sequence.  vi  90  L i s t o f Figures.  1  P r o t o c o l / i n t e r f a c e communication.. .  2  OSI l a y e r a r c h i t e c t u r e . . .  3  The Pup P r o t o c o l H i e r a r c h y .  [Boggs et a l 1980] . . . .  26  4  S e r v i c e requests  invocation  39  5  The ITI server design  42  6  X.25 c a l l  50  7  F u n c t i o n a l l e v e l s and s u b - l e v e l l a y e r s  56  8  Terminal  60  9  Multiple transport/application sessions.  and server  17 .  frame and r e s u l t i n g s e s s i o n server requests.  support  communication modules . . . . . . . .  21  65  10  C a l l establishment  phase.  70  11  A l t e r n a t e communication system c o n f i g u r a t i o n s  72  12  Session  93  reconnection  sequence  vii  Acknowledgements.  I  would  Cheriton,  like  who  to  sincerely  my  supervisor  David  was able to d i r e c t my work on t h i s t h e s i s when I  needed i t most. I  greatly  discussions  gave  proof  thank  that  appreciate  rise  reading the f i n a l d r a f t  Thanks  to  David  Cheriton,  Deering  f o r having the time  Steve  Deering  f o r the  to many p a r t s of t h i s t h e s i s , f o r and Pat  the  use  Boyle,  of  John  his  software.  Demco and Steve  to answer my q u e s t i o n s . I would a l s o  l i k e to thank Debbie K i n z e l and everyone from the o f f i c e ,  David  Booth,  their  Kathy  Lee, Marc  Majka  and  Wendy  encouragement. S p e c i a l thanks to Gerry Neufeld commenting on the f i n a l  draft.  vi i i  Moore  for  f o r reading  and  1 Chapter  1.  Introduction.  T h i s t h e s i s i s concerned with the design of a communication system framework for protocol  communication.  transport  s e r v i c e s provided  greater  functionality  communication system provides use  High  of high  level  lower the  structure  a f l e x i b l e host  supporting  level  protocols  high  level  protocols,  communication described  environment for the  adding  services.  within  this  thesis  implementation  and  describes  some  development higher  of  and  Pup  reviewed and  communication a r c h i t e c t u r e s  level  protocol  model  within  the  the  implementation of Verex-  communication model provides and  l i n k s high  request  to  [Boggs et a l 1980]  form the b a s i s for a comparison w i t h i n chapter  Chapter 3 d e s c r i b e s system  research  a connection  the  entities  (modules) to allow  components.  The  a flexible  ITI  virtual  time  existing  X.25  utilizing  an  transport  level.  We  include  protocol  initializes an  external  implementation. between  interconnection protocol  of system  implementation  concerned  only  layer  i s implemented  w i t h i n a l l lower l e v e l  ( t r a n s p o r t l e v e l ) those p r o t o c o l s  4.  Connectionless  interface  terminal  are  computer system. The-  i s received.  implementation u t i l i z e s a uniform  [ISO  communication  a system s t r u c t u r e that  l e v e l p r o t o c o l l a y e r s at  establish  a  p r o t o c o l s are not c u r r e n t l y supported w i t h i n the The  and  high  o r i e n t e d communication a r c h i t e c t u r e s . In p a r t i c u l a r the OSI 1981]  The  protocols.  Chapter 2 of t h i s t h e s i s reviews the level  implementation  l e v e l p r o t o c o l s enhance the data  by  to  and  as  the  protocols  with  moving  2  data between, endpoints. In terms of the OSI section  2.2)  this-  represents  the  r e f e r e n c e model (see  t r a n s p o r t p r o t o c o l and a l l  lower p r o t o c o l l a y e r s .  Chapter  4 g e n e r a l i z e s the implementation  and presents a more general design  communication  model of chapter 3  system  design.  The  d e f i n e s the high l e v e l communication support  i n terms of  the f u n c t i o n a l i t y of the component modules. P r o t o c o l  management  modules  and  interface  filter  provides  intermodule  modules a  are  uniform  interface  and  defined.  access the  s e c t i o n of chapter  method  1.1  objective  intersystem  operating  the  interface.  A  4.  system  implementation  f u t u r e areas of r e s e a r c h .  of t h i s work was  communication  system. The  to p r o v i d e a remote access  facility  implementation  within  c o n f i g u r e d dynamically by i n v o k i n g , i n i t i a l i z i n g  communication modules  at  the  time  the  Verex  utilizes a flexible  model that allows the s t r u c t u r e of the communication be  both  Object i v e s .  The and  for  module  and Pup models i s made i n  Chapter .5 reviews the communication and design and proposes  uniform  application  comparison of t h i s design with the OSI the f i n a l  A  a  connection  system  system and  linking  request  rece i v e d .  The  i s s u e s that are of concern  to  w i t h i n t h i s model a r e :  is  3  (a)  The  determination  of  incoming  call  requirements and. the  dynamic c o n f i g u r a t i o n of the communication  service  support  modules. (b)  The I/O  p r o v i s i o n of a uniform module i n t e r f a c e using p r o t o c o l that u t i l i z e s  interprocess  the  messages  local  for  I/O  requests. (c)  E r r o r recovery to be  functions  that allow  suspended when the t r a n s p o r t  r e a c t i v a t e d when the t r a n s p o r t  The high  is  not  l e v e l p r o t o c o l s , but  existing of  thesis  (and  additive  requirements. However  communication  and  then  is reestablished.  supported. The  the  restrictions  system  in  which  modularity  complete are  applied  in  layer  assumed  upon  model  is  c h a r a c t e r i z e d by  (b) V a r i a b l e number of p r o t o c o l l a y e r s . (c) Uniform l a y e r i n t e r f a c e .  (e) E x t e r n a l (f)  the  the model.  independence.  (d) U t i l i z a t i o n of dynamic  an  communication  following a t t r i b u t e s . (a) P r o t o c o l  new  p r o t o c o l s with a minimum of  be s e l e c t i v e l y  complexity of the p r o t o c o l s w i t h i n  The  be  favours  provide no  fails  in p r o v i d i n g an environment  so that these can to  system  connection  f u t u r e ) p r o t o c o l s can  manner  level applications  concerned with the development of  the communication design  functionality,  high  entities.  s t a t e dependent p r o t o c o l management modules.  I n t e r n a l s t a t e dependent f i l t e r modules.  the  4  The l a y e r attributes  independence  permit  the  and  the  uniform  layer  s t a c k i n g of communication  (almost) a r b i t r a r y manner. The uniform I/O  modules in an  i n t e r f a c e can be used  to p r o v i d e a p p l i c a t i o n s with a l o c a l p e r s p e c t i v e I/O  interface  for  non-local  o p e r a t i o n s . Only those a p p l i c a t i o n s or p r o t o c o l l a y e r s that  must s p e c i f i c a l l y  utilize  communication  dependent  facilities  need be aware of the d i f f e r e n c e between the l o c a l and remote services.  The  uniform  implementation  I/O  provides  interface  I/O  used  operations  within  using  I/O  the Verex  interprocess  messages.  The  objective  of  the  dynamic  system to respond to demand and communication (possibly  of  system  idle  processes.  gained  if  idle  process  the  predetermined, communication  reduce  resources Dynamic  overhead.  communication but  the  S t a t i c communication  minimal)  system with amount  modules.  structure  is  and  overhead  of  idle  modules consume some tend to c l u t t e r the  invocation  reduces  on  structure demand  is  based  communication  structure.  The  configuration  components i s determined by the c a l l i n g requirements,  a p p l i c a t i o n performance communication supported  in  not  requirements of an incoming c a l l .  many i n t e r c h a n g e a b l e components corresponding to each  application  be  upon the.  As w i t h i n the Pup internetwork a r c h i t e c t u r e there may  the  the  A d d i t i o n a l b e n e f i t s may  system  configured  i s to allow the  allows to  The  protocol the  resources  and  the  flexibility  of  the  standard  locally  of  upon  system  requirements.  structure addition  the  layer  of  system, based  exist  protocols  defined,  to  be  non-standard  5  protocols. .  1.2  Motivation.  The  primary  s t r u c t u r e was  motivation  for  developing the  to provide a simple communication  i s e a s i l y adaptable f o r a v a r i e t y research  system  the  simplicity  operating is  applications.  system designs and  system.  viewed  as  necessary path towards  The  environment  provided a v e r s a t i l e environment  a l t e r n a t i v e communication within  of  communication  a  that  The  Verex  for exploring  their  integration  As w i t h i n the P u p . a r c h i t e c t u r e ,  desirable  aim  in  itself  and  a  flexibility.  the  multilayered  communication  design such as the OSI a r c h i t e c t u r e  i s an imposing  task. The OSI  r e f e r e n c e model [ISO 1981]  trend  complexity  towards  of  highly  layered  r e f e r e n c e model represents a which  the communication  implementing  the  model  Within the OSI model topmost user  will  indicative  communication  design  framework  of  the  systems.  The  (model)  within  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 p r o t o c o l s above)  is  achieve  the .user  (at the s e s s i o n l a y e r  greater p h y s i c a l interface  is  and  realization.  defined  at  the  l a y e r only and thus by d e f i n i t i o n does not allow user or  defined  protocol  access  to  lower  l a y e r s where t h i s i s  desirable.  A g e n e r a l i z e d communication design  is  subject  to  system  based  upon  a  static  c o n f l i c t i n g c o n s t r a i n t s that a f f e c t 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  insufficient  6  generality  may  exclude  applications  requiring  performance requirements. Secondly the p r o v i s i o n  of  specific sufficient  g e n e r a l i t y w i t h i n a s t a t i c model i m p l i e s i n c r e a s e d complexity at each  level  performance  tradeoff.  A l t e r n a t i v e l y , a d y n a m i c a l l y s t r u c t u r e d communication  system may  a v o i d these service  and  some  problems  modules  by  degree  providing  of  only  those  that are r e q u i r e d to f u l f i l l  services  and  the communication  requirements of the a p p l i c a t i o n .  In  summary,  the  motivation  dynamically s t r u c t u r e d communication  for  the  of  a  system was t o :  (a) Reduce the complexity of the communication (b) Increase f l e x i b i l i t y  development  system as a whole.  by g r e a t e r use of m o d u l a r i t y .  (c) Decrease overhead bu u t i l i z i n g dynamic  structuring.  7  Chapter  2.1  2. High Level P r o t o c o l s - an Overview.  Higher  A  Level Protocols.  communication  system  l e v e l p r o t o c o l s provides the for  a l l levels  of  incorporating communication  intersystem  both  high and low  services  necessary  i n t e r a c t i o n . We d e f i n e a high  l e v e l p r o t o c o l as a p r o t o c o l that provides more than a means transparently A  high  exchanging b i t s or bytes between remote l o c a t i o n .  level  dependent)  protocol  services.  A  provides  higher  order  (application  high l e v e l p r o t o c o l p r o v i d e s  d e v i c e and data r e p r e s e n t a t i o n independence to the whilst  of  low l e v e l p r o t o c o l s p r o v i d e a user  topology,  application,  independent t r a n s p o r t  mechanism.  The  communication system must provide a means to e s t a b l i s h ,  maintain and terminate a These  services  are  conversation  provided  in  a  with form  a  remote  entity.  convenient  to the  a p p l i c a t i o n . The communication mechanism may be connection or c o n n e c t i o n l e s s at lower connections  levels.  (Possibly  providing  virtual  at higher l e v e l s . ) By a b s t r a c t i n g the communication  mechanism and p r o v i d i n g an environment that i s t a i l o r e d application,  the  high  communication  to the  high l e v e l p r o t o c o l provides a manageable and  v e r s a t i l e tool for d i s t r i b u t e d  The  based  level  protocol  environment  T h i s i m p l i e s that at l e a s t  system design and  provides  suitable  the  implementation.  user  f o r the given  with  a  application.  some p a r t of the communication  system  w i l l be a p p l i c a t i o n dependent. The a p p l i c a t i o n dependent part of  8  a high l e v e l communication system provides services,  whilst  services  by  many  nature  of  high  such  as  a  applications application also a  other high l e v e l p r o t o c o l s  required  dependent  requires  facility  Operations  upon  a  transport  In the  distributed  not  only  file,  the  file  i s apparent system.  a file  transport  files  on  such  as  do not r e q u i r e  the  file  application  Such  an  mechanism, but remote  creation,  transmission  in  system. renaming,  of the f i l e but  system. These o p e r a t i o n s  the high l e v e l p r o t o c o l  in  addition  to a  mechanism.  following  communication-  provide  The  protocols  basic o p e r a t i o n s upon a remote f i l e  are provided w i t h i n file  level  transformation  may provide general  applications.  f o r managing  querying and r e l e a s e are  data  sections  system  topological,  we d e s c r i b e  utilizes device  high and  the means by which  level  protocols  data  to  representation  abstract ions.  2.1.1  Topology Independence.  Many d i s t r i b u t e d a p p l i c a t i o n s , system  that  utilizes  a  virtual  such as a  l o c a t i o n s are not known  a p p l i c a t i o n . Within such a d i s t r i b u t e d a p p l i c a t i o n ,  identifiers  may  distributed  system.  mapping f u n c t i o n identifier address  be  used The  necessary  to  identify  communication to  file  f i l e p r o t o c o l , are based upon  d i s t r i b u t e d resources whose p h y s i c a l the  distributed  map  a  resources  by  logical  within  the  system may provide the locally  known  logical  i n t o a l o c a l or remote p h y s i c a l address. The p h y s i c a l  may  include  addressing  components  f o r the network,  9  system, port and resource i d e n t i f i e r or may be represented by  a  n o n - h i e r a r c h i c a l address.  Shoch  [Shoch  1978]  defines  a  name  as  identifying  p a r t i c u l a r e n t i t y , the address of which i d e n t i f i e s where  a  i t is  l o c a t e d and whose route i s the means of g e t t i n g to i t . Of these, both  names  and  addresses  p r o t o c o l s . Routing i s a protocols.  are  of  function  Hierarchical  and  concern  of  to  lower  higher  level  (transport)  non-hierarchical  (flat)  level  address  spaces can be used to represent the address domain. H i e r a r c h i c a l addresses are u s e f u l and  i n r o u t i n g as  they  contain  topographical  g e o g r a p h i c a l i n f o r m a t i o n w i t h i n the address. A f l a t  space  does  not  provide  any  topological  address  information  but  r e p r e s e n t s a m o r e . f l e x i b l e address base.  Name fix  and address p a i r s must at some time be bound so as to  (at l e a s t t e m p o r a r i l y )  binding  agent  [Abraham  the  and  relationship  Dalai  between  1980],  them.  A  i s able to map the  resource name to i t s address. Binding- agents may be  centralized  or  et a l 1980]  1  distributed.  The  Xerox  Pup  internet  u t i l i z e name s e r v e r s l o c a t e d throughout the  name  to  address  i d e n t i f i e d by socket  mapping. numbers  The  that  [Boggs  the i n t e r n e t to  perform  Pup s e r v i c e addresses are represent  generic,  service  points.  The  binding  of  names ' and  addresses may be performed at  v a r i o u s times over the network o p e r a t i o n . (a) S t a t i c b i n d i n g .  10  S t a t i c binding i s performed fixed  until  environment mapping (b) E a r l y  the  at  system  t h i s would  system  is  generation  regenerated.  soon r e s u l t  in  In  and i s  a  dynamic  out-of-date  address  functions.  binding.  Static  binding  i s performed when the system i s i n i t i a l i z e d  and remains f i x e d from that p o i n t onward. (c) Late b i n d i n g . Late b i n d i n g at runtime p r o v i d e s up-to-date address  mapping  but may r e q u i r e s i g n i f i c a n t overhead to be maintained.  By address  combining  early  is  to  found  binding  be  with  incorrect,  late  binding  dynamic  flexibility  p r o v i d e d with manageable overhead [Abraham and D a l a i  Whichever  addressing  mechanism  when an is  1980].  i s used w i t h i n a dynamic  environment, the addressed resource i s not always to be found at that l o c a t i o n . T h i s may be due to r e l o c a t i o n , reasons.  failure  or  other  A l t e r n a t i v e l y t h e address- may- have been- r e a l l o c a t e d ' to  a new resource. In both cases the i n c l u s i o n of the resource name w i t h i n the connection request would be h e l p f u l correcting  these  s i t u a t i o n s . Shoch  the address be used as a h i n t a l t e r n a t i v e s should  be  in detecting  and  [Shoch 1980] maintains that  i n l o c a t i n g the r e s o u r c e , but that  provided  i f the  resource  cannot  be  located.  The  independence  topology of d i s t r i b u t e d the  design,  of  the  systems  implementation  application resources  and  from greatly  portability  of  the p h y s i c a l facilitates distributed  11 applications.  2.1.2  Device Independence.  A high with  l e v e l communication system should  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  by  a b s t r a c t i o n are performed by high  both  local  and  device  abstraction  remote  application.)  of  device  virtual that  terminal  participants. by  second  (The  the  high  level  means  of  device  The  as - a p p l i e d  local  protocol  (VTP)  data  provided  by  by both the l o c a l  requires  a  VTP.  virtual  establishes  a  and  remote  that  is  Similarly  to  physical  may  utilize  a  some t r a n s f o r m a t i o n the  VTP/terminal  terminal  of that  interface  translation  viewpoint  of the a p p l i c a t i o n and the t e r m i n a l , the VTP  a standard  device  terminal to  and the l o c a l  the l o c a l  It i s a function local  system to transform  representation.  with local  u t i l i z e s the p h y s i c a l c h a r a c t e r i s t i c s of the t e r m i n a l . From  definition.  data  protocol  system a p p l i c a t i o n may work d i r e c t l y  structure the  terminal  the t e r m i n a l . T h i s data  ' v i r t u a l ' t e r m i n a l data s t r u c t u r e or  terminal  to  below.  i t views as r e p r e s e n t i n g  s t r u c t u r e i s recognized entities.  The  abstraction  communication are d e s c r i b e d  structure  i s provided  device  i n v o l v e s a parametric approach t o device management.  means  The  communication  abstraction  p r o t o c o l , not the  the  l e v e l p r o t o c o l s . The  of these r e q u i r e s the implementation of a ' v i r t u a l  virtual  Both  so  user device  first  communication  the  that  of device  independent  provide  that the  provides  to both the  the v i r t u a l  terminal  So long as the a p p l i c a t i o n i s able  12 to manipulate the v i r t u a l device protocol,  a  much  wider  variety  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 nor  the  remote  transformations  device  provided of-  by . the  devices,  be used. Neither  high  with the  level  markedly  application  need be e x p l i c i t l y aware of any  r e q u i r e d as these are provided by the  of  VTP  the data  transformation functions.  A  second  approach to p r o v i d i n g device independence w i t h i n  high l e v e l p r o t o c o l s i s to provide a parametric p r o t o c o l manager, manager  of  its  whereby own  the  entity  i n t e r f a c e to the  notifies  the  p h y s i c a l c h a r a c t e r i s t i c s . The  protocol  protocol  may  use t h i s i n f o r m a t i o n to transform exchanged data to the r e q u i r e d form. T h i s approach i s used w i t h i n and  X.29  Interface may  terminal  advantage the  disadvantage  of  known  or  of  parametric  the  complexity  Non-homogeniety i n data  software  Interactive  parametric  protocol  performance  grow,  that  X.28  Terminal handler  of a device  to  provides.  A  it  approach i s that the number of causing  greater  variety  and  participants  will  w i t h i n the p r o t o c o l .  Data Representation  result  the  recommendation  characteristics  service  parameters t y p i c a l l y w i l l  2.1.3  and  (ITI) [Datapac 1978].. A  take  improve  interface  CCITTs  amongst  communication  r e p r e s e n t a t i o n d i f f e r e n c e s at  levels.  transparent  Independence.  The  device  [Heafner  and  abstraction  Wood  hardware  and  l o c a l system data r e p r e s e n t a t i o n i s made  to a remote e n t i t y  virtual  the  1980]  in  much  is  provided.  have  the  identified  same  manner  Heafner three  and levels  that Wood of  13  difficulty (a)  The  in data t r a n s f o r m a t i o n , these are : transformation  of data c o n t a i n i n g u n s t r u c t u r e d  data types. T h i s i n c l u d e s other (b)  The  simple data  character,  numeric,  transformation'  included within t h i s The do  or  of data c o n t a i n i n g s t r u c t u r e d , p o i n t e r and  arrays  are  category.  t r a n s f o r m a t i o n of data c o n t a i n i n g s t r u c t u r e d types that  i n c l u d e p o i n t e r s . Data s t r u c t u r e s such as l i s t s and  include  pointers  implementation  Ideally  that  may  have  data  transformations  a p p l i e d to the transformed original  differing  trees  language  and  representations.  Isomorphic t r a n s f o r m a t i o n s allow an  its  boolean  types.  f r e e data. Data s t r u c t u r e s such as records  (c)  single,  form.  should  isomorphic.  inverse t r a n s f o r m a t i o n to be  data that would r e t u r n  Typically  be  this  is  the  data  to  not p o s s i b l e , as many  t r a n s f o r m a t i o n s have no unique inverse t r a n s f o r m a t i o n .  As  long  as the data semantics remain unchanged by the t r a n s f o r m a t i o n , i t is  not  necessary  that  the  data t r a n s f o r m a t i o n be  completely  isomorphic.  The errors  data t r a n s f o r m a t i o n may may  occur  introduce e r r o r s .  Range  for numeric data where d i f f e r e n t wordsizes  used. Type i n c o m p a t i b i l i t y and to  itself  another) are other  sources  format conversion of e r r o r .  (from one  are base  14  2.2 The Open System I n t e r c o n n e c t i o n  2.2.1  ISO P r o t o c o l Standards A c t i v i t i e s .  In  1976  the  e s t a b l i s h e d a new of  Architecture.  developing  [Hollis  International subcommittee  Standards  Organization  (ISO/TC97/SC16)  for  the  1980], [ S c h i n d l e r  what  has  been  1981]. T h e i r most  called  (OSI) a r c h i t e c t u r e . T h i s current  purpose  communication p r o t o c o l standards [Bachman 1978], significant  to date has been the development of a r e f e r e n c e model for  (ISO)  the 'Open Systems  ISO  action  was  in  result  [ISO  1981]  Interconnection' anticipation  of  and f u t u r e problems apparent i n i n t e r f a c i n g the growing  number of incompatible communication p r o t o c o l s .  Standardization  of high and low l e v e l p r o t o c o l s was seen as a means of p r o v i d i n g greater  interaction  between  otherwise incompatible systems and  networks.  The  extent  interactions  of  the  OSI  between  systems.  t e r m i n a l support, f i l e  transfer,  architecture Applications  encompasses such  model  does  not  exclude  p r o t o c o l s being used between efficiency  or  unstandardized  security. may  remote  remote job entry and e l e c t r o n i c  mail are a p p l i c a t i o n s f o r which standards are being The  as  all  the  considered.  p o s s i b i l i t y of non-standard  systems f o r reasons of convenience,  Non-standard  networks  that  remain  a l s o o f f e r member systems the f a c i l i t i e s of  the OSI environment by p r o v i d i n g a s i n g l e  (possibly  more)  OSI  composed  of  node, through which the OSI environment i s a c c e s s a b l e .  The  ISO  subcommittee  ISO/TC97/SC16  is  1  representing cooperation  bodies  from  nations  and  Standards  set of p r o t o c o l Institute  standards.  (ANSI)  is  The  committee,  ANSI/X3T5,  [ d e s J a r d i n s and White  to  investigate  1980],  Consultative  The  new  the  technical  OSI  International  Committee  American  proposal  Telegraph  matter.  The  CCITT  been  interest  [Steel  1980],  i n p r o t o c o l standards development  i n the area of lower l e v e l  circuit  to  study  has taken a s u p p o r t i v e p o s i t i o n and i s  a l s o proposing c o o p e r a t i o n with the ISO primary  and  (CCITT) has shown i n t e r e s t i n  t h i s area but has as yet not formed any working group the  urged  c u r r e n t l y working in  p a r a l l e l with the ISO and has l i k e w i s e c r e a t e d a  Telephone  has  with other standards o r g a n i z a t i o n s in an attempt to  e s t a b l i s h a worldwide National  interested  5  protocol  CCITT's  to date has  standards  where  the  s w i t c h i n g V s e r i e s p r o t o c o l s and the packet switching X  s e r i e s p r o t o c o l standards are i n widespread use.  Systems 'open'  in  supporting the OSI the  sense  that  c o o p e r a t i n g systems. The changed  from  architecture  to  plural  i n d i c a t i n g a r e v i s i o n of the i n i t i a l single  'system'  to  that  of  many  portion  be  physically  the  means  by  be  in  the  title  later  ISO  documents,  concept of an cooperating  has-  encompassing systems.  imply that  all  The OSI  connected, but that l o g i c a l connections  can be e s t a b l i s h e d between OSI specify  to  of  ' i n t e r c o n n e c t i o n ' term does not n e c e s s a r i l y systems  said  they are ( e l e c t i v e l y ) a v a i l a b l e to  'systems'  singular  are  which  systems. The OSI model the  data  is  to  does  not  be p h y s i c a l l y  t r a n s p o r t e d between systems.  The ISO r e f e r e n c e model [ISO 1981] d e f i n e s the framework of  16 the  OSI  architecture  themselves. facilities  The  but  model  does  is still  not  define  the  protocols  under review w h i l s t  additional  such as datagram and broadcast communication  are c o n s i d e r e d . Burkhardt and S c h i n d l e r 1981] by  the  interface points the  [Burkhardt and S c h i n d l e r  present an a l t e r n a t i v e p e r s p e c t i v e  defining  architecture  (cuts).that  possibility  of  on the OSI a r c h i t e c t u r e  i n terms of the i n t e r a c t i o n s and  e x i s t i n the  utilizing  both  model.  between  They  discuss  s t a t i c and dynamic system  e n t i t i e s to implement the model. The reference differentiate  support  model  does  not  the s t a t i c and dynamic system components  as t h i s i s implementation dependent.  The  reference  incorporating communicates  model  seven with  a  remotely  located  vertical  functional  The  independent  protocol  that  layer  and  layered each  layers.  the  means  interact  and  design  of  which  Each  layer  by  which the  also  f o r higher l a y e r s . The  provide reference  as h o r i z o n t a l communication between one  another  equivalent  entity  at  the  same  i n t e r a c t i o n between an (n) l a y e r e n t i t y and a (n-1)  layer e n t i t y i s defined applied  (remote)  entities  a  layers  provides  support  a protocol  (n) l a y e r e n t i t y and level.  adopted  equivalent  supports  model d e f i n e s  has  as an i n t e r f a c e . These  definitions  to the design and implementation d e s c r i b e d  are  i n chapters 3  4.  The reference  nature  interface  is  not  model as t h i s r e l a t i o n s h i p  is  locally  between  layers  interface/protocol below i n F i g 1.  of  the  interactions  specified  by the  defined. are  The  depicted  1 7  layer  (n) e n t i t y  <  PROTOCOL  >  layer  INTERFACE  INTERFACE  V  V  layer  (n-1) entity  <  PROTOCOL  >  layer  System A. Figure The the  set  1  (n-1) e n t i t y  System B, Protocol/interface  communication.  a t t r i b u t e s of an (n) l a y e r p r o t o c o l of s e r v i c e s  An (n) l a y e r p r o t o c o l by  (n) e n t i t y  that  may be  i t p r o v i d e s to the next higher  i s dependent only on the s e r v i c e s  lower l a y e r s . Any (n) l a y e r p r o t o c o l  support i s p r o v i d e d to the higher  allow  by  layer.  provided  may be replaced  a f f e c t i n g the other l a y e r s , as long as the e q u i v a l e n t  To  defined  without functional  layer.  (n) l a y e r e n t i t i e s to communicate, two t h i n g s are  required: (a) Each n l a y e r e n t i t y supports the same (or a of the same) (n) l a y e r (b)  The  (n-1)  layer  subset  protocol.  e n t i t y provide the s e r v i c e s  allow the t r a n s p o r t a t i o n information.  working  of  (n)  layer  data  necessary to and  control  18  2.2.2 Layered P r o t o c o l  Design.  A l a y e r e d p r o t o c o l design large  complex  simpler then  protocol  to  reduces the problem of managing a the task of managing many  p a r t s . The development and v e r i f i c a t i o n  becomes  an  easier  task.  of  smaller,  each  layer  Because of the independence of  l a y e r e d modules, system c o r r e c t n e s s  can be shown i n d u c t i v e l y  by  showing each l a y e r c o r r e c t .  The evolving  layered  framework  communication  requirements  of  a  permits  system  protocol  in  may  l a y e r e d a r c h i t e c t u r e the p r o p o r t i o n changed  is  reduced  specifications should  reflect  modifications  when  are modified.  simple  maintenance of an  which  change  the  over  a  time. Within a  of the software that must be  implementation  or  protocol  The implementation of the p r o t o c o l  the s t r u c t u r e of the p r o t o c o l , so of  functional  single  layer  may  be  that  protocol  constrained  to  implementation a l t e r a t i o n s w i t h i n a s i n g l e l a y e r e n t i t y .  A disadvantage of l a y e r e d p r o t o c o l s functions  may  be  necessary at higher  i s that d u p l i c a t i o n  l e v e l s when the s e r v i c e s  r e q u i r e d by an (n) l a y e r e n t i t y are inadequately (n-1)  layer e n t i t y . .  2.2.3  The OSI Layer A r c h i t e c t u r e .  The  reference  model  defines  a r c h i t e c t u r e . The s e r v i c e s provided is  briefly  of  provided  by  an  seven l a y e r s w i t h i n the OSI by each of the seven  layers  summarized below. More d e t a i l e d d e s c r i p t i o n s of the  19  f u n c t i o n a l i t y of each l a y e r can be found model i t s e l f  within  the  reference  [ISO 1981]. .-  (1) A p p l i c a t i o n Layer. The  application  layer  provides  the  ( a p p l i c a t i o n ) with the access p o i n t to the OSI It  i s at  this  level  end  user  environment.  that a l l user s e r v i c e s are provided  (although some may not be implemented at t h i s node management tasks a l s o r e s i d e at t h i s  layer).  Some  level.  (2) P r e s e n t a t i o n Layer. . The  presentation  standard  format  layer  i s r e s p o n s i b l e f o r transforming  data to or from a l o c a l  format  that i s used  by the a p p l i c a t i o n . The t r a n s f o r m a t i o n should leave the data semantically  equivalent.  Data  transformations  may  be  r e q u i r e d f o r t e x t , numeric data,, command, data s t r u c t u r e s or any  other' form, of data that the a p p l i c a t i o n r e q u i r e s .  (3) Session  Layer.  The  session  presentation  layer  layers  i s responsible for  the  f o r binding  duration  of  a  two  session.  A d d i t i o n a l s e r v i c e s may provide- a p p l i c a t i o n  dependent  integrity  mapping between  and  security.  S e s s i o n a l address  l o g i c a l and p h y s i c a l addresses layer  so  that  The  the  session  (topologically  independent).  Layer.  t r a n s p o r t l a y e r p r o v i d e s an  communication messages  by  resources are made a v a i l a b l e independent of  their physical location (4) Transport  i s provided  data*  channel.  i s assured  communication  Data despite  error  delivery an  free  end-to-end  and flow c o n t r o l of  underlying  error-prone  mechanism. End-to-end acknowledge ensures the  f i n a l d e l i v e r y of data at the remote  endpoint.  20  (5) Network Layer . The  network l a y e r manages network dependent  routing  and flow c o n t r o l . A l s o i t provides a v i r t u a l  between two endpoints detection  over a s u p p l i e d  data  link  layer  e s t a b l i s h i n g a connection over  correction  The across within  The services  this  provides  a  basic  between endpoints  and  connection.  i s performed by t h i s  Some  error  means  of  exchanging  detection  and  layer.  Layer. physical  l a y e r performs the p h y s i c a l  the medium. this  electrical,  data  interface  transfer i s defined  layer.  protocol to  The  the  l a y e r s are designed layer  above.  so  Each peer  s e r v i c e s and enhances them by adding protocol  c o n n e c t i o n . Some e r r o r  Layer.  The  (7) P h y s i c a l  circuit  and c o r r e c t i o n may be p r o v i d e d .  (6) Data Link  data  addressing,  that  each  provides  layer u t i l i z e s  these  i t s own s e r v i c e s . The seven  l a y e r s are i l l u s t r a t e d below- i n Fi;g* 2.  21  Application layer  Application  Presentat ion layer .  Presentat ion  Session  Session  layer  Transport layer  Transport layer  Network  Link  Network  layer  layer  Physical  <  layer  <  >  Network  <  >  Link  <  >  Physical  Intermediate node. OS I  OSI  reference  that  layer  layer  layer  System  B.  l a y e r a<rohi f e a t u r e .  :  must be  services provided within (a) Connection (b) Data  layer  layer  Physical  layer  Figure 2  functions  Link  >  System A.  The  layer  model supplied the OSI  specifies  many  services  by a communication system. model  and The  include:  establishment/release.  transfer.  (c) C o n t r o l  data  (d) A p p l i c a t i o n  transfer. dependent  services.  Functions performed by a given system e n t i t y  are  not  the  22 result  of  any  specific  request,  but are a c t i o n s taken in the  p r o v i s i o n of requested s e r v i c e s . The  OSI  model  includes  such  f u n c t i o n s as: (a  Data  transformation.  (b  Error  detection/correction,  (c  Mult i p l e x i n g .  (d  Multilevel  (e  Parameter  (f  Segmenting/blocking.  (g  Flow C o n t r o l .  (h  Sequenc i n g .  addressing. negotiation.  ( i Routing.  2.3 OSI A r c h i t e c t u r e  2.3.1  Layering  The  Constraints.  Constraints.  l a y e r e d nature of the model adopted by the ISO f o r the  OSI reference  model has s e v e r a l c o n s t r a i n i n g  the model design,  f a c t o r s that  affect  implementation and performance.  (a) F u n c t i o n a l d u p l i c a t i o n . The s e r v i c e s provided reference  model  may  by a subordinate l a y e r w i t h i n  prove  to  be  inadequate f o r a given  s i t u a t i o n . The f u n c t i o n a l i t y must then be higher  layer.  An  example  of t h i s  within  the  session  provided  by  the  i s that flow c o n t r o l i s  g e n e r a l l y only a p p l i e d at the t r a n s p o r t provided  the  layer  l e v e l , yet level  if  must  be  downward  23 multiplexing  i s provided  by that l a y e r . S i m i l a r l y upward and  downward m u l t i p l e x i n g  f u n c t i o n s at the session  sequencing operations  to be  provided  performed,  layer  despite  require  sequencing  by lower l a y e r s .  (b) Increased  overhead.  Each  successive  l a y e r adds more c o n t r o l information to  the a p p l i c a t i o n data being  exchanged, thereby i n c r e a s i n g the  c o n t r o l data overhead. One study of the ARPANET  [Pouzin  Zimmermann  1978]  cent  of the  transmitted  b i t s were made up  This  figure  excludes  showed  internal  that  only of  network  24  user  per data.  traffic  and  represents  and  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 i s necessary. (c) B u f f e r i n g  requirements.  Protocol  l a y e r e n t i t i e s can only be ensured to be  independent this, and  i f no  common  data  independent l a y e r e n t i t i e s  instances  used  in  i s shared. As a r e s u l t of require  multiple  buffers  of the- same message. A- r e l a x a t i o n of the l a y e r  independence c r i t e r i a allows is  truly  Squire  data to be shared. Data  [Chesley  and  Hunt  1981]  sharing  to  reduce  b u f f e r i n g requirements and data movement.  2.3.2 OSI Model  The  OSI  Constraints.  model  implementation. previous nature  The  s e c t i o n apply of  the  poses  many  layering to the  problems  for  constraints model  due  design  mentioned  to  model. Other problems inherent  the  and  i n the  multilayered  i n the OSI model  24  are  d e s c r i b e d here.  (a)  Model complexity. The OSI model system  is  framework.  a  large  The  models  system may  simple  may  a significant  communication  systems,  implemented  i n t e r a c t with other  communication  task.  The  f i x e d overhead f o r even  requirements.  Less  unable to support or implement  generality  flexibility  relatively  sophisticated  because  the complete OSI  they  performance  to  of  meet  the  the  OSI  demands  model of  a  criteria  that  are  allows wide  difficult  g e n e r a l i z e d system. Such a p p l i c a t i o n s may implement  non-standard  p r o t o c o l frameworks be met  it  the  variety  of  The  find  it  requirements  and  cannot  environment.  functionality.  OSI model d e f i n e s seven l a y e r s w i t h i n the model and  services  functional  and  boundary  functions i s not a l w a y s  that clear,  the t r a n s f o r m a t i o n / a p p l i c a t i o n l a y e r  [Moulton  necessary  protocols  attempts to d e f i n e the boundaries between them  of  specific  to meet w i t h i n a  communication  i f the a p p l i c a t i o n  w i t h i n the OSI  Ambiguous l a y e r  the  are  model.  a p p l i c a t i o n s . However s p e c i f i c a p p l i c a t i o n s r e q u i r e  (c)  model  generality.  The  to  OSI  ( i e small systems without the necessary resources)  be excluded from the OSI environment  (b) Model  communication  complexity i s then not r e l a t e d to the  complexity of the r e q u i r e d represents  complex  I t r e q u i r e s each l a y e r to be  before the communication systems.  and  1980]  defines  the  each  by  defining  performs.  notably  The  i n the case  interface.  Moulton  t r a n s f o r m a t i o n l e v e l as being  25 concerned with data  syntax  whereas the a p p l i c a t i o n l a y e r  being concerned with the data  2.4 The Pup Internetwork  The  Pup  developed  semantics.  Architecture.  (PARC U n i v e r s a l Packet) internetwork a r c h i t e c t u r e  at  alternative  Xerox  PARC  layered  [Boggs  protocol  et  al  design  1980],  for  viewed  a  and f l e x i b i l i t y means  of  whilst  performance  reducing  by  at  flexibility the  the  dissimilar  process  i s transparent  The shown  networks.  same  on the b a s i s  for  time  processing  dependent e n c a p s u l a t i o n techniques over  in  providing  Network  a r e used to t r a n s p o r t  The  high  packets  encapsulation/decapsulation  to the user.  Fig- 3.  t r a n s p o r t mechanism.  of  intersystem  overhead.  Pup design c o n s i s t s of four b a s i c l e v e l s  below  an  of o p e r a t i o n . P r o t o c o l s i m p l i c i t y i s  providing  communication,  provides  intra/internetwork  communication. The Pup a r c h i t e c t u r e i s designed simplicity  as  (0  to  3)  as  L e v e l s 0 and' 1 provide a Inter net work-  Levels  2  and  3  provide  host  to  host  26 intersystem  communication  protocols  Level 3  Woodstock  Telnet  Document printing  Data, structure and process i n t e r a c t ion conventions.  Level  EFTP  BSP  RTP  2,  Interprocess communication primitives.  WFS  Levels Internetworking  Datagram  (Pup)  Internetwork packet format.  Level Ethernet  Figure The support  Arpanet  3  The  Pup  higher both  performance  Protocol Hierarchy. protocols  connection-based  Connection-based for  Connectionless  Packet radio  leased 1 ines  level  protocols high  volume  protocols  oriented applications.  provide data  0.  Packet transport mechanism.  [Boggs et a l  that  and  1.  1980]  make up l e v e l s 2 and  connectionless greater  are used to support  protocols.  reliability  transport  3  and  applications.  query/transaction  27  The  l e v e l 2 communication  p r o t o c o l may  be made based upon the a p p l i c a t i o n , host  communication application  criteria.  protocols that  other  times.  The  o p e r a t i o n s that may for  node  provided  the  under some c o n d i t i o n s and  BSP  by  a  (Byte  provides  be used as a  file  Stream  very  transfer  facility  Protocol)  basic  bootstrap  i n i t i a l i z a t i o n whereas the BSP  s o p h i s t i c a t d data t r a n s f e r  resources  EFTP (Easy F i l e T r a n s f e r P r o t o c o l )  the  EFTP  choice of l e v e l 2  An example of a l t e r n a t e i n t e r s y s t e m  is  uses  The  alternative  data  performance  techniques.  provide  intersystem  and  transfer  primitives  file  and  at  transfer  down-line-load  p r o v i d e s a f a s t e r more  (with s i g n i f i c a n t  additional  resource demands).  The RTP application and  (Rendezvous support  Protocol)  provides  f o r a d d r e s s i n g w e l l known socket  addresses  requesting a p a r t i c u l a r  by the socket address,  but  and  Termination  service.  (The s e r v i c e i s represented  i s not n e c e s s a r i l y  addressed  entity.)  server and  r e t u r n a unique connection'* i d e n t i f i e r  the new with  Once addressed,  provided  s e r v e r . The RTP  the  means  s e r v i c e support  of  entity  the e n t i t y may  then  interaction  provides  with  i s provided by the RTP  in  Unlike to  s e r v e r . Dynamic  to be  f e a t u r e for dynamic p r o t o c o l s t r u c t u r i n g  chapters 3 and  provide  4 of t h i s  the OSI many  new  application  is  socket  met  r a t h e r than being e s t a b l i s h e d in a predetermined  A similar  the  that represents  and each addressed  s e r v e r , a l l o w i n g the communication requirements demand  invoke a  the  the new  by  upon  manner.  described  thesis.  model, the Pup dedicated  networking  protocol  model i s designed  services  at  the  28 sub-application end  oriented  l e v e l . The  acknowledgment, s i m i l a r to the OSI  p r o v i d e s a v a r i e t y of dedicated advantage  of  level  2 p r o v i d e s end  transport  protocols  t a i l o r e d 'transport'  performance. The may  Pup  at  l e v e l , but  this  also  level.  s e r v i c e i s that of  disadvantage i s that very many  to  The  increased  such  protocols  result.  The  Pup  a r c h i t e c t u r e a l l o w s great  host i n t e r a c t i o n s due  to the  communication s t r u c t u r e . The system  can  is  importance and accordingly.  required, the  a  the  communication  of  application.. simplicity  services  can  to the  communication  s o p h i s t i c a t i o n , resource  given  protocol  for host  f l e x i b l e nature  s o p h i s t i c a t i o n of the  be adapted to s u i t  performance requirements of performance  simple and  flexibility  Where  is be  and high  of primary allocated  29 Chapter 3. A Verex Communication  3.1  Model  Implementation.  The Server Model.  3.1.1  The Verex System  Servers.  The Verex o p e r a t i n g system [Lockhart the  Thoth  multiprocess message-based  1981] has i t s b a s i s i n  operating  system  [Cheriton  1979].  Verex  operating  system  providing  kernel  support  interprocess  communication.  Multiple  spaces are provided so than many processes can address  space to form a team. System  request by system teams ( s e r v e r s ) operations.  System  or  is  for  address  share  a  single  s e r v i c e s are p r o v i d e d upon alternatively  by  kernel  s e r v e r s remain i n an i d l e s t a t e u n t i l  their  s e r v i c e s are requested by a user. The . communication  system  implemented  both  following  this  server  t r a n s f o r m a t i o n and t r a n s p o r t l e v e l s . l e v e l s may  The  itself  message  design Each  blocked  within  layer  within  passing  primitives  supported  can  or  await  may  non-selective  following  a  events.  message.SEND u n t i l  Verex,  communication.  A  Verex process  the addressed receiving  block awaiting a message from a p a r t i c u l a r process a  message  RECEIVE).  from The  any  SEND,  process RECEIVE  p r i m i t i v e s , although not the only message within  the these  within  process r e p l i e s to the sending p r o c e s s . S i m i l a r l y the process  is  form a server f o r one or more u s e r s .  r e q u i r e processes to block awaiting message remains  a  form  the  basis  for  most  (selective  and  and REPLY message  primitives  supported  of the i n t e r p r o c e s s  30  The b l o c k i n g nature of the message p r i m i t i v e s w i t h i n gives  r i s e to the server model of system  than the  message,  process  and  system  s e r v i c e support. Other  device  provided w i t h i n the k e r n e l , most system  Verex  management  operations  s e r v i c e s are provided by  s e r v e r s . System s e r v i c e s are requested using i n t e r p r o c e s s  message requests made d i r e c t l y to the a p p r o p r i a t e system s e r v e r . I/O  services  protocol  are  requested of I/O s e r v e r s using a uniform I/O  [ C h e r i t o n 1981 ] that  does  not  differentiate  between  device types.  A  team  of  processes  use the same address  space,  thereby  a l l o w i n g data to be shared between processes but not across team boundaries. Data same  s h a r i n g between  server  processes  team i n c r e a s e s the interdependence  reduces' the overhead  within  the  of these processes, but  that would otherwise be i n c u r r e d i n  moving  and d u p l i c a t i n g data. The three X.25 p r o t o c o l l a y e r s of the X.25 server  [Deering  1 9 8 1 ] occupy  the  same  team and reduce data  movement between l a y e r s by a l l o w i n g shared data level  protocol  servers  access.  Higher  do not allow data s h a r i n g as c u r r e n t l y  these  ( i f more than one) are implemented as separate teams. A l l  data  must  be moved i n t o the team's address space before i t may  be accessed.  The section  server model p r o v i d e s a uniform means 3.1.2)  to  the  communication  message-based I/O p r o t o c o l . Due to the passing remains  primitives  provided  by  services  nature  Verex,  of  of  access using the  (see the  message  the r e q u e s t i n g process  blocked u n t i l the server r e p l i e s . T h i s allows the server  two courses of a c t i o n  i n p r o v i d i n g the requested s e r v i c e .  These  31 are: (a)  Reply  to  the r e q u e s t i n g process only when the request has  been f u l l y (b) Reply  immediately  request later  The  completed.  so  to  the  blocked  process  and  queue  that the requested a c t i o n may be performed  the at a  time.  former  approach (a) allows the server s t r i c t c o n t r o l of  the r a t e that s e r v i c e processes.  Read  requests  requests  are  f u l l y s a t i s f i e d . The second process  greater  are  accepted  generally  from  r e p l i e d to only when  approach (b) allows  latitude  in  individual  operation,  the  with  consequence of swamping the server i f s e r v i c e  requesting  the p o s s i b l e  requests  can  be  generated  f a s t e r than they can be f u l f i l l e d . Write requests may  be handled  i n such a manner. The  choice  of  approach  used  in  r e p l y i n g to s e r v i c e requests i s dependent upon the nature of the application,  the  type  of  request,  the  queueing  facilities  a v a i l a b l e and l o c a l system bounds (such as memory s i z e ) .  3.1.2 The Uniform  Server I/O I n t e r f a c e .  Within Verex message-based  processes  I/O  protocol  allows any process to perform supporting  the  I/O  request  I/O  [Cheriton  operations  1981].  the f u n c t i o n of an I/O  protocol.  User  request,  and the f i l e  a  I/O model server  by  I/O requests are made by a  message SEND to the I/O server with i n f o r m a t i o n I/O  This  using  containing  the  i d e n t i f i e r . B u f f e r i n g and data l e n g t h  i n f o r m a t i o n are i n c l u d e d w i t h i n the request message f o r read and  32  w r i t e o p e r a t i o n s . The uniform t o be provided server type  the  I/O  services  c o n s i s t e n t l y by a l l . I/O s e r v e r s . The user and I/O  interface  i s well  d e f i n e d and independent of the f i l e  characteristics.  Communication as  I/O p r o t o c o l allows  local  I/O s e r v i c e s are provided  I/O o p e r a t i o n s . A uniform  communication  communication  system  system  communication  system  i n t e r f a c e between  between  within  given  represents  (file  (b) Release  the  of  t h i s request  instance)  instance  request.  The  the  the  with  file  I/O  the  instance  server.  to an e x i s t i n g  i s discussed  The  communication  below..  instance.  The r e l e a s e instance request the f i l e  r e l e a s e s resources  instance and i n v a l i d a t e s the  there  example  i s concurrent  is  generally  terminal s u p p o r t  explicit  user  problem,  request, -as  used  where  identifier. instance, for  the instance  i s r e c e i v e d from  undesirable  committed to  instance  use of a s i n g l e f i l e  a communication connection,  when a r e l e a s e request  this  file  the object implemented by  applicability  remote  within  instance.  attributes  This  users and  used i n the I/O p r o t o c o l a r e :  c r e a t e s a. new  When  layers  basis  f a c i l i t a t e s the i n t e r c h a n g e a b i l i t y of the  The c r e a t e request  link  same  components.  The I/O requests (a) Create  and  on the  any  i s released  user  for applications  disconnection,  other  process. such as than  by  i s not t o l e r a t e d . The r e s o l u t i o n of within  the  communication  model  33  implementation (c)  i s d i s c u s s e d below.  Read i n s t a n c e . Read the s p e c i f i e d amount of data from the f i l e return  instance and  i t to the r e q u e s t i n g p r o c e s s .  (d) Write i n s t a n c e . Write the s p e c i f i e d data to the given f i l e  instance.  (e) Query i n s t a n c e . Return i n f o r m a t i o n concerning the given f i l e  instance to the  requesting process. (f)  Set i n s t a n c e owner. Indicate  to  the  server  which  instance.  (The absence of an owner process i s the b a s i s upon  which non-released communication  process  'owns'  the  file  l i n k s are c l e a r e d . )  (g) Set break process. T h i s request  i n d i c a t e s that the s p e c i f i e d process  destroyed  on  the  exceptional  event.  D i f f i c u l t i e s arises  receipt  in  the  of  an  is  interrupt  concurrent  use  of  to  or  other  a  single  communication connection. U n l i k e the f i l e  system that may  a  create  instance  same  physical  new  file  instance  on  communication  system  uses  communication  link)  access manifests release  instance  for  each the each  i t s e l f when any that  be  create  request, the file  (the  user. The problem of concurrent user  application  r e l e a s e s the communication  performs link  a  for a l l  other u s e r s .  on  One  solution  each  user's  i s to perform  sufficient  permission  checking  r e l e a s e request. F i n d i n g permission c o n d i t i o n s  34  that are s u f f i c i e n t l y Permitting  processes  authorised users  flexible  'super  but  belonging  user')  does  i s not n e c e s s a r i l y an easy to  the the owner user  eliminates  interference  not p r o t e c t the remote user  causing the connection  a l l o w i n g r e l e a s e requests from the f i l e is  (and an  from  other  from i n a d v e r t e n t l y  r e l e a s e . ( R e d i r e c t i n g output  own t e r m i n a l would r e l e a s e the connection.)  task.  On  to the users  the  other  hand  i n s t a n c e ' s owner process  p r o v i d e s adequate connection p r o t e c t i o n but i s u n n e c e s s a r i l y  restrictive.  An a l t e r n a t i v e s o l u t i o n used w i t h i n Terminal  Interface)  secondary  file  identifiers  instance.  The  the  physical  same  processes.  primary  to  server identify  and secondary  file  Seperate  identifying secondary  protocol  and  file  are  Both  utilizes a  file  identifiers  file  The process  secondary on  provide  a  file  r e f e r to by  user  means  of  a p p l i c a t i o n from those  of  requests  (such  file  as- read-  i d i s accepted  file  identifier  i s returned to the r e q u e s t i n g  c r e a t e instance and query instance requests that do  file  file  identifiers  q u e r i e s addressed  i d e n t i f i e r with  associated  to the name s e r v e r .  server  the  request.  are a l s o returned on f i l e  allows o b j e c t s to be i d e n t i f i e d the  communication  and  (such as the r e l e a s e r e q u e s t ) .  not provide the primary secondary  primary  identifiers  and w r i t e r e q u e s t s ) , w h i l s t only the primary requests  (Interactive  i d e n t i f i e r s are recognized by the  communication s e r v e r s f o r n o n - c r i t i c a l  for c r i t i c a l  ITI  indistinguishable  requests from a 'primary' users.  the  and  (The Verex  The  identifier  name  server  by name and - i f known - to have  file  identifier  returned on query  35  requests.) The original  primary  owner  (and  i n f o r m a t i o n to) and critical the  service  only  file  identifier  any  process  represents requests.  process  given  p r o v i s i o n of connection  by  the  that i t chooses to send  this  the  is  known  authority  As the o r i g i n a l  the  primary  for  performing  'owner' process i s  file  s e c u r i t y without  only  identifier,  the  i n t e r f e r e n c e from  other  users i s the r e s p o n s i b i l i t y of the owner a p p l i c a t i o n .  T h i s approach i s c o n s i s t e n t with the h a n d l i n g of f i l e s when a  unique  file  request. The servers  In  I/O  is  file  provided  on each c r e a t e i n s t a n c e  i d e n t i f i e r allows the  d i f f e r e n c e s between l o c a l and  addition  to  the  standard  Non-standard provided  server  remote I/O  I/O  requests that are supported  services  communication  i t s s e r v i c e s i n a manner i d e n t i c a l to other  s e r v e r s . In a c h i e v i n g t h i s the ITI  non-standard entities.  secondary  to manifest  system I/O apparent  instance  some  requests are necessary by  operations.  requests, by  there  are  communication  for  the*- communication  eliminate  non-standard  servers'i  These,  include: (a) C o n t r o l request. The  c o n t r o l request  of  the  i s used to change the mode of o p e r a t i o n  communication  non-transparent  entity.  (eg.  Transparent  to  o p e r a t i o n mode.)  (b) C o n t r o l query. Query  the  information,  specified  file  instance for f i l e  ( i e . For communication  providing c a l l  o r i g i n address,  file  facilities  type dependent  types t h i s i n c l u d e s requested  etc.)  36 The in  ITI server/X.25 server  i n t e r f a c e uses the I/O  protocol  a non-standard manner by appending an a d d i t i o n a l byte to the  user data that  i s i n t e r p r e t e d by the X.25 server as c o n t r o l data  for s e t t i n g the Q and M c o n t r o l  bits  within  the  X.25  packet  l e v e l header. T h i s i s a r e s u l t of the interdependence of the ITI protocol  upon  the  underlying  X.25 p r o t o c o l . The non-standard  nature of t h i s  i n t e r f a c e precludes  the  I/O  standard  protocol  to  most a p p l i c a t i o n s from  using  d i r e c t l y access the X.25 l e v e l  services.  3.1.3 S t a t i c and Dynamic  We d e f i n e execute  at  static  Servers.  server processes as those  a l l times  whilst  servers are c r e a t e d when t h e i r subsequently  released  services no  communication s t r u c t u r e uses both  The  choice  are  longer static  required needed.  and  and are The  dynamic  Verex service  l e v e l s e r v i c e support.  between p r o v i d i n g  based upon the f o l l o w i n g  that  t h e . system i s running. Dynamic  when  e n t i t i e s to implement higher  processes  s t a t i c or dynamic s e r v e r s i s  considerations:  (a) The frequency of i n v o c a t i o n . A server w i l l not b e n e f i t from dynamic i n v o c a t i o n is  required  sufficiently of  on  a  very  infrequent  these t r a n s f o r m a t i o n  frequent  b a s i s . Incoming c a l l s are  events that the servers  dynamic  of s e r v i c e and s t a t e  invocation  f r e e s system resources  would be committed but otherwise be unused. (b) The d u r a t i o n  if it  information.  that  37  When a server must provide times  and  must  users a s t a t i c  maintain model  by  the  may  be r e l e a s e d during  to  users,  s t a t e information  serves  r e q u i r e d over a f i x e d call  services  If  all  f o r a number of services  are  d u r a t i o n of time, bounded in t h i s  case  establishment  best.  at  and.the c a l l  the  idle  the  r e l e a s e , the  server  times,  (c) V a r i a b l e number s e r v e r s . Providing equivalent requires  services  many  growing numbers of s e r v e r s  differing  i f these are  maintained. Dynamic s e r v e r s respond to demand  statically  as  they  c r e a t e d only as r e q u i r e d . Subsequently they do not additional each  The  overhead  when  dynamic  server processes redundant  creation  thereby  server p r o c e s s e s .  The  level  reliability if  s e r v e r s can s e r v i c e s and requires  the  automatic  their  cleanup  the model with The  servers  dynamic  of  unused  ITI  are  flexibility  server,  without  and  other  c r e a t e d upon demand so that  for i d l e l o g i c a l  channels.  Dependency.  of the communication system in  communication  be v e r i f i e d . reliability  services.  allows  communication system i s made up of dynamic  modules.  R e l i a b i l i t y and  servers  providing  unused s e r v e r s do not e x i s t  enhanced  represent  m u l t i p l e s e r v e r s are r e q u i r e d at  of  that provide  server  transformation  The  are  level.  destruction,  3.1.4  servers  To  Each  servers server  and  is  general  their  dependent  of any  subordinate  avoid  circular  server  is  dependent upon  the  from which i t  dependency each server  38  makes requests notification  of lower l e v e l from  a  lower  ways without v i o l a t i n g (a) The  s e r v e r s only. to higher  Asynchronous  level  i s achieved  these dependency conventions.  d e s t r u c t i o n of processes  event in  two  These are:  a s s o c i a t e d with a higher  level.  T h i s i s used w i t h i n the communication system to i n d i c a t e that an . i n t e r a c t i v e occurred (b) The  break or other  at the lower  i n v o c a t i o n process  to commit i t s e l f accessable new  server  by way  of  level  when  dynamically  Server the  making  invocation  required  created  has  entity.  does not  to the newly c r e a t e d  server.  event  level.  i n v o c a t i o n of a higher The  asynchronous  r e q u i r e invoking its  own  address  server space  server or by b l o c k i n g on is  higher  used by the X.25 level  server  level  must  f o l l o w i n g the. r e c e p t i o n of an  the  be  incoming  call.  Figure requests  4 illustrates  within  the  downward  direction  the communication system and  i n v o c a t i o n that performs event n o t i f i c a t i o n  of  service  the upward server  to higher  levels.  39  Application  service  request  Network Server  service requests  server invocation  V Session  server invocation  Server service  Transport F a c i l i t y .  Figure 4  request  ( X.25 Server )  S e r v i c e requests and server i n v o c a t i o n ,  3.2 The Communication Model Implementation,  The communication model c o n s i s t s of three are  briefly  listed  remainder of t h i s  below  and  described  entities.  more  These  fully  i n the  chapter.  (a) The ITI s e r v e r . The ITI server provides the user server  for  remote  I/O  ( I n t e r a c t i v e Terminal terminal oriented  I/O  with  operations.  an It  addressable supports  I/O  the ITI  I n t e r f a c e ) p r o t o c o l and p r o v i d e s basic functionality  which  includes  some  40  l o c a l character transparent  t r a n s l a t i o n s . A l t e r n a t i v e l y i t operates i n a  mode  of  operation  f u n c t i o n a l i t y provided  by higher  (b) The s e s s i o n The  thereby  having a d d i t i o n a l  layers.  server.  s e s s i o n server maintains l o c a l and remote  records.  Remote  reconnect  and r e l e a s e higher  perform server  the  session  local  is directly  records  are  used  level virtual  administrative responsible  user  session  to e s t a b l i s h ,  connections  functions.  f o r dynamically  and  The s e s s i o n creating  p r o t o c o l and a p p l i c a t i o n s e r v e r s as requested  the  by an incoming  call. (c) The network The  server.  network server determines the c a l l  X.25  call  requirements from the  frame and sends the a p p r o p r i a t e  service  requests  to the s e s s i o n server to e s t a b l i s h the r e q u i r e d higher  level  communication l a y e r s .  3.2.1 The ITI Server.  The  ITI server  dynamically It  i s a transformation  created  i s used to support  1978],  and  level  protocol  server  as a r e s u l t of r e c e i v i n g an incoming the ITI p r o t o c o l as  provides  remote  defined  terminal  and  communication s e r v i c e s . The ITI server provides  intersystem  the NIM (Network  NIM  negotiation  exchange. NIM c o n t r o l data management f o r  interrupt  data  r e c o g n i t i o n i s a l s o provided  a d d i t i o n the exchange of user  data.  necessary  [Datapac  I n t e r f a c e Machine) to and  interface  in  call.  by  the  for  ITI  parameter  server  in  41  The ITI server i s composed Fig.  5  below.  addressed the  The  main  ITI  server  process  i s the process  by user processes when I/O s e r v i c e s a r e r e q u i r e d  logical  channel  i n use. The I/O request  SEND to the ITI server process buffer  of four processes as d e p i c t e d i n  over  i n v o l v e s a message  i n d i c a t i n g the request  type  and  areas i f these are r e q u i r e d . 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  a d d i t i o n a l s l a v e r e a d e r / w r i t e r processes to do t h i s .  The  multiprocess  server  implementation  s e r v i c e requests to be made of the ITI reader  and  writer  processes  server.  a l l o w s concurrent The  additional  block a w a i t i n g the s e r v i c e  from the u n d e r l y i n g X.25 l o g i c a l channel  server w h i l s t  reply  allowing  the ITI server to accept other user requests.  The  timer  process  process of timeouts  i s used to n o t i f y the main ITI server  that may occur under v a r i o u s c o n d i t i o n s f o r  resource reclamation (see s e c t i o n 3.3.2).  42  user  wr  >  write  te  Writer  requests  write  user  read  ITI Server  -read  other  1  process  the  The ITI server d e s i g n . (Arrows i n d i c a t e data  reader  and w r i t e r processes  indicating their a v a i l a b i l i t y  ITI process ITI  request  Timer  user req's  The  flow.) initially  thereby  r e p l i e s . When a read/write request  server  a  reply  X.25. Logical Channel Server  read  Reader  timeout  Figure 5  requests  requests  >  >  SEND to the ITI  b l o c k i n g u n t i l the i s received  i s made to the r e a d e r / w r i t e r process  g i v i n g the nature of the request and the l o c a t i o n the user The  user data has the necessary  remove l o c a l  system i d i o s y n c r a s i e s ) and a I/O request  writer  notification has been  The  processes  send  a  processes  remain  a  other user requests. The reader complete  event  to the ITI server when the t r a n s p o r t l e v e l  request  read/write  satisfied.  ITI server r e p l i e s to a read request only when the read  o p e r a t i o n has been completely when  writer  i s sent to  a w a i t i n g the r e p l y of the lower t r a n s p o r t l e v e l s e r v e r ,  the ITI server i s free to accept and  data.  data t r a n s f o r m a t i o n s a p p l i e d (to  the X.25 s e r v e r . While the reader and blocked  by  read  request  s a t i s f i e d . Read requests  i s c u r r e n t l y oustanding  received  are not accepted.  43  Write  requests may  concurrent  access  w r i t e requests accepted  be queued, but o n l y  by  are r e p l i e d to only when the  multiple  the  request  lower l e v e l . T h i s prevents with  an  any  user and  ITI  server  provides  been  s i n g l e process  unmanageable  a l s o performs the (a)  the standard  I/O  amount  of  s e r v i c e s to the  a d d i t i o n a l non-standard c o n t r o l requests  user to s p e c i f y or a l t e r  expanded  characters  data  transformation.  and  on  CR  LF  output.  pairs  On  the NIM  data  resource  the f a c i l i t y  should  resumes  the  session  connection  server)  This  NL  and  recognised  a c o n t r o l packet  procedures.  connection session  the ITI server  uses  is  resumed.  to 'suspend' a user's  terminal  t r a n s p o r t connection the  (newline)  characters.  be  recovery  when the u n d e r l y i n g t r a n s p o r t then  characters  recognized  r e p l i e d to by sending  i n d i c a t i n g that output  provides  locally  as INDICATION-OF-BREAK packets.  and  Tab  system  i n t e r p r e t a t i o n . User breaks are forwarded by  by the ITI server and  Error  server  Local  i n s e r t e d f o r NL  input  c h a r a c t e r s are exchanged for CR Control  ITI  the  following functions.  Local/external  are  that allow  the mode of o p e r a t i o n . The  c h a r a c t e r i s t i c s are removed from user data.  (c)  has  requests.  The  (b)  users  to the communication l i n k . I n d i v i d u a l process  from swamping the ITI server write  t o allow  The  ITI  server  terminal session fails.  The  user  by r e e s t a b l i s h i n g the (with  the  help  of  t h e n e w l y established transport  for the d u r a t i o n of the t e r m i n a l s e s s i o n .  44 The  data t r a n s f o r m a t i o n and c o n t r o l data  f u n c t i o n s that  may  be  individually  i n t e r p r e t a t i o n are  enabled  or  disabled  as  r e q u i r e d by higher l e v e l u s e r s . The modes of o p e r a t i o n a r e : (a) Transparent  input.  (enabled/disabled)  (b) Transparent  output.  (enabled/disabled)  (c) Transparent  mode.  (enabled/disabled)  Transparent  input  (a) and  transparent  allow the ITI server to t r a n s p o r t higher  level  data  transformations  n e c e s s a r i l y correspond  to  otherwise  the  operation  applied  by  (c) allows  transformation  data  end  the  output  unedited.  to  terminal  (b) modes  This  allows  be a p p l i e d that do not data  transformations  ITI s e r v e r . The transparent mode of  to  end  communication  without  data  or l o c a l or remote NIM i n t e r p r e t a t i o n of s p e c i a l  c o n t r o l c h a r a c t e r s . For example XON and XOFF are not  recognised  as c o n t r o l data. In t h i s mode of o p e r a t i o n the i n t e r p r e t a t i o n of control  data  the user  data.  The events  i s performed by higher l a y e r s from the contents of  ITI server i s asynchronously at  the  notified  i s detected by the ITI server which responds  by r e c r e a t i n g the timer process and i s s u i n g a the t r a n s p o r t l e v e l  request  to  i n d i c a t e s the nature of the event. P o s s i b l e  e x c e p t i o n a l c o n d i t i o n s i n c l u d e : the r e c e p t i o n and  read  i f none was c u r r e n t l y o u t s t a n d i n g . The r e p l y  the read request  notification  exceptional  t r a n s p o r t l e v e l by the d e s t r u c t i o n of i t s timer  process. T h i s event  to  of  the  failure  t r a n s p o r t c o n n e c t i o n . The e r r o r  of  an  interrupt  (or remote d i s c o n n e c t i o n ) of the recovery  procedures  following  45 transport  connection  The  ITI  sufficiently the be  f a i l u r e are d e s c r i b e d  server  provides  l a r g e block  transport  the  in s e c t i o n 6.  higher  s i z e so that the  high  s i z e amenable to the lower l e v e l p r o t o c o l  the  a l t e r the  ITI  length  substitution block  X.25  server of  performs  the  utilization  data,  level  block  case  in  a  block  server.  data s u b s t i t u t i o n that (tab expansion ;  and  size  I t i s i n t e r e s t i n g to observe  chosen  provided  will  CR,. LF  that  the  the user with the maximum  results.  The  i n c i d e n c e " of  s u b s t i t u t i o n s i s common i n t e x t u a l data, required  of  s i z e can  s i n g l e packet data s i z e (255 b y t e s ) . T h i s produced near  worst  a  f o r NL) i t i s not p o s s i b l e to a l l o c a t e an optimum  s i z e f o r the user.  initial  user  frame may be achieved. T h i s l a r g e block  segmented and forwarded to the t r a n s p o r t  As  level  some  to  tabs and NL (newline) so  that  most  frames  expansion, thereby r e q u i r i n g a second n o n - f i l l e d  packet.  A compromise between a l i m i t e d amount of f r e e b u f f e r and  the  use  of  a  large  block  transport  frames to be t r a n s m i t t e d  made.  block  full that  A  s i z e which would allow N f u l l f o r each n o n - f u l l packet  was  s i z e of 600 bytes was used, thereby a l l o w i n g two  X.25 frames to be t r a n s m i t t e d included  space  f o r each  non-filled  l e f t o v e r text p l u s any c h a r a c t e r s  as a r e s u l t of data expansion.  frame  that came about  46  3.2.2  The Session  Server.  The s e s s i o n server both  communication  communication duration  session  sessional  provides  services.  over the  The  complete  i n c l u d i n g p e r i o d s where the communication  provided  at  system  failure.  The  each phase of the communication  below.  establishment.  Invoke the s e r v i c e module f o r each r e q u i r e d as requested  ii.  application  has been l o s t due to t r a n s p o r t  s e s s i o n are given  i.  system server that  s e s s i o n a l s e r v i c e s are provided  services  (a) C a l l  and  of the c a l l ,  connection  is a static  by the network  protocol  layer  server,  Invoke the s e r v i c e a p p l i c a t i o n i f the c a l l  i s accepted.  (b) C a l l maintenance. i.  Maintain  call  (Includes  information  the  concerning  user, c a l l  origin,  communication  facilities  sessions.  requested,  I/O  server. ) (c) C a l l i.  Reconnection.  Maintain  ii.  a record of the suspended a p p l i c a t i o n s e s s i o n s ,  Initiate  session  reconnection  if  connection  is  reestablished. (d) C a l l i.  release.  Maintain  Protocol  an access  servers  l o g to record remote user  are  invoked  behalf  of the network  server  Verex  also  a l l descendants  removes  because  (Thereby removing unused process  by  the  team that  access.  s e s s i o n server on destruction have been  teams and s e r v e r s . ) The  within invoked. session  47  server  is statically  s e r v e r s on behalf  In  maintained  and  of the network  addition  to  so  may  performing  the p r o t o c o l  i n v o c a t i o n f u n c t i o n s , the s e s s i o n  local  remote  session  information  users  are  represented  users are represented  The  remote  administrative information in  functions.  session  are used  been  for  establishment,  accepted,  and  the  i s created  and to the  i s also  reconnection  requested  local  query  L o c a l users have query access  f u n c t i o n s . The remote s e s s i o n record has  respectively.  only.  of both l i s t s , w h i l s t the remote l i s t  the c a l l  maintains  w i t h i n both l i s t s , w h i l s t  records  and  i n the form of two l i s t s  w i t h i n the l o c a l l i s t  session  server  server  composed of both l o c a l and remote s e s s i o n records Remote  protocol  server.  application and  invoke  used  and r e l e a s e  when  the  application  call  has been  invoked.  When a t r a n s p o r t connection  f a i l u r e causes- the- a p p l i c a t i o n  to be suspended, the t r a n s f o r m a t i o n is  l e v e l server  c u r r e n t l y the only t r a n s f o r m a t i o n  (the ITI server  l e v e l server o f f e r i n g  f u n c t i o n ) sends a suspension n o t i f i c a t i o n t o the session and  awaits  i t s response. The s e s s i o n server w i l l  suspended server only when the same user has connection occurs  and  has  requested  the s e s s i o n server  this  server  r e p l y to the  reestablished  the  the same a p p l i c a t i o n . When t h i s  i n i t i a t e s the reconnection  by r e p l y i n g  to the suspended server module and the e n t i t y that requested the new s e s s i o n connection. the formal  Once t h i s  i s done the r e s p o n s i b i l i t y f o r  t r a n s f e r of ownership of the t r a n s p o r t connection  is  48  performed between e q u i v a l e n t  The  release  of  information  log  that  3.2.3  The the  session  from the d e l e t e d  Network  of  the  (and  network server  l e v e l s e r v i c e and call  protocol  remote  users.  The  provided  with  underlying  service) receives  an  frame  p r o t o c o l requirements f o r the  call,  information  (charging,  call  uses these to e s t a b l i s h  required.  choose to s p e c i f y each  protocol  layer  use  default  the  default  protocol  ITI p r o t o c o l and  protocol and  the  and  service  of  service facilities  i n v o c a t i o n of a system  service respectively.  The  protocol  requirements  sequence (lower to higher These  network  f o r s e l e c t i n g a meaningful c o n s t r u c t i o n  l a y e r s ) or may  w i t h i n Verex are the login  an X.25  o r i g i n address, etc) and  responsible  specification.  list.  r e t r i e v e s from the c a l l  dependent  remote user may  is  call  instance  the communication f a c i l i t i e s as  The  system access by  frame when the  c a l l . The  call  i s w r i t t e n to a  incoming  incoming  priority,  in the  remote s e s s i o n  invoked and  system ( i n t h i s  as w e l l as other  result  i s dynamically  transport  the higher  will  Server.  network server  contents  from the  record  i s maintained to record  The  servers.  the network connection  removal of the a p p r o p r i a t e The  protocol  are  are  l e v e l ) within  specified the  ascending  incoming c a l l  terminated by the a p p l i c a t i o n s e r v i c e  Each p r o t o c o l l a y e r s p e c i f i c a t i o n  in  frame.  specification.  i s i n t e r p r e t e d by the  network  49  server  from a s t r i n g of c h a r a c t e r s  name.  The  protocol  l a y e r s by  invoking  module as  i t s own  The of  highest  access  to  provides  a new I/O  is built  protocol  upon the e x i s t i n g p r o t o c o l  p r o t o c o l module  that  uses  the  lower  server.  level  p r o t o c o l module i s the only v i s i b l e  point  the communication system. T h i s access point  change with the service  layer  denoting the generic  addition  application  is  the user i n t e r f a c e  of  each  invoked. to  the  protocol The  layer  highest  until  level  communication  will the  module  system  I/O  services.  Fig.  6  r e q u i r e s an the  standard  below  i l l u s t r a t e s an example X.25  ITI p r o t o c o l , a t e r m i n a l handling  (TTY)  system l o g i n s e r v i c e . These requests  i n t o s e r v i c e requests  that  call  frame that  facility  are  and  translated  50 X.25 Incoming c a l l  X.25 header  frame,  ITI  Facilities  Send s e s s i o n server Request type P r o t o c o l type Network server i d Network f i l e i d  request. INVOKE PROTOCOL ITI <X.25 server X. 25 f i l e i d  Send s e s s i o n server Request type P r o t o c o l type Network server i d Network f i l e i d  request. INVOKE.PROTOCOL TTY •<• ITI server ITI f i l e i d  Send s e s s i o n server Request type S e r v i c e type Network server i d Network f i l e i d Facilities Call origin  request 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  The  call  X.25 c a l l  call  LOGIN  frame and r e s u l t i n g s e s s i o n server  i s accepted  only  requests.  i f each l a y e r can be s u c c e s s f u l l y  b u i l t and the s e s s i o n server allows to  TTY  the connection.  The  failure  s u c c e s s f u l l y invoke any p r o t o c o l l a y e r or the r e f u s a l of the (as determined  release  of  by  the  network  establishment  results  server  i n the Releasing  r e s u l t s i n the r e l e a s e of a l l  l a y e r s and t h e i r a s s o c i a t e d modules. S t a t i c  w i t h i n the t r a n s p o r t  The  server)  a l l e s t a b l i s h e d communication components.  the c u r r e n t network access subordinate  session  servers  l e v e l r e t u r n to an i d l e s t a t e .  server  is  required,  phase, and terminates  f a i l u r e of the connection  only  during'  the  call  f o l l o w i n g the acceptance or  to be e s t a b l i s h e d .  51  3.3 E r r o r Recovery.  The e r r o r recovery  f u n c t i o n s of the  transformation  system  provide a means of e r r o r recovery  from complete t r a n s p o r t system  failure.  itself  The  transport  system  i s c o n s i d e r e d as being  e r r o r free but prone to o c c a s i o n a l f a i l u r e . higher l e v e l s p r o v i d e s higher l e v e l over  transport  system  failures  Error  ITI  server  to  and  are  transparent  r e l e a s e i d l e processes  3.3.1  following transport release  channel.  ITI server p r o v i d e s s e s s i o n a l e r r o r recovery f u n c t i o n s  allow  transformation  sessions  d i s r u p t i o n s caused by connection (Transport connection intermediate  node  to  be  failure,  a  application  is  requested  If  failure,  d e l i b e r a t e t r a n s p o r t connection  application  i s unaware  of  u n t i l a read or w r i t e  the  until  the  transport  connection  is  connection  i s not  reestablished  (after  a  p e r i o d of time) the outstanding  I/O  requests  end-of-file  the  communication  condition  when  is  r e e s t a b l i s h e d the  a p p l i c a t i o n w i l l be unaware that any d i s r u p t i o n has occured. connection  any  of the ITI s e r v e r . When t h i s occurs the  i s blocked  reestablished.  over  f a i l u r e at the t r a n s p o r t l e v e l .  d i s r u p t i o n to the I/O s e r v i c e and executes operation  maintained  f a i l u r e may* be t h e r e s u l t of l i n e  r e l e a s e or other a c t i o n . ) The  the  by  Session Recovery.  The that  at the  provided  f a i l u r e and f a i l u r e of the u s e r - a p p l i c a t i o n t o d i r e c t l y the l o g i c a l  at  s e s s i o n s that are maintained  a p p l i c a t i o n l e v e l . Resource recovery f u n c t i o n s are the  recovery  will  If  predetermined return I/O  an  server  52  terminates.  The when  ITI server d e t e c t s the f a i l u r e of the t r a n s p o r t  timer  server.  process  The  exception  timer  i s destroyed by the lower process  destruction  system  transport level  indicates  that  an  c o n d i t i o n has occured at the t r a n s p o r t l e v e l . The ITI  server subsequently  i s s u e s a read request to the t r a n s p o r t l e v e l  server i f i f none was o u t s t a n d i n g . The r e p l y to the read i n d i c a t e s i f an. i n t e r r u p t  has  been  received,  the  request  transport  connection has been c l e a r e d or other e x c e p t i o n a l event. Once the ITI  server  i s aware  of the t r a n s p o r t f a i l u r e , a l l subsequent  user requests are blocked. The s e s s i o n server i s n o t i f i e d message ITI  SEND  that  server i s then  transport  The  The  suspended,  awaiting  reconnection  level.  transport  ITI  server remains blocked u n t i l e i t h e r of occur.  level  verification  connection  at the  '  suspended  includes  a  the t r a n s p o r t connection has been l o s t . The  the f o l l o w i n g two events (a)  by  represents  connection that the  same  is  the  reestablished. new  remote  transport user  and  This level user  application. (b) A timeout generated any  (of a r b i t r a r y )  l e n g t h determined  occurs that i s used as the b a s i s f o r r e l e a s i n g  resources committed to the suspended s e s s i o n .  Race c o n d i t i o n s between the timeout always  when the system i s  result  in  and  the  reconnection  favour of the timeout. Once a timeout  occurs  53 any  subsequent remote connection  (by the same user)  establishes  a new a p p l i c a t i o n s e s s i o n .  The  s e s s i o n server v e r i f i e s the i d e n t i t y of the new remote  user as the same user the remote user the  user,  identifier the  the  addressing  the  ( i e . the  server  sequence  for this  the  i s the  the  server  returned  to  the  of the new  s e s s i o n s the  entity  connection  login  server  action.)  i s performed by the cooperating ITI  previously  of  i s given  When  new ITI s e r v e r . N o t i f i c a t i o n of  i s also  itself  representing  complete  ITI  server on behalf  responsible  reconnection  servers  process  session  that the new remote user  (For i n t e r a c t i v e user  i s the server  server  suspended  reconnection  establishment.  The  is satisfied  of the corresponding  pending  involves  i n the usual user/password l o g i n sequence.  s e s s i o n server  same  whose s e s s i o n was suspended. This  suspended ITI server and the ITI  newly  events  established that  are d e s c r i b e d and i l l u s t r a t e d  occur  connection).  The  i n the reconnection  i n Appendix: A.  1  3.3.2 Garbage C o l l e c t i o n and Resource Reclamation.  Committed servers Firstly the  may  but exist  unused  resources  within t h i s  the suspension of user  connection. resources  servers Secondly  and an  idle  s e s s i o n s does not guarantee l e v e l reconnection,  resources  committed  a p p l i c a t i o n may f a i l  that are used by the  communication  implementation f o r two reasons.  user may i n i t i a t e the t r a n s p o r t  l e a v i n g those  and  communication  to  that  thereby  the  idle  to r e l e a s e those facility  (as i s  54  allowed  by  the  I/O protocol  Verex  where  formal r e l e a s e i s  c o n s i d e r e d more as a courtesy a c t i o n than a necessary one).  Non-released logical local  communication  channels system  However  at  the  calls  such  as  for  will  outgoing  be  calls  as  reclamation by the ITI server i s as  the  e l e c t another multiple  application  as owner i f  sequential  to  identify  a  process  one  the  connection  is  application  to  a p p l i c a t i o n s . The connection  that  f o r resource  s e s s i o n 'owner'. T h i s process may  i d l e e i t h e r when f o r m a l l y r e l e a s e d by a (ie.  required.  denied access i f a l l l o g i c a l  channels are i n a n o n - i d l e s t a t e . The approach used  process  unused  t r a n s p o r t l e v e l , can be recovered by  applications  incoming  facilities,  primary  s u p p l i e s the primary  file  be  used  by  i s considered user  process,  i d e n t i f i e r ) or  when no owner process e x i s t s . The e x i s t e n c e of the owner process i s r e g u l a r l y checked Fig.  by the timer process of the ITI server (see  5 ) . I f a f t e r the  application  no  timeout  longer  period  exists  has  elapsed  the  owner  the communication resources and  s e r v e r s are r e l e a s e d .  Session suspension, due to also  results  application  in  the  resources  transport  maintenance whenever  connection  failure,  of unused communication and  the  user  chooses  not  r e e s t a b l i s h the c o n n e c t i o n . The t r a n s p o r t l e v e l l o g i c a l are  not  committed,  so incoming  e x i s t e n c e of a higher l e v e l  a  blocked  state  if  communication system) and  channels  c a l l s are accepted d e s p i t e the  suspended  session.  The  resources are those c u r r e n t l y h e l d by the a p p l i c a t i o n , in  to  any  request  the  suspended  has  been  committed (which i s  made  transformation  to the level  55 server  processes.  Suspended  a r b i t r a r y l e n g t h of time seconds).  This  time  sessions  are  ( i n the order of must  be  maintained  minutes  sufficient  rather  f o r the  r e e s t a b l i s h the connection and v e r i f y himself to the the  same  user  as  server when suspended s e s s i o n timeout end-of-file  r e l e a s e the  user  to  system  as  suspended  ITI  occurs. T h i s a c t i o n causes  c o n d i t i o n f o r any outstanding  I/O r e q u e s t s . The  f u n c t i o n of the timer i s not i n h i b i t e d when the blocked.  than  that of the p r e v i o u s suspended s e s s i o n . The  timer process of the ITI server w i l l  an  f o r an  ITI  server  is  56  Chapter 4. A Dyamic Communication System Design.  4.1  A Modular System  The three  communication  principle  application level  model  levels  of  that  we  propose i s comprised  functionality,  these  l e v e l , the a p p l i c a t i o n dependent data  facility  dictates the  Structure.  the  and  the  nature and  subordinate  data t r a n s p o r t  transformation  and  that  is  transport  the  transformation  l e v e l . The  q u a l i t y of s e r v i c e  being  of  application provided  by  levels.  The  r e l a t i o n s h i p between these l e v e l s i s shown below in F i g u r e  7.  application user  communication system services  transformation layer n  t ran s format ion level  transformat ion l a y e r n-1  transport layer n  transport level  Figure 7 Functional  Each  of  the  transport l a y e r n-1  l e v e l s and  transformation  and  sub-level  transport  layers.  levels  are  57  composed  of  n  (one  or more) l a y e r s that in t o t a l provide the  s e r v i c e s and f u n c t i o n s for a given aspect  of  this  design  is  the  application. varying  A  significant  composition  of  t r a n s f o r m a t i o n l e v e l . U n l i k e the OSI model, with a f i x e d of  layers  (seven),  each  having  response  to  the  service  to be  requirements  of  a p p l i c a t i o n . The determination of the i n i t i a l transformation l e v e l establishment  4.1.1  is  made  during  the  Modules.  system to  provide  f o r a p a r t i c u l a r a p p l i c a t i o n . The  by a l l o w i n g an almost a r b i t r a r y modules  communication  functionality. unused  that  provide  the  System  overhead*  is  communication  modules.  types  only  those  flexibility  i n t e r c o n n e c t i o n of  together  enhanced by p r o v i d i n g dynamic communication  d e s i g n . Both  of the  flexibility  communication  Two  composition  we propose p r o v i d e s s i m p l i c i t y and  s e r v i c e s necessary  eliminating  particular  phase.  design  achieved  a  connection  by s t r u c t u r i n g the communication  is  established  initial  P r o t o c o l Management and F i l t e r  The  number  an a s s o c i a t e d p r o t o c o l , t h i s  s t r u c t u r e allows the communication components in  the  necessary reduced  Flexibility  by is  structuring.  of communication modules are d e f i n e d w i t h i n the  present  a  uniform  interface  to  the  user  and  t h e r e f o r e are not v i s i b l y d i s t i n g u i s h a b l e to the user, yet there are  significant  d i f f e r e n c e s w i t h i n the f u n c t i o n a l i t y of e i t h e r  module type. F i r s t l y a p r o t o c o l management module i s  an  responsible  symmetric)  for  managing  an  interactive  p r o t o c o l . A l l l a y e r e n t i t i e s w i t h i n the  OSI  (possibly model  would  entity  fall  58  under t h i s category of communication  The  second  necessarily  support  transformation knowledge modules  form  as  communication  specific  and  o n l y . We  of  protocol,  service define  filter  module.  modules  but  functions  the  second  because  module  they  not  provides  data  require  local  that  form  does  of  communication  a l t e r the p e r c e i v e d  nature of the communication mechanism. F i l t e r s can  be  used  to  i s o l a t e device dependencies and l o c a l system data  representation  characteristics  provide  services  such  (see as  section  session  4.2.2)  and  reconnection.  to  Protocol  local  management  modules are f u n c t i o n a l l y s p e c i f i e d by the p r o t o c o l they support. Filter  modules  a p p l i e d to services. are  have  alter The  locally  the  d e f i n e d f u n c t i o n a l i t y and may  perceived  filter  modules  nature  of  the  lower  be  level  that are used w i t h i n t h i s design  f u n c t i o n a l l y s i m i l a r to f i l t e r s  as  used  within  the  is  composed' only  Unix  o p e r a t i n g system.  The  communication  structure  communication modules that are e x p l i c i t l y a p p l i c a t i o n to provide  the  Each  a  module  provides  necessary  of the communication  during the i n i t i a l  the  r e q u i r e d by the a c t i v e  communication  services.  uniform i n t e r f a c e f o r the i n t e r a c t i o n  between modules and the a p p l i c a t i o n structure  of  (see  section  4.2.1).  The  system i s determined dynamically  connection establishment  phase.  Filter  and  p r o t o c o l management modules are invoked and l i n k e d as r e q u i r e d .  The example  two  types  of  communication  shown below. The f i l t e r  module  modules are used i n the is  applied  to  provide  59  full  screen  terminal  terminal  protocol  transparent  support  module  when  provides  the  underlying,  only  scroll  virtual  mode  or  functionality.  Example 1.  A  filter  module  i s applied  p r o t o c o l so as to provide whilst  using  an  full  to a t e r m i n a l support ( I T I )  screen,  full  duplex  operation  u n d e r l y i n g p r o t o c o l that provides only s c r o l l  mode t e r m i n a l support  or a transparent  mode of  module i s invoked  operation.  the t e r m i n a l  (TTY) f i l t e r  subordinate  p r o t o c o l (ITI) module enter the transparent  o p e r a t i o n . The ITI p r o t o c o l module then does t r a n s l a t i o n but continues functions.  Exception  by  transformation Fig.  means  not  that the mode of  provide  data  to perform p r o t o c o l c o n t r o l management conditions,  such  i n t e r p r e t e d by the ITI module and the higher notified  i t requests  When  of  the  local  as  i n t e r r u p t s are  l e v e l TTY module i s  interface.  i s performed by the higher  level  All  filter  data  module.  8 i l l u s t r a t e s the communication system c o n s t r u c t i o n f o r the  described terminal  support.  60  Command I n t e r p r e t e r  Application  level.  TTY _ t t y f i l t e r Transformation  ITI  protocol  X.25  Figure  8  protocol  Transport l e v e l , ( m u l t i p l e modules)  Terminal support communication  modules.  In F i g . 8 the ITI module and X.25 module(s) are for  supporting  level.  the ITI p r o t o c o l  and  the  three  responsible  X.25  protocol  l a y e r s r e s p e c t i v e l y . The TTY module performs data i n t e r p r e t a t i o n and  translation  require s p e c i f i c  functions  that are l o c a l  f u n c t i o n s and do not  p r o t o c o l data to be exchanged.  4.2 Transformation L e v e l F u n c t i o n a l i t y .  4.2.1  A Uniform Communication Module  Interface.  Standard system s e r v i c e s can be c o n v e n i e n t l y  represented  those s e r v i c e s that are s u p p l i e d by any I/O process.  A  by  standard  61  I/O  interface  can  be  used  for  o p e r a t i o n s . If the d i s t i n c t i o n operations  is  application  not  may  distribution  use  of  providing a  apparent either  services  standard  I/O  between  define  local local  and  remote  and  remote  I/O I/O  at the a p p l i c a t i o n l e v e l then  the  environment  The  and  transparently.  resources  interface  communication system s e r v i c e s and  We  both  is  facilitated  applicable  the l o c a l I/O  to  both  by the  operations.  the b a s i c s e r v i c e s provided upon request by a l l  t r a n s f o r m a t i o n l e v e l communication modules  to  be  those  given  below. These a r e : (a) Open c o n n e c t i o n .  ( s y s t e m / a p p l i c a t i o n dependent)  (b) Close  connection.  (c) Write  data.  (d) Read data. (e) N o t i f i c a t i o n of (f)  Query  interrupt.  response.  (g) A l t e r  'ownership' of the f i l e  These  (connection).  s e r v i c e s apply both to communication r e l a t e d  as w e l l as the e s t a b l i s h e d I/O  files.  identical  I/O  to  applications apparently  application access  a  file  requests,  distributed  types  thereby  environment  appear allowing  that  is  local.  Non-standard a p p l i c a t i o n s may remote  to  Both  'files'  services recognize the  communication  are  provided  distinction  functionality  and  because  between require  local  some and  alternative  62 services. Alternatively non-standard  some  communication  communication requests  nature of these non-standard s e r v i c e s Some t y p i c a l non-standard s e r v i c e s (a) A l t e r mode of o p e r a t i o n (b) Send  modules  amongst  make  themselves.  w i l l be system  would  may  The  dependent.  include:  request.  interrupt.  (c) Query connection dependent  information.  (d) Reconnect to new subordinate module.  Applications provided  by  that  the  interchangable  make  use  communication  between  a  that  are r e l e v a n t  interrupt  transfer  i f one  directed  to  as  an  not  immediately  d i s t r i b u t e d environment.  designed t o operate and  t r a n s f e r program  interrupt  i s current. the  and  are  manage  to the d i s t r i b u t e d environment. For  example, an i n t e r a c t i v e f i l e user  modules  local  These are p r i m a r i l y a p p l i c a t i o n s functions  of non-standard I/O s e r v i c e s  A  directed 'send  communication  may  towards  interrupt'  module  translate  that  the  a  file  request i s . manages  application  session  concerned with the f i l e  interrupt'  request  i s not a standard I/O request as i t does not  correspond to l o c a l I/O f u n c t i o n necessary  t r a n s f e r . The  the  as we have d e f i n e d  f o r synchronization  between  remote  'send  them, but i s interactive  processes.  A standard i n t e r f a c e to  support  the  interconnection interface  f o r communication modules i s necessary  flexibility  provided within  between  all  of  the (almost) a r b i t r a r y module  t h i s d e s i g n . Without a  modules,  the  standard  interconnection  of  63 communication modules  would  be  possible  only  on  a  r e s t r i c t e d b a s i s . Where modules support non-standard addition  to  supporting  the  f u n c t i o n a l i t y of the module modules  that  utilize  standard may  not  standard I/O  I/O be  operate does  example  a  support  available  for  transparent  Data Transformation and  The primary to  i f they are to  succeed  operation.  is  .if  the  Modules  translated  established  cannot this.  in  the  format  the higher l e v e l p r o t o c o l management. Data by  transformation-  level  modules-  'standard' data r e p r e s e n t a t i o n so  to  . do  can be avoided. The two  things.  t r a n s f o r m a t i o n between a l o c a l and to  be  f u n c t i o n of the t r a n s f o r m a t i o n l e v e l modules i s  device dependencies required  module  with  most convenient. W h i l s t doing t h i s the t r a n s f o r m a t i o n  modules perform be  operate  Transparency.  provide the user a p p l i c a t i o n with data  which  those  subordinate  i n t e r c o n n e c t e d i n a f u l l y a r b i t r a r y manner because of  4.2.2  full  request f o r a subordinate module to  i n a t r a n s p a r e n t mode w i l l not  not  i n t e r f a c e , the  requests to the  l a y e r must have those requests s a t i s f i e d For  s e r v i c e s in  requests o n l y . A l t e r n a t i v e l y  those modules that make non-standard  correctly.  greatly  that  must  to/fromsystem  anand  t r a n s f o r m a t i o n module i s  Firstly  to  perform  standard format and  data  secondly  provide the high l e v e l p r o t o c o l management f u n c t i o n s .  The  protocol  management and data t r a n s f o r m a t i o n f u n c t i o n s  can be separated so that a p r o t o c o l management  module  the  system dependent  protocol  management  functions  data t r a n s f o r m a t i o n s are performed  alone and  by a separate f i l t e r  performs  module.  64  System dependencies are then The  versatility  specific  of  encapsulated  f u n c t i o n s are removed. F i l t e r  modules then become simpler t o develop  The higher  data  transformation  level f i l t e r  required  an  function  can  alternative  unaltered.  filter  This  mode module  mode  of  require  be performed by a itself.  operation  that  filter  When  filter is  i s necessary  allows  data  of o p e r a t i o n , c a l l e d  to be  transparent  modules are t o be allowed  c o e x i s t i n a n o n - i n t e r f e r i n g h i e r a r c h i c a l s t r u c t u r e of f i l t e r  and p r o t o c o l management modules. Stacking not  not  f u n c t i o n a l i t y of a subordinate  mode, i s r e q u i r e d i f m u l t i l e v e l to  do  module or by the a p p l i c a t i o n  w i t h i n the lower l e v e l passed  as they  of p r o v i d i n g i n t e r a c t i v e p r o t o c o l management.  the data t r a n s f o r m a t i o n not  modules.  p r o t o c o l management modules i s enhanced, as  l o c a l data t r a n s f o r m a t i o n  the complexity  within f i l t e r  necessarily  higher  level  provides  a  imply  filters means  filter  modules  the need f o r a transparency  may s t i l l  r e q u i r e these  of bypassing  does  f u n c t i o n as  functions,  but i t  the data t r a n s f o r m a t i o n  process  when t h i s i s not r e q u i r e d .  4.2.3 E r r o r Recovery and Session Management.  The  t r a n s f o r m a t i o n system design presumes the presence of a  transport although be  facility  that i s e r r o r - f r e e (within a l l o w a b l e  prone t o f a i l u r e . F a i l u r e of the t r a n s p o r t f a c i l i t y  the  result  of  line  failure,  system  unexpected d i s r u p t i o n . I t i s t h i s e r r o r concern  bounds)  at the t r a n s f o r m a t i o n  system  failure  situation  level.  or  that  may other  i s of  65  The  objective  transformation operation transport  of  level  over  the is  e r r o r recovery  to  disruptions  to  r e e s t a b l i s h e d . The  transport exist one  the  service  until  a p p l i c a t i o n s e s s i o n may  r e l e a s e a communication I/O  s e s s i o n s may connection  thus r e q u i r i n g t r a n s f o r m a t i o n illustrates transport  the  n  exist  transport >  To  over session  may  yet must have at l e a s t as  still  r e s u l t .from f a i l u r e  l e v e l garbage  session  collection.  Fig  between  application  application  sessions  <  9  transport  sessions >  <  to  9 and  provide  transport  session.  application  The are  unaware  session  failure  utilizes  of  session  >  Multiple transport/application  system  transport  many  at the a p p l i c a t i o n l e v e l ,  relationship  communication  entities)  can  sessions.  application  Figure  :n  the  l e v e l modules  a c t i v e a p p l i c a t i o n s e s s i o n a c t i v e to be c o n s i d e r e d transport  by  the t r a n s p o r t connection  several a p p l i c a t i o n sessions  Inactive  the  continued  provided  sessions. A l t e r n a t i v e l y a single transport  over  active.  <  applications  system. T h i s r e q u i r e s the t r a n s f o r m a t i o n  to maintain s t a t e information be  al-l-ow  c a p a b i l i t i e s at  (or the  the  sessions,  error  concept  higher  recovery  the  of an a p p l i c a t i o n  level  transformation  d i s r u p t i o n of s e r v i c e due  f a i l u r e . Reconnection of a  transport  to a  session  66 to  an  existing  intervention manager.  transformation  session  of another system management  This  session  will  require  entity,  the  management e n t i t y i s d e s c r i b e d  the  session  in section  4.3.3.  Error  recovery due to t r a n s p o r t  of  complexity,  the  a p p l i c a t i o n . The simplest  application, is  both  failure  imposes two  of which are dependent upon the nature of of these i s the n o n - c r i t i c a l  i n which l o s s of data due to e x c e p t i o n a l  a c c e p t a b l e . An example of an a p p l i c a t i o n  is acceptable  (as an  alternative  to  alternative condition  duplication  of  complexity  of  considerably  data)  the  is  error  greater.  complexity  and p r o t o c o l  system. An  additional  termination)  loss is  i n which l o s s of data (or In  procedures  sequencing  Sequencing  conditions  users.  unacceptable.  recovery  Data  ensure data c o n s i s t e n c y .  i s that  data  f o r which data  session  t i m e s h a r i n g support f o r a remote terminal  The  levels  is  data  this  case  the  provided  is  necessary so as to  requires  additional  overhead on the e x i s t i n g - t r a n s f o r m a t i o n protocol  layer  will  be  necessary  to  p r o v i d e the sequencing f u n c t i o n a l i t y i f not a l r e a d y provided and thus  ensure  no l o s s or d u p l i c a t i o n  of data on t r a n s p o r t  f a i l u r e . The implementation d e s c r i b e d  i n chapter  the  data l o s s and d u p l i c a t i o n .  former approach a l l o w i n g  Multiple  application  possible  s e s s i o n s per t r a n s p o r t  achieved e i t h e r by m u l t i p l e x i n g transport  3  system  session  a p p l i c a t i o n " sessions  connection, or by a l l o w i n g  takes  the a p p l i c a t i o n  be changed at the d i s c r e t i o n of the a p p l i c a t i o n . An  only  can be  over  the  session to application  67 is  free  pass  to terminate the a p p l i c a t i o n s e s s i o n at any  'ownership'  application session.  of  the  process  This  is  implementation  communication  thereby  the  a p p l i c a t i o n that  in  him/herself  to  another  course  of  events  chapter3  in  which  i n t e r a c t s with the  entry and user v e r i f i c a t i o n identified  initiating  normal  described  facilities  time or to  remote  another  application within the  user  is  the  initial a  system  ( l o g i n ) procedure. When the user  to the s a t i s f a c t i o n of the l o c a l  has  system  the next a p p l i c a t i o n process i s a l l o c a t e d the connection s e s s i o n ownership  The  priviledgess.  other  alternative  sessions  per  transport  facility  application  application  to  session.  i s lost  processes  is  and  allow  multiple  This  transport  i s achieved when the  subsequently  reconnected.  The  (and higher l e v e l t r a n s f o r m a t i o n modules)  are unaware that the reconnection has o c c u r r e d . The  reconnection  i s provided  manages  by  the  transformation  transformation/transport some  c o o r d i n a t i n g , system  server may  4.2.4  level  fulfil  B l o c k i n g and  The approach  within  that  (In  t h i s case the s e s s i o n  this function.)  Segmentation.  to b l o c k i n g and  the  t r a n s m i s s i o n block s i z e  segmentation  taken w i t h i n t h i s  blocking/segmenting  communication i s determined  system  by  the  operations itself.  transport  Blocking/segmentation  is  performed  at  as The  level.  T h i s p r e s e n t s an upper bound upon the data u n i t s i z e that can transmitted.  the  i n t e r f a c e with the c o o p e r a t i o n of  service.  design i s to provide as few possible  module  be the  68  transformation/transport level  interface.  Transformation  level  block s i z e i s not r e s t r i c t e d by the t r a n s p o r t block s i z e as level  of  functionality  arbitrarily of  block  l a r g e block size  no  as  upper  i n h e r e n t l y v i r t u a l and may  s i z e s to higher  secondly  to attempt  lower  transformation  bound  additional  module  can  protocol  Blocking/segmentation data  provide  block  the  expansion  header is  functions  system and  transport  then  and  use  be  at  as  the  a  if  appended. the  layer  r e s u l t of i t s data  transformation/transport  size.  utilized  approach by  the OSI  appears  to  be  less  flexible  than  the  data  or more times  unit  may  be  altered  three  times  exchange of data between l a y e r s . The  OSI  protocol  first  data  unit  (PDU)  of  the  OSI  .model  s i z e . Given  flexibility than u s e f u l .  in  layer entity  the  in the the  size  be  (IDU),  which  (SDU)  before  in p r o t o c o l data u n i t s  the number of l a y e r s in the segmenting and  model  l a y e r , which may  then must conform to a given s e r v i c e data u n i t at the next  size-  specifies  blocked/segmented to the i n t e r f a c e data u n i t s i z e  accepted  that  model whereby- data- u n i t s of d i f f e r i n g  are allowed at each l a y e r i n t e r f a c e . Within  (PDU)  if  i n t e r f a c e where the t r a n s p o r t l e v e l p r o t o c o l d i c t a t e s the  This  being  data  provided is  only  has each  the same user  must  required  level  limits)  information  expansion/contraction  transformation level  utilize  (within  block s i z e . S u f f i c i e n t b u f f e r  performs  to  choice  to be s u i t a b l e f o r the  f u l l y as p o s s i b l e . As the t r a n s f o r m a t i o n  or  provide  l e v e l u s e r s . The  should be chosen f i r s t l y  a p p l i c a t i o n and facility  is  this  OSI  model,  such  b l o c k i n g becomes more burdensome  69  4.3  Transformation  The  L e v e l Components.  three types of components that cooperate  s e r v i c e s of the t r a n s f o r m a t i o n transformation  level  call  call  phase  establishment  and  incoming c a l l  i s required  only  handler  the the  and a  during  the  the s e s s i o n manager i s a system s e s s i o n a l s e r v i c e s upon  request  i l l u s t r a t e s a t y p i c a l sequence of events  required  a l l users.  Fig. to  an  handler  management e n t i t y that provides to  l e v e l w i t h i n t h i s design are  modules,  s e s s i o n manager. The  to provide  10  e s t a b l i s h an a p p l i c a t i o n s e s s i o n a f t e r an  r e c e i v e d by the t r a n s p o r t system.  incoming  call  is  70  Step # Application  A p p l i c a t ion level  5.  Perform p r o t o c o l dependent i n i t i a l i z a t i o n . Provide user request s e r v i c i n g .  Transformat ion modules  Transformat ion level  4.3.1  Determine c a l l requirements. ie. Application, protocol, o p e r a t i o n mode, c a l l characteristics etc.  Handler  1.  Transport system  Transport level  Figure  Create or a l l o c a t e the required a p p l i c a t i o n , t r a n s f o r m a t i o n components.  Session Manager  Call  10  Call  I n t e r a c t with remote user  Receive incoming c a l l . N o t i f y c a l l handler.  establishment phase.  Data Transformation Modules,  The  transformation  level  is  composed of n (one or more)  t r a n s f o r m a t i o n modules. Each module i s l a y e r e d so as to the  services  services  with  transformation  of  the  its  layer  own  module  below  and  functionality. is  enhance The  utilize  the provided topmost  data  the only communication system e n t i t y  71 through which users request communication s e r v i c e s . access to subordinate although  any  entities  transformation  module may present  itself  Application  i s not d e f i n e d w i t h i n t h i s layer  module  design  or b a s i c t r a n s p o r t  as the topmost communication l a y e r i f  requested.  Unlike level  the OSI model the composition  i s not  transformation transport level.  level  facility Fig  timesharing level  fixed.  Fig.  depicts  configurations,  and an ITI  11(a)  11  of the t r a n s f o r m a t i o n  each  three  based upon an X.25  protocol  at. the  simple  terminal  provides  a p p l i c a t i o n using the  ITI  possible  protocol  transformation access  to a  transformation  module. F i g 11(b) provides enhanced t e r m i n a l access  using  the ITI p r o t o c o l i n a transparent mode of o p e r a t i o n by adding terminal  handler  filter.  a  F i g 11(c) i l l u s t r a t e s a f i l e t r a n s f e r  a p p l i c a t i o n , again using the ITI p r o t o c o l i n t r a n s p a r e n t mode. A file is  transfer f i l t e r  applies a local  used to transform data to l o c a l  these  file  transport level  interface.  interface  that  system formats. Each of  configurations  reconnection/segmentation/blocking and  system f i l e  utilizes filter  a-  at the t r a n s f o r m a t i o n  72  command interpreter  command interpreter  file transfer  terminal handler filter  file transfer filter  A p p l i c a t ion level.  Transformation level.  ITI  Reconnection/ Segmenting/ Blocking filter  ITI (transparent)  ITI (transparent)  Reconnection/ Segmenting/ Blocking filter  Reconnection/ Segmenting/ Blocking/ filter  X.25  X.25  (a) Figure  (b) 11  (c)  A l t e r n a t e communication system  4.3.2 Incoming C a l l  Handler.  The  handler  incoming  call  created service f a c i l i t y an incoming c a l l  The  that  is a  configurations..  static  or  i s used to determine  and i t s s e r v i c e  incoming c a l l  Transport level.  X.25  dynamically  the nature of  requirements.  handler i s designed as a separate e n t i t y  because: (a) The d e t e r m i n a t i o n of the incoming c a l l dependent such  the  upon  the  underlying  transformation  requirements  may  be  t r a n s p o r t mechanism and as  protocol  dependencies  are  73 encapsulated described  with  in  the  call  chapter  3  handler. In the  the  incoming  dependent upon the u n d e r l y i n g X.25 (b)  The  incoming  call  handler  implementation  call  incoming  handler  call  frame,  i s r e q u i r e d only during the  establishment phase. I t serves  no  function  is  in  call  subsequent  interactions.  Isolating handler allows  the  t r a n s p o r t system dependence w i t h i n the  all  other  system  components  to  be  designed  independent  of the p a r t i c u l a r t r a n s p o r t system. The c a l l  is  to implement so that the overhead  simple  any new protocol entity  transport f a c i l i t y dependencies assumes  interpretation  is  minimal.  Ideally  a l l transport  can be removed i f the t r a n s p o r t p r o t o c o l  the  responsibility  of the c a l l  Given the temporary it  is  handler,  i n development f o r  requirements  of  performing  from the c a l l  forwarding these requests i n a p r o t o c o l independent  handler,  call  functionality  convenient  to: allow  of  the  the.  c r e a t e d dynamically and then disposed of  frame and  manner.  incoming  call  once  the  the  call  handler to beapplication  s e s s i o n and communication system s t r u c t u r e has been e s t a b l i s h e d . An  alternative  i s to allow a s t a t i c c a l l  the s e r v i c e of incoming  call  handler that p r o v i d e s  establishment upon request  and  is  maintained c o n t i n u o u s l y .  The "be  call  establishment phase r e q u i r e s that several, a c t i o n s  taken by the incoming  are t o :  call  handler.  These  responsibilities  74  (a) : Determine  the t r a n s f o r m a t i o n  i n t e r a c t i o n with level  the  protocols  transformation  modules that are r e q u i r e d for  remote user. T h i s  to  -be  used  and  modules to provide  may  i n c l u d e an  inter-system  mail  transmission  facility.  (c)  Determine  the  transport  call  o r i g i n and p r i o r i t y  call  i s accepted  or  facilities  by the l o c a l  (d) Forward t h i s information  Session  The  higher  requirements. Charging, may  affect,  sessions  manager  connections  represent  the  session  connection  by  communication access level  connection  is  a  system  'ownership' to  management  reconnection  (application  virtual  connections  and  entity  release  of  sessions). Application between  applications  exchange i n f o r m a t i o n .  The  i s terminated  when the a p p l i c a t i o n r e l e a s e s  a  request  release  directed  to  p o i n t . U l t i m a t e l y the r e l e a s e of the  causes the r e l e a s e of the u n d e r l y i n g  connection.  Applications  application  session  ensuring  the.  module(s).  d u r i n g which time the a p p l i c a t i o n s may application  whether  to the s e s s i o n management e n t i t y .  for the establishment,  level  file  Manager.  session  responsible  s e s s i o n , an  system.  the newly c r e a t e d t r a n s f o r m a t i o n  The  Possible  inter-system  (e) Complete the t r a n s f e r of t r a n s p o r t connection  4.3.3  or more  application.  an  facility  high  facilities.  i n t e r a c t i v e timesharing  facility  the  r e q u i r e one  these  (b) Determine the nature of the requested alternatives  specifies  may  transfer  'ownership'  between themselves and  that the connection  i s not  the higher  transport of  the  are r e s p o n s i b l e f o r  inadvertently  released.  75  The  session  sessional  manager,  services  and  modules i n  addition  provides.  These  as  the  name  implies,  provides  f u n c t i o n s f o r the t r a n s f o r m a t i o n  to  any  services  other and  implementation. The f u n c t i o n a l i t y of  system  services  functions the  may  session  level  that  it  vary  with  manager  may  i n c l u d e the f o l l o w i n g (non exhaustive) s e r v i c e s and f u n c t i o n s . (a) Session  s e c u r i t y and v a l i d a t i o n .  Determine the a c c e p t a b i l i t y of the c a l l given requested, (b) Session Aid and  i t s origin etc.  establishment  the  call  handler  (c) S e s s i o n a l e r r o r  reconnection a  application  session  (d) Session  the  termination session  l e v e l modules as r e q u i r e d .  services  transport  termination  Release  i n the i n i t i a t i o n of the a p p l i c a t i o n  recovery.  following  level  for transport connection  i s maintained over t h i s  connection failure.  The  time.  functions.  transport functions  connection as  required  or when  perform  other  the a p p l i c a t i o n  i s released.  (e) Perform l o c a l Supplying  call  examples  of  the  functions.  the' t r a n s f o r m a t i o n  Perform  the f a c i l i t i e s  system s e c u r i t y and query information  and logging  tasks. incoming  calls  are  l o c a l query and s e c u r i t y f u n c t i o n s used w i t h i n  implementation d e s c r i b e d  i n chapter  3.  76  4.4 Comparison with OSI and Pup A r c h i t e c t u r e s .  The the  design d e s c r i b e d w i t h i n t h i s t h e s i s , the OSI model  Pup  architecture  share  some  and  p o i n t s of commonality. Each  communication a r c h i t e c t u r e provides a basic  layered  structured  in which s u c c e s s i v e l a y e r s provide enhanced f u n c t i o n a l i t y . These layers  communicate  with  e q u i v a l e n t l a y e r e n t i t i e s at a remote  system using p r o t o c o l s and use  interface  interactions  between  layers.  Whereas  the  transformation  OSI  layer)  design to  designates  provide  a  data  s i n g l e l a y e r (the  transformation  and  protocol  management f u n c t i o n a l i t y , the design we have d e s c r i b e d  separates  these  functions  to  functions, and allows l o c a l be  performed  Data t r a n s f o r m a t i o n communication  data  transformation  w i t h i n independent f i l t e r  modules.  i s provided at one or more l e v e l s w i t h i n the  system.  Stacking  filter  applications  to  use  previously  a d d i t i o n to  any  new  data  modules  allows  established f i l t e r  transformation  new  modules i n  functionality  they  provide.  Our  design  utilizes  dynamic  layering  of  communication  modules that are e s t a b l i s h e d when an incoming c a l l This within  is  similar  Pup  application  to  received.  the  provision  of g e n e r i c socket  be  addressed  .to  protocol  services  using  that and  is  can  request the  particular  rendezvous and  t e r m i n a t i o n p r o t o c o l . The Pup a r c h i t e c t u r e  establishes  well  represent  known  socket  addresses  s e r v i c e type, our model provides  that a  each single  numbers  several  a generic  addressable  access  77  point.  Higher  l e v e l p r o t o c o l s and s e r v i c e s are requested using  i n f o r m a t i o n contained i n the i n i t i a l call  establishment  call  frame.  Whereas  the  mechanisms d i f f e r w i t h i n both our model and  the Pup model, both u t i l i z e g e n e r i c i d e n t i f i c a t i o n of  services.  Addressing p r o t o c o l l a y e r s and a p p l i c a t i o n s by generic name does not  n e c e s s i t a t e that each l a y e r address be known by the c a l l i n g  system.  Generic  possibility another  specification  also  removes  of i n c o r r e c t a d d r e s s i n g i f the address  the  i s reused by  entity.  On (as  protocol  the other hand the ISO model proposes  individual  layer  w e l l as other OSI resources) a d d r e s s i n g r a t h e r than generic  service requests. This  requires  a  greater  amount  of  global  knowledge to be shared.  Like  Pup,  our  design  supports  components w i t h i n the communication protocol  many  structure.  interchangeable The  choice  of  support can be made on the b a s i s of a p p l i c a t i o n needs,  performance  requirements,  resource.  availability  or  other  considerat ion.  However restricted  unlike  to  transformation  a  the  OSI  specific layer  and Pup models our design i s not  number  represent  of  layers,  specific  nor  services.  does  A uniform  i n t e r f a c e between a l l t r a n s f o r m a t i o n l e v e l modules allows transformation flexibility  modules  to  be  liberally  existing  with  differing  to  be  developed  s e r v i c e s , or to form a l t e r n a t e f u n c t i o n a l performance  these  interconnected. This  allows new communication s e r v i c e s  from  each  characteristics  thereby  levels  allowing  78  several  interchangeable  protocol  modules  at  one  similarity  to  functional  level.  This  design  architecture flexibility (and  to  shows  than  to  greater the  OSI  model,  yet  proposes  than a v a i l a b l e w i t h i n both designs.  a  lesser  degree  the  Pup  design)  the all  Pup  greater  The  OSI  model  does  not  allow  a p p l i c a t i o n s to access lower l e v e l communication when the  the  services  even  f u n c t i o n a l i t y r e q u i r e d by the user i s f u l l y provided  lower  l e v e l . The  utilization  of a uniform I/O  l e v e l s of the communication system allows  (without  application  modification)  i n t e r f a c e at  both  and  by  user  access  arbitrary  layer  interconnection.  The mode  OSI  model in p a r t i c u l a r does not provide  of o p e r a t i o n  maintaining  simplicity),  and  a complex general  The  provided  the OSI  system complexity  providing  fewer  fixed  by the OSI  reference and  the aims of our design  a r c h i t e c t u r e are s i m i l a r ( i e .  provides  simplified'  that r e q u i r e s minimal p r o t o c o l complexity  overhead. Whereas in t h i s respect Pup  a  is  and  and  the  flexibility  by  to  increase  has  compromised on  simplicity  purpose communication framework.  reduced  layers  with  within  our  design  by  fewer b a s i c s e r v i c e s than  model. Many s e r v i c e s  required  by  the  OSI  model, such as downward m u l t i p l e x i n g , have l i m i t e d use  are complex to implement. (For example downward m u l t i p l e x i n g  requires to provide  a d d i t i o n a l flow c o n t r o l and multiplexing  such as m u l t i p l e x i n g ,  services.)  at m u l t i p l e  resequencing f u n c t i o n a l i t y Duplication  layers within  of the  functions, architecture  79  increases  flexibility  at  the  expense  of  greater  complexity  w i t h i n each l a y e r that p r o v i d e s t h i s f u n c t i o n .  Many f u n c t i o n s provided w i t h i n the s e s s i o n l a y e r of the model are r e q u i r e d by a m i n o r i t y of a p p l i c a t i o n s  and  could  OSI be  provided by the a p p l i c a t i o n or by higher l a y e r s where necessary. One  example  of  this  s e s s i o n l a y e r . The  is  the  quarantine  'quarantine' function  has  f u n c t i o n of the many  uses  OSI  within  d i s t r i b u t e d a p p l i c a t i o n s where data c o n s i s t e n c y must be ensured. However  the  quarantine  dependent f e a t u r e and  function  i s apparently an a p p l i c a t i o n  as such c o u l d  be  provided  at  a  higher  layer.  The are  s e s s i o n management f u n c t i o n s provided w i t h i n our  provided  by  a  management  entity  as  opposed  p r o v i s i o n by a 'session l a y e r ' (as proposed by the The  s e s s i o n a l .manager  is  similar  e n t i t y that r e s i d e s w i t h i n the model.  However',  particular such  as  as  the  the reconnection the  ITI  in  application  layer  s e r v i c e ) to  of  the  through  take  layered  s i g n i f i c a n c e when c o n s i d e r i n g component  we  number of redundant configuration  of  have  described  services the  OSI  modules  that  communication  part  in  communication  s t r u c t u r e , the p o s i t i o n i n g of the s e s s i o n a l manager i s  design  the  implemented, i t r e s i d e s at a l e v e l  the  The  model).  transformation  i t does not  data  OSI  their  s e s s i o n manager p r o v i d e s s e r v i c e s ( i n  server we  of  to  n o t i o n of a management  below the t r a n s f o r m a t i o n modules. As progress  design  only  of  interdependencies.  attempts are  to minimize the  provided  system  and  by  a  given  in  doing  so  80  p r o v i d e a simpler, system  more f l e x i b l e  interconnection.  As  tool  within  design presents a model that allows communication  services  and  a p p l i c a b l e to the task at hand.  for the  the  functions  remote  access  and  Pup a r c h i t e c t u r e  this  dynamic that  selection are  of  directly  81  Chapter  5. C o n c l u s i o n .  We  have used the Verex research computer system as  environment  f o r an experimental  implementation. this  The communication system model d e s c r i b e d  of high l e v e l p r o t o c o l s . The  the implementation existing  X.25  application  implementation  f u n c t i o n a l i t y was  and  The  implementation  was  design than  is  structure  Extended  upon the b a s i c ITI p r o t o c o l  design  applying  described  implementation  possible  within  of the design  implementation  a  t r a n s f e r s e r v i c e a l s o u t i l i z e s the ITI p r o t o c o l its  within  own  file  this  transfer  thesis  is  provides  the uniform module  model a  provides greater  static  structure.  server model used a convenient  interface.  a  implementation.  The  within  model for the  the  flexibility modular  i s w e l l s u i t e d to implementation  a m u l t i p r o c e s s design. The  of  includes  dynamic communication system s t r u c t u r e used w i t h i n and  for  provided by a p p l y i n g  g e n e r a l i z a t i o n of the Verex communication model  The  the  achieved by the a d d i t i o n of higher  screen support  enhances i t s s e r v i c e s by  protocol.  framework  as a t r a n s p o r t f a c i l i t y .  data t r a n s f o r m a t i o n f i l t e r  services. A f i l e  to both  of the ITI v i r t u a l t e r m i n a l p r o t o c o l using an  order p r o t o c o l s . F u l l terminal  within  design.  T h i s communication model p r o v i d e s a f l e x i b l e the support  and  but not n e c e s s a r i l y u l t i m a t e ,  design that r e s u l t e d from many i t e r a t i v e refinements and  host  communication system design  t h e s i s represents the f i n a l ,  implementation  a  the  within Verex  utilization  82  From t h i s experience we have l e a r n e d that of  the  flexibility  the communication system i s enhanced by the modular (layered)  system greatly  design.  We have found that the uniform module i n t e r f a c e  enhances  interactions  the  versatility  thereby  of  allowing  user the  and  interlayer  almost  arbitrary  i n t e r c o n n e c t i o n of modules. T h i s uniform module i n t e r f a c e allows users to access the communication system adequate  for  the  at  a  level  s e r v i c e s that they r e q u i r e , thus  unused higher l e v e l p r o t o c o l  that  is  eliminating  layers.  The f o l l o w i n g s e c t i o n reviews the s i g n i f i c a n t  issues  were  addressed w i t h i n t h i s 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 the  implementation  for  of high l e v e l p r o t o c o l s . The most  important  p o i n t s of the model, and the s i g n i f i c a n c e of these are  reviewed  below. These a r e : (a) Dynamic  initialization  Structuring  and l i n k a g e of communication  the" communication  time an incoming c a l l  protocol  modules.  l a y e r s at the  i s r e c e i v e d allows fewer resources  to  be committed to i d l e communication channels. In a d d i t i o n the requirements  of the c a l l are determined  r e c e p t i o n . Communication linked  as  required  service  support.  to  at the time of c a l l  s e r v i c e modules may provide  be invoked  the necessary  and  application  83  (b) U t i l i z a t i o n The  of uniform module i n t e r f a c e .  provision  allows  almost  of a  uniform  arbitrary  interface  interconnection  between  modules  of modules  within  the communication system. Within the Verex implementation local  device  independent  I/O  protocol  is  supported  a by  communication modules and other system I/O s e r v e r s . (c) A p p l i c a t i o n  session  Application applications layer  error  session  with  recovery.  error  some  degree  f a i l u r e . The d u r a t i o n  determined  recovery  operations  of s e c u r i t y over  of the. a p p l i c a t i o n  and  this  new  the t r a n s p o r t  transport  occurs  the  application  connection f a i l s . The a p p l i c a t i o n  higher l e v e l communication modules are  module  is  by the a p p l i c a t i o n . The communication system and  when  another  transport  session  host environment provide a means of m a i n t a i n i n g state  provide  connection  suspended  i s established.  transformation/transport  until  When (and i f )  level  interface  reconnects the suspended higher l e v e l modules to the  transport  connection  thereby  allowing  continued  communication model that we have d e s c r i b e d  presents an  operation.  The  a l t e r n a t i v e model to that proposed by the OSI Our  reference  model more c l o s e l y resembles the Pup a r c h i t e c t u r e  provides  alternative  communication  l a y e r of the model. I t i s due to layered  modular  structuring  communication modules model.  that  provides  i n that i t  s e r v i c e components at each  the  and  model.  versatility  the  of  run-time  interchangeability  the  flexibility  of  of the  84  5.2  Future Research  The many  design  It  we  established  independent  have d e s c r i b e d  communication  layer construction  presents  interesting layer  Areas.  some new research  (module)  within  design  and  this thesis  techniques  utilizes such  f u n c t i o n a l l y defined  as  modules.  communication system design concepts with  p o s s i b i l i t i e s . The p r o v i s i o n of  interface  provides  the  a  uniform  communication  designer with a powerful t o o l f o r the design and  system  implementation  of communication, system components and a p p l i c a t i o n s .  The  uniform i n t e r f a c e i s used at the a p p l i c a t i o n i n t e r f a c e  l e v e l and the intermodule i n t e r f a c e . The a p p l i c a t i o n can use the same i n t e r f a c e conventions to access the at  the  support  level  specific  performance  services  at  the  cannot be met the  Pup  uniform current  required  application  applications.  interface  access to the t r a n s p o r t  Much  if  directly the s e r v i c e  dependent  to  An  applied  the X.25  apply  these  requirements As  services of  l e v e l within  i n Verex would allow d i r e c t  in  communication  extension  transport  system  requiring  be s e l e c t i v e l y a p p l i e d as r e q u i r e d and new  implementation  therefore  level  can  Applications  by e x i s t i n g communication s e r v i c e modules.  f o r new I/O  requires.  requirements  architecture,  s e r v i c e s may developed  it  commmunication  the the  applications  l e v e l . Higher l e v e l p r o t o c o l overhead i s  reduced to a minimum.  work  needs  number of p r o t o c o l  to  be  done  in assembling a reasonable  support modules that would form the b a s i s f o r  the communication support s e r v i c e s . An  interesting  application  85 within  the  Verex  system  would  --message passing c a p a b i l i t i e s  be to extend  (supported  the i n t e r p r o c e s s  by the Verex kernel)  to  allow remote process message based communication. D i r e c t message passing  between a process and  remote process) The  remote  process) length than  would be supported  process agents (one  the f i x e d  processes,  The  'agent' ( r e p r e s e n t i n g the  by l o c a l  kernel  (not supported message  thereby  length  eliminating  operations.  r e p r e s e n t i n g each p a r t i c i p a t i n g  communicate using a remote message messages  transfer  a local  protocol.  Variable  w i t h i n Verex) allow data  longer  to  remote  be  passed  between  the need f o r i n t e r p r o c e s s data  facility.  multilayered  communication  system  design  imposes  a d d i t i o n a l p r o c e s s i n g overhead at each l a y e r i n t e r f a c e when data must  be  address [Chesley  moved  across l a y e r boundaries  spaces. A means of and  Hunt  1981])  data  sharing  would  which may (as  span  used  significantly  overhead. Data sharing i n c r e a s e s the interdependence  separate  in  Squire  reduce of  separate  l a y e r s , 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 but  this  reducing the system overhead i n c u r r e d i n data movement.  task,  86 Bibliography.  [ Abraham and D a l a i 1980 ] Steven M Abraham and Yogen K D a l a i . Techniques f o r D e c e n t r a l i z e d Management of D i s t r i b u t e d Systems.. IEEE Comcon 80 S p r i n g . San F r a n c i s c o Feb 25-28 1980. [ Bachman 1978 ] C h a r l e s W Bachman. Domestic and I n t e r n a t i o n a l Standards A c t i v i t i e s for D i s t r i b u t e d Systems. IEEE Compcom 78 F a l l . Washington Sept 5-8, 1978. [ Bachman and Canepa 1978 ] C h a r l e s Bachman and Mike Canepa. The Session C o n t r o l Layer of an Open System I n t e r c o n n e c t i o n . 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 T a f t and R.M M e t c a l f e . Pup: An Internetwork A r c h i t e c t u r e . IEEE T r a n s a c t i o n s on Communications. A p r i l 1980 [ Berglund 1978 ] Ralph G Berglund. Comparing Network A r c h i t e c t u r e s . Datamation. Feb 1978. [ Burkhardt and S c h i n d l e r 1981 ] H J Burkhardt and S S c h i n d l e r . S t r u c t u r i n g P r i n c i p l e s of the Communication of Open Systems - A Systematic Approach. Computer Networks. May 1981. [ CCITT 1980 ] CCITT Study Group V I I . D r a f t Revised CCITT Recommendation X.25. Computer Communications Review. J a n / A p r i l  Architecture  1980.  [ C h e r i t o n 1979 ] David R C h e r i t o n . M u l t i - P r o c e s s S t r u c t u r i n g and the Thot'h Operating System U n i v e r s i t y of B r i t i s h Columbia. Department of Computer Science T e c h n i c a l Report 79-5. 1979.  87 [ C h e r i t o n 1981 ] David R C h e r i t o n . D i s t r i b u t e d I/O using an Object-based P r o t o c o l . U n i v e r s i t y of B r i t i s h Columbia. Department of Computer Science. T e c h n i c a l Report 81-1, [ Chesley and Hunt 1981 ] H R Chesley and V B Hunt. Squire - A Communications-Oriented Operating Computer Networks. V o l 5. No 5. Sept 1981.  1981.  System.  [ Datapac 1978 ] The Computer Communications Group; TransCanada Telephone System. Datapac I n t e r a c t i v e Terminal I n t e r f a c e . Oct 1978. [ Day 1979 ] John D Day. Resource Sharing P r o t o c o l s . Computer. Sept 1979. [ Deering 1981 ] Stephen Deering. A Message Based Design f o r X.25 Software.. U n i v e r s i t y of B r i t i s h Columbia. Department of Computer S c i e n c e . M.Sc. T h e s i s  ( i n progress)  1981.  [ d e s J a r d i n s 1981 ] Richard d e s J a r d i n s . Overview of the ISO Reference Model of Open Systems Interconnection. Computer Communications Review. A p r i l 1981. [ d e s J a r d i n s and White 1980 ] Richard d e s J a r d i n s and George W White. ISO/ANSI Reference Model of Open Systems I n t e r c o n n e c t i o n . IEEE Trends and A p p l i c a t i o n s : Computer Network P r o t o c o l s 1980. [ F l e t c h e r and Watson 1980 ] John G. F l e t c h e r and Richard W Watson. S e r v i c e support in a Network Operating System. IEEE Compcon 80 S p r i n g . San F r a n c i s c o Feb 25-28  1980.  [ G r i e b 1980 ] Gertrude P G r i e b . Open Systems I n t e r c o n n e c t i o n Management and A p p l i c a t i o n Layer P r o t o c o l Issues. IEEE I n t e r n a t i o n a l Conference on Communications. S e a t t l e June 8-12 1980.  88 [ Heafner and Wood 1980 ] John F Heafner and Helen M Wood. ISO P r e s e n t a t i o n Layer P r o t o c o l Issues. IEEE i n t e r n a t i o n a l Conference on Communications.. S e a t t l e June 8-12 1980. [ H O l l i s 1980 ]• Lloyd L H o l l i s . Open Systems I n t e r c o n n e c t i o n Upper Layers A c - t i v i t y . IEEE Compcon 80 F a l l . Washington Sept 23-25 1980. [ ISO 1980 ] ISO/TC97/SC16/N537. Open Systems I n t e r c o n n e c t i o n - Basic Reference Model. Computer Communication Review. A p r i l 1981. [ Lauer ] Hugh C Lauer. D e c e n t r a l i z e d Assignment Xerox C o r p o r a t i o n .  of Names i n Networks.  [ Lockhart 1979 ] T W Lockhart. The Design of a V e r i f i a b l e Operating System K e r n e l . U n i v e r s i t y of B r i t i s h Columbia. Department of Computer S c i e n c e . T e c h n i c a l Report 79-15, 1979. [ McGovern 1980 ] Joseph P McGovern. A D i s t r i b u t e d Communications A r c h i t e c t u r e . IEEE Trends and A p p l i c a t i o n s 1979. G a i t h e r s b u r g May 17, 1979. [ McGovern and Basu 1980. ] Joseph P McGovern and Dipak Basu. Middle Layers of Open System I n t e r c o n n e c t i o n : Session and T r a n s p o r t . IEEE Compcon 80 F a l l . Washington Sept 23-25 1980. [ Moulton 1980 ] James Moulton. High L e v e l P r o t o c o l Boundaries i n the ISO Model. IEEE Trends and a p p l i c a t i o n s : Computer Network P r o t o c o l s , 1980. [ Pouzin and Zimmermann 1978 ] L o u i s Pouzin and Hubert Zimmermann. A T u t o r i a l on P r o t o c o l s . Proceedings of the IEEE. Nov 1978.  89  [ S c h i n d l e r 1981 ] S Schindler. Open Systems, Today and Tomorrow - A Personal Computer Networks. May 1981.  Perspective.  [ Shoch 1978 ] John F shoch. Internetwork Naming, Addressing and Routing. IEEE Compcon 78 F a l l . Washington Sept 5-8 1978. [ S p r o u l l and Cohen 1978 ] Robert F S p r o u l l and Dan Cohen. High L e v e l P r o t o c o l s . Proceedings of the IEEE. Nov 1978. [ S t e e l 1980 ] Thomas B S t e e l . CCITT P e r s p e c t i v e s on Higher L e v e l P r o t o c o l s . IEEE I n t e r n a t i o n a l Conference on Communications. S e a t t l e June 8-12 1980. [ T r i p a t h i 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 D i r e c t i o n s i n D i s t r i b u t e d P r o c e s s i n g . IEEE Compcon 80 F a l l . Washington Sept 23-25 1980. [ Walden and McKenzie 1979 ] David C Walden and Alexander A McKenzie. The E v o l u t i o n of Host-to-host P r o t o c o l Technology. Computer. Sept 1979. [ Zimmermann 1980 ] Hubert Zimmermann. OSI Reference Model - The ISO Model of A r c h i t e c t u r e for Open Systems I n t e r c o n n e c t i o n . IEEE T r a n s a c t i o n s on Communications. A p r i l 1980.  90  Appendix A.  The  sequence  performing  the  illustrated level  Session  of  Reconnection Sequence.  actions  session  in  taken  reconnection  F i g . 12.  The  by  the  is  ITI server when  given  below  and  steps that f o l l o w the t r a n s p o r t  f a i l u r e may be broken up i n t o the f o l l o w i n g four phases.  1. O r i g i n a l ITI server  detects  transport  system  failure  and  blocks a l l user a p p l i c a t i o n s . (a)  The  ITI server  is notified  the d e s t r u c t i o n connection X.25  of  release  read  the  of an exception  timer  status  process.  i s returned  c o n d i t i o n by  The  transport  on the f o l l o w i n g  request.  (b) Any.outstanding or a d d i t i o n a l blocked.  Requesting  application  applications  requests  are  must await ITI server  reply. (c) The ITI server session  server.  authorized timeout  sends a  suspension  The  ITI  to reconnect  server  until  by the s e s s i o n server or a  local  occurs.  Verification  of  reconnection  original  and  login  (b) A l o g i n is  the  and higher  level  services.  user and a u t h o r i z a t i o n to proceed  i s performed by s e s s i o n  (a) A new incoming c a l l causes  t o the  remains blocked  2. E s t a b l i s h new t r a n s p o r t connection  with  notification  server.  i s r e c e i v e d by the X.25  generation  level.  This  of new upper l a y e r s i n c l u d i n g ITI  servers.  request  verified  i s sent  to  be  to the s e s s i o n s e r v e r .  the  The  user  same as that whose s e s s i o n was  91  suspended. (c) The suspended ITI server reconnect (d) The  i s returned  and w i l l await a reconnection  session  initiate  server  replies  reconnection  server.  of connection The  ITI  supported  3. S y n c h r o n i z a t i o n  (a)  the  login  server.This  is a  by the ITI server  to  non-standard I/O  only.  handshaking between ITI s e r v e r s and  transfer  ownership to the p r e v i o u s l y suspended s e s s i o n .  'new'  ITI  s e r v e r sends a 'RECONNECT QUERY  1  the suspended ITI server  proceed.  If  the  t o e s t a b l i s h that  that  the  suspended ITI server  a c t i v e a 'RECONNECT UNSUCCESSFUL' r e p l y login  to the  i s s t i l l active.  (b) The suspended ITI s e r v e r r e p l i e s  the  to  (suspended) ITI  the ITI server to reconnect  suspended ITI s e r v e r . T h i s i s necessary  . may  server  •  suspended  request  to  request.  to the i d e n t i f i e d  (e) The l o g i n server requests the  the a u t h o r i z a t i o n to  reconnection i s no longer  i s returned  to  serve causing a new a p p l i c a t i o n s e s s i o n to be  established. (c) The X.25 server the  transport  i s requested level  t o a l t e r the 'ownership'  connection  of  to  the  previously  request.  If  successful  suspended ITI s e r v e r . (d) The X.25 server r e p l i e s t o t h i s reconnection  continues.  I f u n s u c c e s s f u l a new a p p l i c a t i o n  session i s established. (e)  The  suspended ITI server  the t r a n s p o r t l e v e l  i s informed  that i t now 'owns'  connection.  (f) The suspended ITI server n o t i f i e s the X.25 server of the break  process  that  i s to be destroyed  f o r asynchronous  92 event  notification.  (g) The  X.25  server  r e p l i e s to t h i s  (h) The  suspended ITI server r e p l i e s to the  that the reconnect 4.  Reconnection  reply  request.  status.  request  i s made to the s e s s i o n  (a) The  l o g i n server The  ITI  server  i s complete. If  successful  s e r v i c e s are r e l e a s e d . If u n s u c c e s s f u l  reconnect.  new  the now  another l o g i n  unused service  server.  i s given a r e p l y i n d i c a t i n g a s u c c e s s f u l login  server  and  new  ITI  server  are  released. (b) The  previously  outstanding new  transport  suspended  requests level  and  ITI  server  accepts  connection.  I/O  replies requests  to using  any the  93  Session  server 2(b) 2(d) V  Application  1 (b)  Login  1 (c)  server  2(e)  c)  4(a)  4(b) V  V <—3(a)--3(b)—> .<—3(e) — 3(h)—>  ITI server (new) A 3(d)  3 c)  I  V  X.25  server  A 2U)  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}]}"
                            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:
http://iiif.library.ubc.ca/presentation/dsp.831.1-0051824/manifest

Comment

Related Items