UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Implementations of user mobility support for UPC in JAVA/CORBA environment Huynh, Thong Tri 1999

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

Item Metadata

Download

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

Full Text

Implementations O f User Mobility Support for U P C in J A V A / C O R B A Environment by Thong Tri Huynh B . A . S c . , University of B r i t i s h Columbia,1993 B . S c , University of B r i t i s h C o l u m b i a , 1996  A THESIS S U B M I T T E D INPARTIAL F U L F I L L M E N T O F THE REQUIREMENTS FOR T H EDEGREE OF  M a s t e r of Science in T H E F A C U L T Y O FG R A D U A T E STUDIES (Department o f C o m p u t e r Science)  we accept this thesis as conforming to the required standard  The University of British Columbia A u g u s t 1999 © T h o n g T r i H u y n h , 1999  In presenting this thesis/essay in partiaCfuCfiCCment of the requirements for an advanced degree at the University of British CoCumBia, I agree that the Library shaCC make it free Cy avaiCaBCe for reference and study. I further agree that permission for extensive copying for this thesis for schoCarCy purposes may Be granted By the 3-Cead of my department or By his or her representatives. It is understood that copying or puBCication of this thesis for financiaCgain shad not Be adowed without my written permission.  X a Date  Computer Science The 'University of 'British CoCumBia 2366 Main maCC yancovuer, 2?C Canada \6T 1Z4 .  SO  X  Q  1 1  Abstract T h i s thesis addresses the specification and implementation of the U n i v e r s a l Personal C o m p u t i n g ( U P C ) environment, developed at U B C for support of user mobility. In the U P C c o m p u t i n g environment, each user has a unique global identification w i t h which the user can access network services, c o m p u t i n g resources, personal applications, d a t a files, and environmental configuration through any t e r m i n a l , stationary or mobile, wired or wireless networking, anywhere on the Internet. In this thesis, we produced the specification of the U P C ' s Registration and Service Negotiation P r o t o c o l ( R S N P ) using the Specification and Description L a n guage ( S D L ) and simulated the R S N P using a S D L supported t o o l . A s an initial attempt to verify the concept, we implemented the U P C protocol and a graphical user interface using C and T c l / T k as the programming language.  CORBA  and  J a v a offers an alternative approach in modelling the U P C concept t h a t is flexible and portable to any c o m p u t i n g platform. A U P C prototype is implemented using C O R B A as the architecture framework and J a v a as the p r o g r a m m i n g language.  Contents  Abstract  ii  Contents  iii  List of Figures  vi  Acknowledgements  vii  1 Introduction  1  1.0.1  Motivation  1  1.0.2  Thesis Objectives and C o n t r i b u t i o n s  4  1.0.3  Thesis O u t l i n e  6  2 Background  7  2.1  M o b i l e Host P r o t o c o l for I P (Mobile-IP)  2.2  Specification Description Language ( S D L )  10  2.3  Universal Personal C o m p u t i n g ( U P C )  11  2.3.1  User Identification  12  2.3.2  User Profile  12  2.3.3  T e r m i n a l Identification  13  iii  7  2.4  2.5  3  2.3.4  T e r m i n a l Profile  13  2.3.5  U P C Network A r c h i t e c t u r e  13  2.3.6  Registration and A u t h e n t i c a t i o n  15  Introduction to C O R B A  .  16  2.4.1  Interface Definition Language ( I D L )  18  2.4.2  Object Request B r o k e r ( O R B )  19  2.4.3  C O R B A Object Services ( C O R B A s e r v i c e s )  20  2.4.4  T h e C O R B A C o m m o n Facilities ( C O R B A f a c i l i t i e s )  22  CORBA-based U P C  . . . .  22  2.5.1  Facility object  23  2.5.2  Personal C o m p u t i n g E n v i r o n m e n t ( P C E ) object  2.5.3  T e r m i n a l Profile object  2.5.4  User Agent ( U A ) object  24  2.5.5  T e r m i n a l A g e n t ( T A ) object:  25  2.5.6  Initial A g e n t ( I A ) :  25  . . . . . . . . ,  U P C ' s R e g i s t r a t i o n a n d Service Negotiation P r o t o c o l ( R S N P )  23 24  27  3.1  Overview  27  3.2  U P C Protocol Architecture Modification  29  3.3  S D L Specification of R S N P  31  3.4  . . . . . .  3.3.1  Pseudo M o b i l e - I P Block . ' . . .  35  3.3.2  M o b i l e User B l o c k  36  3.3.3  User Foreign Agent B l o c k  3.3.4  User Home A g e n t B l o c k  .  38 . 4 1  P r o t o t y p e Implementation of U P C . 3.4.1  Assumptions and Requirements: iv  41 . . . . . . . .  45  3.4.2  Registration and Service Negotiation Procedure  3.4.3  Re-registration after E x p i r a t i o n of Connection Lifetime  3.4.4  Re-registration after Hand-ofF .  3.4.5  D a t a g r a m F o r m a t used in Registration and Service Negotiation P r o t o c o l  4  . . .  47 48  • • • •  48  CORBA-based U P C Prototype Implementation 4.1  5  46  52  C O R B A - b a s e d U P C P r o t o t y p e Implementation  52  4.1.1  Personal C o m p u t i n g E n v i r o n m e n t ( P C E )  54  4.1.2  User H o m e A g e n t ( U H A )  54  4.1.3  T e r m i n a l Profile  4.1.4.  T e r m i n a l Agent ( T A )  58  4.1.5  Initial A g e n t  60  4.1.6  Testing and Results  63  Conclusion and Future Works  .  55  66  5.1  Conclusion  66  5.2  Future W o r k s  68  Bibliography  70  Appendix A  75  List of Figures  2.1  C O R B A Object Architecture [23] .  17  2.2  I D L Language Bindings P r o v i d e Interoperability [23]  2.3  O R B structure [23]  2.4  C o l l a b o r a t i o n of agents in the C O R B A - b a s e d U P C framework [30]  3.1  System D i a g r a m of U P C ' s Registration and Service Negotiation P r o -  .  •.  18 20  .  26  tocol  32  3.2  Block D i a g r a m of a Pseudo M o b i l e - I P  36  3.3  B l o c k D i a g r a m of a M o b i l e User  3.4  M o b i l e User Agent's Extended F i n i t e State M a c h i n e  39  3.5  B l o c k D i a g r a m of a User Foreign Agent  40  3.6  User Foreign Agent's Extended F i n i t e State M a c h i n e  42  3.7  Block D i a g r a m of a User Home Agent  43  3.8  User Home Agent's Extended F i n i t e State M a c h i n e  44  4.1  M a i n screen of the Service Manager utility  57  4.2  Login screen of the U P C  4.3  U P C A p p l i c a t i o n Manager screen .  . . .  ; . ,  vi  '.  37  .  61 62  Acknowledgements I would like to take this o p p o r t u n i t y to thank D r .  Son V u o n g , my supervisor,,  who has guided, supported and encouraged me throughout the M a s t e r program and especially this thesis.  I would also like to thank my second reader, D r .  George  T s i k n i s , for the time and valuable suggestions to this thesis. M a n y thanks to M a r i a Toeroe, J i n s o n g Z h u , and K a n g m i n g L i u for all the lengthy meetings and discussions on the U P C ' s issue. It has been a pleasure to work w i t h all of y o u . F i n a l l y , I thank my parents and my sisters for their love and support on every stage of my education.  T H O N G TRI H U Y N H  The University August  of British  Columbia  1999  vii  Chapter 1  Introduction 1.0.1  Motivation  In recent years, the term "Internet" has become a household w o r d . T h e cost of connecting to the Internet has become affordable for everyone, and most people work in an environment where their desktop computer is connected to the Internet. Internet applications such as E m a i l , W o r l d W i d e W e b , Internet chat (e.g. I R C , Microsoft C h a t ) , Internet video conferencing (e.g.  CuSeeMe, S D R , NetMeeting),  and Internet radio (e.g. R e a l P l a y e r ) are widely used on computers at home and at work. Meanwhile, portable computers have become more compact, yet more powerful, w i t h increased processing and storage capabilities. T h e y are available in i n creased diversity, ranging from laptop, to notebook and palmtop computers.  In  addition, the communication capabilities of these portable computers are impressive as high-speed modems, P C M C I A modem, and gigabit satellite access, and so on become more common [1]. A t ' the same time, wireless technology has grown significantly, especially  1  wireless technologies for L A N s . In the market place we can find inexpensive highspeed wireless L A N products, in addition to low-speed wide area wireless network and medium-speed metropolitan area wireless network services. T h i s availability of wireless network services enables mobile users with portable computers to remain connected to the Internet anywhere at any time. Nowadays, people are constantly on the move. M a n y people are m o v i n g between offices, homes, automobiles, conference rooms, and so forth. W h i l e they are on the move, they may want to be able to perform c o m p u t i n g a n d / o r communicat i o n . A s they move around, they may have access to enormous c o m p u t i n g facilities such as advanced workstations, desktop computers, compact P D A s (Personal D i g i t a l A s s i t a n t ) , and convenient locally available services, such as faxes and printers. However, they often find themselves de-coupled from their familiar "home base" c o m p u t i n g environment when using these foreign c o m p u t i n g facilities. I t . w o u l d be better if the user could have the same personal c o m p u t i n g environment, regardless of the computer's platform, the computer's location, or the user's l o c a t i o n . T h e combination of increasing use of portable computers, the rapid advancement of wireless c o m m u n i c a t i o n technologies, and the fact that most users are mobile, requires a special c o m p u t i n g environment that supports mobile c o m p u t i n g . M o b i l e c o m p u t i n g refers to an area of technology t h a t aims at p r o v i d i n g access to c o m p u t i n g resources, independent of motion, location, c o m p u t i n g platform, communication device, and communication b a n d w i d t h . T h e independence refers to theconcept of a c o m p u t i n g environment that automatically adjusts to the processing, communications and access available at any moment. Ideally, a user can travel from place to place and still use the c o m p u t i n g facilities they desire in their new location or even while they are on the move.  2  Currently, a user can o b t a i n mobile c o m p u t i n g by installing a cellular telephone interface into their p o r t a b l e computer and running a protocol such as S L I P •or P P P over a dialup service. T h i s approach is simple and cheap; however, there is a severe l i m i t a t i o n in t h a t the user can only access Internet resources within a single administrative d o m a i n . T h i s l i m i t a t i o n is due to the Internet's inability to ' s u p p o r t mobility, neither user nor terminal mobility. In regards to terminal mobility, the current version of the Internet protocol is built, on an implicit assumption that the point at which a computer is attached to the Internet is fixed, and its I P .address uniquely identifies this point of attachment. T h e I P address is used by the Internet's routing protocol to deliver the I P packets to the intended receiver. W h e n a computer moves to a different network, its network services are lost because its I P address does not reflect its new point of attachment to the Internet, and the routing protocol is unable to correctly route the packets to it. In this situation, the computer must be reconfigured w i t h a new I P address associated w i t h the new network. D o i n g so causes the lost of already-established transport layer connections (for example, ftp or telnet sessions). Similar limitations apply to mobile users, where each user is registered to one administrative d o m a i n and granted a user login I D that allows the user to access only the c o m p u t i n g resources and network services in the registered administrative d o m a i n . A s the user moves to another administrative domain, they are not able to access any network services. ..-. Several approaches have been proposed and implemented to enhancing the Internet protocol to support mobility. A standard protocol (Mobile Host P r o t o c o l •for Internet Protocol) that supports terminal (or host) mobility has recently been defined by the Internet Engineering Task Force ( I E T F ) as in R F C 2 0 0 2 [25]. T h i s protocol is often referred to as mobile-IP. M o b i l e - I P allows a terminal to roam  3  freely on the Internet while still maintaining one permanent I P address. However, supporting only terminal mobility is not sufficient to provide a seamless mobile c o m p u t i n g environment. Even w i t h mobile-IP support, a mobile user still can not login to any available t e r m i n a l , stationary or mobile, in a foreign administrative d o m a i n . A s a result, this introduces a need for an additional level of mobility on top of terminal m o b i l i t y : user (or personal) mobility. Personal mobility is different from terminal mobility. T e r m i n a l mobility refers to the ability of a portable terminal to access services from any location while in m o t i o n , and the capability of the network to locate and identify the mobile terminal as it moves [10].  O n the other  hand,  personal m o b i l i t y refers to the ability of the end user to send and receive calls, and to access subscribed services on any terminal in any location, and the ability of the network to identify the end user as they move [10].  1.0.2  Thesis Objectives and C o n t r i b u t i o n s  S u p p o r t i n g both t e r m i n a l and personal m o b i l i t y is the fundamental requirement of mobile c o m p u t i n g ; however, very little work has been done to support personal mobility on the Internet. A new c o m p u t i n g paradigm t h a t supports both t e r m i n a l mobility and personal m o b i l i t y over the Internet, called Universal Personal Computing ( U P C ) , has been developed [20,35] j o i n t l y in the Department of C o m p u t e r Science and the D e p a r t m e n t of Electrical and C o m p u t e r Engineering of the University of B r i t i s h C o l u m b i a . . T h i s research constitutes a major activity of Internetworking Wireless D a t a Networks for M o b i l e C o m p u t i n g (TWIN), a project j o i n t l y funded by the N S E R C of C a n a d a and M o t o r o l a C a n a d a .  U P C is a c o m p u t i n g environ-  ment which enables a mobile user to access c o m p u t i n g resources, network services, personal applications, d a t a files, and environmental configurations through any ter-  4  m i n a l , stationary or mobile, anywhere on the Internet [21]. In this environment, terminal mobility and personal mobility are managed separately. T e r m i n a l mobility is supported using mobile-IP with some enhancements in T C P - c o n n e c t i o n management; whereas personal mobility is managed v i a an agent-based architecture. The  core of U P C ' s mobility management is the Registration and Service  Negotiation protocol ( R S N P ) . In this thesis, we use the Specification and Description Language ( S D L ) to produce a clear and precise specification of R S N P . W e also simulate R S N P using a S D L supported tool to verify for R N S P completeness and correctness. In a d d i t i o n , the R S N P s i m u l a t i o n can be used t o ' s i m u l a t e alternative solutions for any problems that come up. After having a concrete understanding of R S N P , we implement a U P C prototype using C and T c l / T k as the p r o g r a m m i n g language. In the proposed U P C architecture [21, 35] there are distributed components that can execute transparently to the host location, host platform and component implementation. T h e distributed nature of U P C ' s components makes the implementation of U P C very complex and even impossible. Fortunately, several technologies t h a t support platform independent distributed object architecture, such as C O R B A and D C O M , are available. C o m b i n i n g of concept of the U P C and C O R B A technology leads to a C O R B A - b a s e d U P C architecture as proposed in [30, 35]. In this new  architecture, the U P C components are modeled as distributed objects with  C O R B A as the object bus that facilitates the interaction, integration, and distribu-, tion of these objects. In this thesis, we implement a prototype of a C O R B A - b a s e d U P C system using J a v a as the p r o g r a m m i n g language, Visigenic's V i s i B r o k e r for J a v a as the C O R B A framework, and Sun M i c r o s y s t e m ' s Solaris 2.x as the. computing platform.  5  1.0.3  Thesis O u t l i n e  T h e rest of the thesis is organized as follows: • C h a p t e r 2 provides the necessary background material i n c l u d i n g mobile-IP, overview of the Specification and Description Language ( S D L ) , the concept of U P C , introduction to C O R B A , and C O R B A - b a s e d U P C . • C h a p t e r 3 presents U P C ' s R S N P formal specification using S D L , and a prototype of U P C ' s R S N P using C and T c l ' / T k . • C h a p t e r 4 presents the prototype the of C O R B A - b a s e d U P C . • C h a p t e r 5 concludes the thesis and discusses possible future works.  6  Chapter 2  Background 2.1  M o b i l e H o s t P r o t o c o l for I P ( M o b i l e - I P )  T h e current version of Internet P r o t o c o l (IP v 4 )  has been built on the implicit  assumption that the point of attachment of a computer to the Internet is fixed and uniquely identified by its I P address.  I P packets sent to a computer are delivered  based on the location information in the I P packet's headers, i.e^ the destination I P address.  W h e n a mobile computer moves to a new network, the I P address  that is configured in the computer does not reflect the new point of attachment. T h u s , the I P packets that are destined to this particular computer are incorrectly routed by the routing protocol.  To overcome this routing problem, the mobile  computer must be reconfigured with a new I P address that reflects the new point of attachment in the visiting network. Unfortunately, although the suggested method above may solve the routing problem, it presents two new problems.  T h e first  problem is the loss of any established transport and higher-layer connection during handoff when changing the I P address.  T h e second problem rests on the burden  7  of informing potential correspondents of the new I P address. Therefore, we need a new mechanism to support the mobility of a computer (often referred as host) over the Internet. M o b i l e Host P r o t o c o l for I P (Mobile-IP) is an enhancement to I P t h a t allows a mobile computer with a permanent I P address to communicate d a t a transparently to application software, and independent of its current point of attachment to the Internet.  T h e M o b i l e - I P is standardized by the Internet Engineering Task Force  ( I E T F ) as defined in the R F C 2 0 0 2 [25]. T h e standard M o b i l e - I P supports host mobility independent of the c o m m u n i c a t i o n medium in use. It works as effectively in a wireless environment as it does in a wired internetworking environment. T h e M o b i l e - I P architecture consists of a set of special entities called the M o b i l e Host [MH],- the H o m e A g e n t [ H A ] , and the Foreign Agent [FA]..  M o b i l e H o s t ( M H ) : A M H is defined as a host that changes its point of attachment to the Internet from one network to another.  E a c h M H belongs to a  unique home network and is assigned a permanent I P address. W h e n a M H is away from the home network, it is associated w i t h a t e m p o r a r y I P address that is often referred as a care-of I P address. T h e care-of I P address identifies the M H ' s current point of attachment to the Internet. A care-of I P address could be either the I P address of the F A that the M H is registered to, or a local I P address that is assigned to the M H at the visiting network.  H o m e A g e n t ( H A ) : H A is the router on a M H ' s home network that maintains the current location information (i.e. care-of I P address) for all mobile hosts under its a d m i n i s t r a t i o n . T h e H A is responsible for intercepting I P packets destined for a M H and tunnelling these IP packets to the M H v i a their care-of  8  address when the M H is away from the home network. F o r e i g n A g e n t ( F A ) : F A is a router on a M H ' s visited network. T h e F A is responsible for de-tunneling and delivering I P packets sent from the M H ' s H A to the registered M H . A F A also serves as a default router for I P packets sent by a registered M H .  T h e H A and F A advertise their presence in the network using an Agent A d v e r t i s i n g message.  T h e A g e n t A d v e r t i s i n g message is a router advertisement  message w i t h a special E x t e n s i o n attachment. W h e n a M H connects to a network, the M H receives the Agent Advertisement message and identifies whether its current point of attachment is on its home network or on a foreign network. If the M H is on its home network, there is no need for mobility services. However, i f the M H has just returned to its home network from a foreign network, de-registration w i t h the H A is required. A s a M H detects it is on a foreign network, it obtains its care-of I P address on the foreign network and uses a special registration protocol to keep its H A informed about its current location (i.e. care-of I P address). W h e n a M H is away from the home network, I P packets destined to it are always first sent to its home network, and then encapsulated by the H A and resent to the M H ' s current F A . E n c a p s u l a t i o n refers to the process of enclosing the original I P packet as d a t a inside another I P packet w i t h a new I P header.  The  routing information in the original I P packet, source and destination address, remain unchanged. T h e outer I P packet header specifies the M H ' s care-of I P address as the destination address and the M H ' s H A I P address as the source address.  The  encapsulated I P packet is then sent to the care-of I P address v i a a conventional I P routing mechanism. W i t h o u t I P encapsulation, I P packets meant for the M H  9  are always routed to the M H ' s H A by intermediate routers since all these packets have M H ' s permanent I P address as the destination address in their headers. U p o n receiving an encapsulated I P packet, the F A extracts-the inner I P packet from the encapsulated I P packet and delivers the extracted packet to the appropriate visiting M H on its local network. Conversely, when the M H sends I P packets, they are directly routed by the F A to their destination using conventional I P routing mechanisms.  Passing these  I P packets through the M H ' s H A is not necessary.  2.2  Specification D e s c r i p t i o n Language ( S D L )  T h e Specification Description Language ( S D L ) , developed and standardized  by  C o m i t e C o n s u l t a t i f International Telegraphique et Telephonique ( C C I T T ) , is a formal specification language. T h e S D L can be applied to specify a variety of systems from telecommunication systems, d a t a c o m m u n i c a t i o n systems, real time systems and interactive systems, to distributed systems. T h e S D L focuses on the reactive behaviour of a system. It is concerned w i t h how external s t i m u l i and responses are related at system interfaces, instead of the internal and physical construction of a system. T h e S D L can be used in both textual and graphical representations. T h e graphical S D L allows the user to specify a system using a set of diagrams that cover different levels of detail from a broad overview down to the detailed design level. T h e textual S D L looks similar to a p r o g r a m m i n g language.  Fragments of textual S D L can be embedded in diagrams where text is  more suitable or the graphical s y m b o l does not exist (e.g. signal declarations, d a t a declarations). In S D L , the top level of description is a system. A S D L system represents •••10  significant properties of a real life application system.  A n y t h i n g that is not part  of the S D L system is part of the environment. A t the top level, a first overview of the system is shown without getting into unnecessary details. In the S D L system we may have a single S D L block or a set of S D L blocks which are the building blocks of a system. These S D L blocks interact w i t h each other and the environment v i a channels. T h e S D L blocks build the system structure and allow decomposing a system into a hierarchy of levels in which each level represents a different level of abstraction. A S D L block may contain other S D L blocks or S D L processes. A Process is the lowest level description of a system; it can not be further decomposed. W e can describe S D L processes as extended. F i n i t e State Machines ( F S M ) . E a c h S D L process works autonomously and concurrently w i t h other S D L processes.  S D L processes  communicate w i t h each other using discrete messages called signals. E a c h signal has a name, sender identity, and possible additional data. T h e F S M uses the name of the signal to make a transition from one state to another state.  2.3  Universal Personal Computing ( U P C )  Universal Personal C o m p u t i n g ( U P C ) is a c o m p u t i n g paradigm that supports location independent network c o m p u t i n g over the Internet. U P C is a similar concept to Universal Personal Telecommunication ( U P T ) , w h i c h has been defined by the I T U - T , yet U P C caters to network c o m p u t i n g over the Internet, rather than telecommunications. In the U P C environment, each user has a unique global identification. U s i n g this identification, the U P C network enables users to access network services, computing resources, personal applications, d a t a files, and environmental configuration through any terminal, stationary or mobile, wired or wireless networking, anywhere  11  on the Internet.  2.3.1  U s e r Identification  In U P C , each user is assigned a Logical User Identifier ( L U I ) that is globally unique and independent of the user's current location. A s proposed in L i and L e u n g [21],a simple L U I could be a user's email address.  It is composed of the login user  ID of a user at their home network concatenated with the user's home domain address. U s i n g the email address as L U I has several advantages. F i r s t of all, email addresses are familiar to any Internet user; thus, it is easy to remember and reference. Secondly, the existing D N S could be used to resolve the user home agent's I P address from the user's home domain address p o r t i o n in the L U I . " T h i s obviates the need for global user-names server, and is compatible w i t h the current Internet architecture" [21].  2.3.2  U s e r Profile  A n o t h e r component of U P C is the User Profile.  E a c h mobile user has a service  profile kept in a user database at their home network. T h e service profile contains authentication information, such as the user login I D and the corresponding passw o r d . T h e service profile also defines a set of c o m p u t i n g resources, network services, and personal applications that a mobile user is entitled to while at home or on the road. F o r each personal application, c o m p u t i n g resource, or network service, there is a set of user preferences, such as environmental requirements, configuration, default settings, and so on. M o d i f y i n g or updating one's service profile can only be performed by an authorized network administrator, or by the user themselves. If necessary, the mobile user is allowed to remotely update or modify their service  12  profile while away from the home network.  2.3.3  T e r m i n a l Identification  In the U P C environment, each terminal is identified by a Logical T e r m i n a l Identifier ( L T I ) . In the current I E T F standard of M o b i l e - I P , each mobile t e r m i n a l ( M T ) is associated with two I P addresses, in particular the M T ' s permanent I P address and the M T ' s care-of I P address. T h e M T ' s permanent I P address is used in identifying the M T at the network level, and the M T ' s care-of I P address is used in discovering the M T ' s current location. I P packets addressed to a M T are redirected to the M T by tunneling to the M T ' s care-of I P address. Since we want to achieve backward, c o m p a t i b i l i t y w i t h the current Internet protocol suite, we selected the M T ' s permanent I P address as the M T ' s L T I , and the M T ' s care-of I P address provides the M T ' s current location. W e can then use the same tunneling mechanism as in mobile-IP to redirect packets to the M T ' s current location.  2.3.4  T e r m i n a l Profile  T h e t e r m i n a l profile is used to re-create the c o m p u t i n g environment specified by a user. E a c h mobile terminal has a t e r m i n a l profile kept in a t e r m i n a l database at the mobile terminal's home network. T h e terminal profile defines the capabilities on the terminal,.such as the resident operating system, the file format, the graphical user interface, the display mode and monitor resolution.  2.3.5  U P C Network Architecture  U P C network is an agent-based architecture that consists of three functional entities: a T e r m i n a l H o m e Agent ( T H A ) , a User H o m e . A g e n t ( U H A ) , and a Foreign A g e n t  13  (FA).  User Home Agent ( U H A ) : E a c h administrative domain has a User H o m e A g e n t . T h e U H A maintains a database of all the users registered i n this administrative domain as well as their associated user profiles. A l o n g w i t h the user profile, the U H A also keeps a record of all users' current location information. T h i s location information is a binding information between the mobile user (i.e. L U I ) , the terminal (i.e. L T I ) that the mobile user is currently using, and the current location of the terminal (i.e. care-of I P address). Whenever the user moves or changes their association w i t h a terminal, the location information is updated. Terminal Home Agent ( T H A ) : In addition to the U H A , each  administrative  domain has a T e r m i n a l H o m e A g e n t ( T H A ) . T h e T H A maintains a database of all the mobile terminals that the network is configured to serve, as well as their associated t e r m i n a l information, such as the terminal identity, the terminal profile, the t e r m i n a l authentication key, and the current location of the terminal (i.e. care-of I P address).  Foreign Agent (FA): If the administrative domain serves mobile users, it has a Foreign A g e n t . T h e F A enables the user and mobile terminal to be temporarily use the network so t h a t registration and authentication can proceed.  After  the user and terminal successfully register, the F A ' s main tasks are packet redirection and possibly caching pertinent parts of the user's service profile. A s part of network management, the F A maintains a list of all the mobile users and all the mobile terminals that are currently visiting the network.  14  2.3.6  Registration and Authentication  In the U P C environment, user mobility is handled independently from terminal mobility; thus, registration is separated into two registration procedures, terminal registration for the mobile t e r m i n a l and user registration for the mobile user. Terminal registration must be performed before user registration so that the terminal is recognized by the foreign network and ready for user registration. B o t h terminal registration and user registration are mandatory for any mobile user to access a mobile terminal in either their home network or a foreign network.  Terminal Registration In our terminal registration procedure, we adopt the M T ' s registration procedure as specified in M o b i l e - I P . T h e sequence of events for terminal registration is as follows: 1. T h e M T registers w i t h the F A in the visited network. 2. T h e F A contacts the M T ' s T H A to authenticate the M T and inform the T H A of the M T ' s new care-of I P address. 3. U p o n successful registration and authentication, the t e r m i n a l profile of the M T is transferred to the F A .  User Registration User Registration is similar to terminal registration, and follows the steps below:  1. T h e M U sends a registration request to the F A in the visiting network.  2. T h e F A contacts the M U ' s U H A to authenticate the M U . It also provides to the M U ' s U H A , the I P address of the M T ' s T H A that the M U is currently on.  15  3. - T h e M U ' s . U H A retrieves the M T ' s t e r m i n a l profile from the M T ' s T H A and then evaluates a set of suitable services for the M U . 4. U p o n successful registration and authentication, a set of services available for the M U at this particular M T is returned to F A , and then relayed to the M U .  2.4  I n t r o d u c t i o n to C O R B A  T h e C o m m o n Object Request B r o k e r A r c h i t e c t u r e ( C O R B A ) , proposed by the O b ject Management G r o u p ( O M G ) , is a new software technology that combines objectoriented technology and distributed client-server.computing to provide an i n d u s t r i a l standard distributed object architecture. C O R B A enables applications to interact with one another w i t h o u t knowing where the corresponding application resides, how the corresponding application is implemented, or what operating system the corresponding application is executed on.  .  C O R B A presents a strong, universal, powerful distributed object-oriented framework that makes software design easier. A n application that is developed using the C O R B A architecture is highly portable and interoperable across a heterogeneous distributed environment. C O R B A not only provides a framework for developing new applications, but it also provides a framework for integrating existing client/server applications. T h i s section provides a tour of major components of C O R B A such as the Interface Definition Language ( I D L ) , the Object Request Broker ( O R B ) , the C O R B A Object Services ( C O R B A s e r v i c e s ) , and the C O R B A C o m m o n Facilities ( C O R B f a cilities). F i g u r e 2.1 presents C O R B A ' s Object Architecture .  16  Common Facilities (CORBAfacilities)  Application Objects  Object Request Broker (ORB)  ^Trade^  R^lationshipfe  f^Query^  (^oltection^  ^Security)  lia^isactio^is  ^ime^  bcfricurrenc)  ^Events^  ficensing)  Ej/ernalizati^n  Common Object Services (CORBAservices) Figure 2.1: CORBA Object Architecture [23]  17  c  Client  + +  D C  , (smjj ^ J Ma  ^  0 B 0  |  0  Server  Object Request Broker (ORB)  F i g u r e 2.2: I D L Language B i n d i n g s P r o v i d e Interoperability [23]  2.4.1  Interface D e f i n i t i o n Language ( I D L )  In the C O R B A architecture, all objects are specified using the Interface Definition Language ( I D L ) . I D L is the key for interoperability in C O R B A . T h e I D L is a language t h a t is used to describe the external behaviour of an object w i t h o u t providing any underlying implementation details about an object. T h e I D L makes a s t r o n g separation between the specification of an object and the implementation of that object. Objects that use the interfaces published from another object have no idea how the object is implemented. T h u s , I D L enables an object w r i t t e n in one language to communicate w i t h another object w r i t t e n in an unknown language. F i g u r e 2.2 presents the I D L interoperability concept. The  I D L g r a m m a r uses the same lexical rules as 0 + + ,  introduced w i t h  several new keywords to support distributed-computing concepts. A n object's attributes, base classes that it inherits from, exceptions it raises, methods it supports, can all be specified using I D L . Objects specified using I D L can be mapped into a particular programming language or an object system. T h e I D L specifications are compiled into header files, stub, and skeleton programs which are used by a "bro-  18  ker".program (i.e. Object Request Broker) which allows the objects to communicate with one another.  2.4.2 The  Object Request B r o k e r ( O R B )  O R B is the central component of C O R B A . In the O S I network model, the  O R B sits between the d a t a and application layers. T h e O R B is an object bus that provides the mechanisms by which objects can make requests to other objects and receive responses from other objects. T h e caller object is often referred to as a client and the corresponding object is called a server. A t runtime, when a client object invokes a method in a server object, O R B is responsible for locating the server object implementation that-can implement the method, and then invoking the method and returning the results to the client object.  T h e client object does not have to be  aware of the server object's location, implementation, nor its operating system. The* O R B supports both static and d y n a m i c method invocations. T h e static method invocation interfaces are defined at compile time and presented to the client as stub code. T h e d y n a m i c method invocation interfaces are d y n a m i c a l l y discovered at run time using the C O R B A Interface Repository. A n Interface R e p o s i t o r y is an on-line database that contains real-time information describing all the interfaces that an object supports along w i t h its parameters.  T h e structure of the O R B is  shown in figure 2.3. A n O R B can run in standalone mode or can be interconnected to other O R B s in the universe. A l l the O R B s are interoperable v i a the Internet I n t e r - O R B P r o t o col ( H O P ) . " T h e H O P is basically a T C P / I P w i t h some C O R B A - d e f i n e d exchanges that serve as a c o m m o n backbone protocol" [23].  19  message  Object Implementation  A Static Skeletons  Dynamic Object Skeleton nvnnatinn Adapter  lm ilementati 31 Repository  O b j e c t R e q u e s t B r o k e r C o r e (MOP)  F i g u r e 2.3: O R B structure [23]  2.4.3  C O R B A O b j e c t Services ( C O R B A s e r v i c e s )  T h e t e r m C O R B A Object Services refers to fundamental (system-level) object i n terfaces that extend the functionality of O R B . T h e y are the most c o m m o n l y used services in building any application. T h e services provided by the C O R B A s e r v i c e s are highly diverse from creating an object, deleting an object from the O R B , and locating an object by its name or properties, to p r o v i d i n g operations for m o n i t o r i n g the use of an object. C u r r e n t l y , there are sixteen object services in C O R B A s e r v i c e s , as listed below.  The Life Cycle Service: defines the methods for creating, copying, moving, and t e r m i n a t i n g an object.  The Persistence Service: provides c o m m o n interfaces to persistently store the state of an object.  The Naming Service: locates an object by object name.  20  T h e E v e n t Service: supports the asynchronous c o m m u n i c a t i o n between objects using events. T h e C o n c u r r e n c y C o n t r o l : provides distributed locks on a given object. T h e T r a n s a c t i o n Service: provides two-phase c o m m i t coordination among objects. T h e Relationship Service: provides mechanisms to create, delete, navigate, and manage the d y n a m i c association between objects. T h e Externalization  Service: provides mechanisms to convert the state of an  object into a stream of d a t a and vice versa. T h e Q u e r y Service: provides query operations for objects. T h e Licensing Service: provides operations for m o n i t o r i n g the use of an object. T h e P r o p e r t i e s Service: provides mechanisms to associate properties to an object. T h e T i m e Service: supports time synchronization in a distributed object environment.  T h e Security Service: offers a framework for distributed object security. T h e T r a d e r Service: matches or locates an object by its properties. T h e Collection Service: provides interfaces to create and manage the most common collections. T h e S t a r t u p Service: starts up an object when an O R B is invoked.  21  2.4.4  T h e C O R B A C o m m o n Facilities ( C O R B A f a c i l i t i e s )  T h e C O R B A C o m m o n Facilities are similar to the C O R B A Object Service, but they are at a higher-level and oriented towards end-user applications. T h e y are related to and extended from the existing C O R B A s e r v i c e s .  T h e C O R B A f a c i l i t i e s is still  under construction.  2.5  CORBA-based U P C  In the-latter phase of the I W I N project at U B C , C O R B A was incoporated into U P C to exploit the advantages of flexibility and versaltality that C O R B A ' s distributed object architecture offered [30, 35]. In C O R B A - b a s e d U P C , all the entities in the U P C architecture (i.e. U H A , T H A , and F A ) are presented as distributed objects. These objects move relative to the current location of the user.  The Common  Object Request B r o k e r Architecture, C O R B A , is selected as a middleware layer that provides a homogeneous distributed c o m p u t i n g environment independent from the underlying hardware and software technology. In addition to providing a homogeneous distributed c o m p u t i n g environment, C O R B A also defines a set of C o m m o n Object Services ( C O R B A s e r v i c e s ) and C o m mon Facilities ( C O R B A f a c i l i t i e s ) t h a t provide building blocks for developing any C O R B A based application. T h e C O R B A s e r v i c e s support generic and c o m m o n functionality, such as creating an object, n a m i n g an object, and resolving the reference of an object. T h e C O R B A f a c i l i t i e s are the frameworks that provide services directly used by the application objects. T a k i n g advantage of the availability of C O R B A s e r vices and C O R B A f a c i l i t i e s , the C O R B A - b a s e d U P C system can utilize some of the core services provided by the C O R B A s e r v i c e s , such as the Life C y c l e Service, the  22  N a m i n g Service, the Trader Service, the Security Service, the Persistence Service, and the Relationship Service. In the C O R B A - b a s e d U P C approach, t e r m i n a l mobility is handled by the M o b i l e - I P . T e r m i n a l migration in M o b i l e - I P is transparent to the T C P and the higher network layers in the O S I model.  Since C O R B A sits above the  TCP/IP  layer, t e r m i n a l migration is also transparent to C O R B A . Therefore, the C O R B A based U P C only focuses on the issue of user mobility. The C O R B A - b a s e d U P C system consists of the following major objects: the Facility object, the Personal C o m p u t i n g E n v i r o n m e n t object ( P C E ) , the T e r m i n a l Profile object, the User A g e n t object ( U A ) , the T e r m i n a l A g e n t object ( T A ) , and the Initial A g e n t object ( I A ) .  2.5.1  F a c i l i t y object  A facility object is a representation of a c o m p u t i n g resource, a network service, or a software application in the system. A facility object is self-descriptive so it can be queried by other objects for supported services and for how to invoke these services. A facility can be either a personal facility, or a shared facility between a group of users. A personal facility is user specific and only available to a specific user at their home network. O n the other hand, a shared facility is specialized for a group of users and available on a certain network. T o a great extent, a shared facility can be general-purpose and available for everyone, everywhere.  2.5.2  Personal C o m p u t i n g E n v i r o n m e n t ( P C E ) object  E a c h user has a Personal C o m p u t i n g E n v i r o n m e n t ( P C E ) . A P C E is a set of facility objects that a user wishes to use when they are away from their home network.  23  A P C E is a persistent object that can be facilitated by the C O R B A ' s Persistence Service. W h e n a user visits a foreign network, their P C E is retrieved and mapped into the facilities that are available at the login terminal (i.e. the T e r m i n a l Profile object). T h e result is a subset of the requested facilities in the user's P C E , referred to as a user's terminal specific P C E .  2.5.3  T e r m i n a l Profile object  E a c h t e r m i n a l has a terminal profile object kept locally at the t e r m i n a l that defines the capabilities of the t e r m i n a l . B o t h the terminal's physical and software capabilities are specified in the t e r m i n a l profile object. B y P h y s i c a l capabilities, we refer to the physical properties of a t e r m i n a l , such as the size of the R A M , the size of the memory in the video card, the monitor mode, and the monitor resolution. Software capabilities refers to the facilities available locally at the t e r m i n a l .  2.5.4  U s e r A g e n t ( U A ) object  E a c h user has a U A object that acts on behalf of the user i n the system. U A object's main task is to manage a user's P C E object.  The  In a d d i t i o n , the U A  object provides interfaces to authenticate a user and to retrieve a user's P C E object once the user is authenticated. T h e U A object is a persistent object facilitated by C O R B A ' s Persistence Service, and is bound to the user' L U I i n C O R B A ' s N a m i n g Services. T h u s , an U A object can be located from a user's L U I w i t h the assistance of the C O R B A ' s N a m i n g Service.  24  2.5.5  Terminal Agent (TA) object:  •Each terminal has a T A object that represents the user at the foreign network. T h e T A object has a reference to the user's t e r m i n a l specific P C E object (i.e. the subset of a user's P C E that is supported by the current login terminal) which the T A object is responsible to m a i n t a i n . Moreover, the T A object is also responsible to discover all the facilities t h a t are available at the visiting network, using both  CORBA's  N a m e Service and C O R B A ' s Trader Service.  2.5.6  Initial Agent (IA):  A n initial agent is an active process that runs at a t e r m i n a l and provides the start up procedure for users. F i r s t the I A authenticates a login user based on C O R B A ' s Security Service. W i t h the assistance of C O R B A ' s N a m e Service, the I A then finds the user's U A object.  After locating the user's U A object, the I A initiates the  creation of a T A object and a user's t e r m i n a l specific P C E object at a t e r m i n a l . F i g u r e 2.4, adopted from [30], shows the collaboration of agents in the C O R B A - b a s e d U P C system.  25  Initial User Interface  User Menu  Figure 2.4: Collaboration of agents in the CORBA-based UPC framework [30]  26  Chapter 3  UPC's Registration and Service Negotiation Protocol (RSNP) 3.1  Overview  In this chapter we present the specification and prototype implementation of U P C ' s Registration and Service Negotiation P r o t o c o l ( R S N P ) . R S N P was specified using the Specification and Description Language ( S D L ) . W i t h the use of S D L , we were able to produce an unambiguous, precise, and concise specification of R S N P . There are several formal specification techniques available to specify and model the behavior of a system, such as Language of T e m p o r a l O r d e r i n g Specifications and Estelle F o r m a l Description Technique.  (LOTOS)  However, we chose S D L as the formal  specification language for R S N P due to the following reasons: • S D L is a recognized international standard and accepted by I S O (International Standards Organization). T h i s fact ensures that S D L will be maintained and supported in the future.  27  • S D L is popular and widely used in the telecommunication industry. • T h e graphical S D L is intuitive and easy to work w i t h . It clearly displays the relationships between blocks, processes and how they interact. • T h e nature of S D L is suitable for specification of a communication protocol since the S D L process is described as E x t e n d e d F S M . T h e F S M is an excellent model for any communication protocol design. In regards to the S D L tool, we used the t o o l developed at the K F K I Research Institute for Measurement and C o m p u t i n g Techniques in Hungary. T h i s S D L t o o l is a part of a tool set called P R O C O N S U L (i.e.  P R O t o c o l C O N S U L t a n t ) . and  consists of a S D L simulator and language sensitive editor that supports the g r a m m a r of the S D L 1992 version. T h e editor has a s y n t a x checker, which helps to create syntactically correct S D L specification. T h e S D L simulator represents a S D L system as a block d i a g r a m , and displays the output of the simulation in the form of a time diagram or a message sequence chart ( M S C ) . W e can step through the simulation execution and simulate different scenarios by changing a variable value, changing the delay time for a channel, and even adding to or deleting signals from the signal queue. F o r example, we can simulate a loss of message by removing it from the signal queue, or we can simulate the protocol behaviour during a network congestion period by simply increasing the delay time in a channel. W i t h the use of the S D L simulator we checked for R S N P specification's completeness and correctness.  In addition to  this, we were able to simulate alternative solutions for any problems t h a t come up.  28  3.2  U P C Protocol Architecture Modification  R S N P is specified w i t h several modifications to the architecture as well as additions of new entities, as compared to the U P C protocol architecture mentioned in section 2.3. T h e modifications and their justification are as follows:  • T e r m i n a l related information such as the terminal identity and the terminal profile are kept locally at the t e r m i n a l . T h e terminal identity is the permanent I P address of a t e r m i n a l . T h e t e r m i n a l profile is basically t h e terminal configuration information, such as resident operating system, file format, and monitor display mode, and so o n . T h i s information is currently available at any terminal so there is no need to replicate the information at the T H A . T h i s alleviates the need for database management in the T H A . • W e extended the terminal profile to store information about software applications locally available at this particular terminal, such as the name of the application, the type of the application, the path of the executable file of the • application, and the mapping information for a mobile user's preference and configuration files. T h e mapping information maps a mobile user's preference and configuration file for an application on the home network, to the preference and configuration file for an application available on the foreign t e r m i n a l .  • Since the terminal profile is kept locally at the terminal, there is no need for a Terminal Home Agent. • W e introduce a new agent, called M o b i l e User A g e n t . T h i s agent runs locally at a terminal and provides a login interface to users. T h e M o b i l e User Agent is responsible for registering, re-registering when a connection lifetime expires,  29  or re-registering when the user and terminal move to a different network. It is also responsible for producing a Session Service Profile t h a t restrains the user from unregistered services. E a c h foreign network has a Service Profile that specifies the c o m p u t i n g resources and network services that are available at this particular network, and the personal applications t h a t are allowed to execute while the mobile user is visiting the network. T h e U F A provides access to this Service Profile d u r i n g the service negotiation phase.  W e introduce a t e m p o r a r y service profile located at a t e r m i n a l , called UserT e r m i n a l Service Profile. T h i s profile has the same format as any other service profile and is created after a successful registration. T h e User-Terminal.Service Profile is the intersection between the User Service Profile and the T e r m i n a l Service Profile, and is created once for each login session. T h i s service profile exists because the binding between a mobile user and mobile t e r m i n a l during a login session is fixed. A s a result, the User Service Profile does not have to be downloaded every time the mobile user and their mobile t e r m i n a l experiences a hand-off w i t h an ongoing session.  W e introduce a temporary service profile located at a t e r m i n a l , called Session Service Profile. T h i s profile is specific to a particular valid login session within a particular visiting network. It is the intersection between the User-Terminal Service Profile and the U F A Service Profile. T h e login user's access is limited to the services that only exist in the Session Service Profile.  T h i s profile is  recreated every time a mobile user and their mobile terminal move to a new foreign network.  30  3.3  S D L Specification of R S N P  A t the top level, we can describe the R S N P in U P C as a system that accepts the login and logout request from a user in the environment and then outputs the status message to the user. T h i s system consists of one block called M o b i l e l P , one block called M o b i l e User ( M U ) , a set of two similar blocks of type User Foreign Agent ( U F A ) , and another set of two similar blocks of type User H o m e Agent ( U H A ) . F i g u r e 3.1 presents the System D i a g r a m of the U P C ' s Registration and Service Negotiation P r o t o c o l . (Please note this diagram is for illustration purpose only, it is not the system diagram t h a t is directly printed put from the S D L ' s graphical representation.) • T h e M U block is connected to the environment t h r o u g h a channel called User, to the M o b i l e - I P block through a channel called M I P , and to the U F A block through a channel called M U - U F A . • T h e U F A block is connected to the U H A block v i a a channel called U F A J J H A , and to the environment v i a a channel called U F A J D e b u g . • T h e U H A block is connected  to the environment  through a channel called  UHA_Debug.  O n each channel in figure 3.1, there is a list of S D L signals that are carried by the channel in the specified direction.  T h e U s e r channel: this channel carries the S D L ' s signals between the environment (i.e. a user) and a M U block. T h e S D L signals carried in this channel are as follows:  31  0X1  JC  E o X o (A 3 cr  u  s  o m c V  Q  S  3  <  X>  CU  Q, o_ a  cr  s  i) xs w  tu  4V  *,  • C  tl.  p.  3 <  -C  cn  tu o  cr 1  o o o o  3C  -  o  s •a —  <4—S-  00 3  c  1)  00  3  2 OS.  X) CU  =' 8 2%  s cs -C  <a  O Q  1  ' CO -5H 00  §  OH  C  s-  _o .2 •' o  W>  cu  Z  0)  a> '> •—  in  <L>  00  -o.  a>  c  B  ni  o  C _g  o  o m  e  U  a. o  03  .5 §  60  . oo o.  OS  so o  u H3  00 . 3  4>  c-Q a. 1 a. « C3SO  . B S  es  J=  U  X  •4-P  CM  .  °,  o  5  U  U .  XI tu  8..§- C J  S  I so  Q  t  eu  UH  2  I  a. tu  i  M  s  ai •s- C/5i  cr i s  M  w £  Cu  ai,  tu  fe 'S 2 2S  O  cr CD  a n  tu  c  3 < 1/2  C  00  I 3  O XI c tu  - tn  pj"  Figure 3.1: System Diagram of UPC's Registration and Service Negotiation Protocol  c  o  3  S3  >  « O0  a  c«  tU  Login signal: this signal describes a login request from a user w i t h the i n put parameters, such as the user's L U I , the user's password, and the I P address of the user's t j H A .  \  Logout signal: this signal describes a logout request from a user who has a valid login session.  Prompt signal: this signal describes a p r o m p t for user inputs. Error Report signal: this signal describes a system response when an error occurs. The M I P channel: this channel carries the S D L signals between a M I P block and a M U block.  Location Update signal: this signal describes the location update message that M o b i l e - I P sends to the M U , informing it that the t e r m i n a l is m o v i n g into a new foreign network. It has the new U F A I P address as the input parameter.  The M U _ U F A channel: this channel carries the S D L signals between a M U block and an U F A block. T h e S D L signals carried in this channel are as follows:  Connection Request signal: this signal describes a request from a M U to an U F A for a connection. It has the user's L U I , the user's password, the user's U H A I P address, a request connection lifetime, and a sequence number as the input parameters.  '•  '  Connection Reply signal: this signal describes a reply from an U F A to a M U for a connection request. It has a returned code, a string message, a granted connection lifetime,,a connection I D , and a sequence number as the output parameters'.  ,  33  .  User Service Profile Request signal: this signal describes a request from a M U to an U F A for a user's service profile.  It has the user's L U I , a  connection I D , and a sequence number as the input parameters.  User Service Profile Reply signal: this signal describes a reply from an U F A to a M U for a user service profile request. It has a returned code, a string message, a service profile, and a sequence number as the output parameters.  ,  U F A Service Profile Request signal: this signal describes a request from a M U to an U F A for the U F A ' s service profile. It has the user's L U I , a connection I D , and a sequence number as the input parameters.  U F A Service Profile Reply signal: this signal describes a reply from an U F A to a M U for an U F A ' s service profile request.  It has a returned  code, a string message, a service profile, and a sequence number as the output parameters.  De-registration Request signal: this signal describes a request for de- registration of a valid established connection. It has a connection I D as the input parameter.  The U F A _ U H A channel: this channel carries the S D L signals between an U F A block and an U H A block. follows:  T h e S D L signals carried in this channel are as  •  Authentication Request signal: this signal describes a request from an U F A to an U H A for authenticating a user.  It has the user's L U I , the  user's password, and a sequence number as the input parameters.  34  Authentication Reply signal: this signal describes a reply from an U H A to U F A for an authentication request. It has a returned code, a string message, and a sequence number as the output parameters.  User Service Profile Request signal: this signal describes a request from an U F A to an U H A for a user's service profile. It has the user's L U I and a sequence number as the input parameters.  User Service Profile Reply signal: this signal describes a reply from an U H A to an U F A for a user's service profile request. It has a returned code, a string message, a service profile, and a sequence number as the o u t p u t parameters.  The U F A J D e b u g and the U H A _ D e b u g channel: these two channels carry S D L signals between the U F A block, U H A block and the environment respectively. These signals are mainly used to display the debug and status information at both the U F A and U H A . The  MIP  channel: this channel carries the S D L signals between a M U block and  a M o b i l e - I P block. There is only one signal, called L o c a t i o n U p d a t e , on this channel. T h i s signal has the new U F A ' s I P address as the input parameter.  3.3.1  Pseudo M o b i l e - I P Block  T h e M o b i l e - I P block describes a pseudo mobile-IP. Figure 3.2 is the block diagram of the M o b i l e - I P block.  T h e M o b i l e - I P block contains one single process called  M I P _ P s e u d o that simulates the movement of a mobile, terminal. After detecting the terminal has moved to a foreign network, it informs the M U block about the change using a location update signal.  35  Block MIP (Pseudo Mobile-IP)  [~Location_Update  From MIP Signal Route  / \  MIP Pseudo Process  \  /  Figure 3.2: B l o c k D i a g r a m of a Pseudo M o b i l e - I P  3.3.2  Mobile User Block  T h e M U block describes a M o b i l e User Agent as mentioned i n section 3.3. T h i s block provides the interfaces for user inputs, such as login and logout requests. Figure 3.3 illustrates the block diagram of the M U block. T h i s block contains one process called M U - P r o c e s s whose behaviour is described i n the attached extended F S M , i n figure 3.4. T h e M U _ P r o c e s s consists of four states: the Idle state, the Registering state, the Registered state, and the Negotiation state.  Idle state: in this state, the M U _ P r o c e s s is ready to accept a login request from a .; user.  Registering state: the M U _ P r o c e s s enters this state after receiving a login request from a user or a location update message from the M o b i l e - I P . D u r i n g this state, the M U _ P r o c e s s contacts the U F A to request a connection and waits for 36  Block M U (Mobile User)  Prompt Error Report Message_Debug  Connection_Rep UserServiceProfile_Rep UFA_ServiceProfile_Rep  Login Logout  Connection_Req UserServiceProfile_Req. UFA_ServiceProfile_Req Deregistration_Req  M U Process User Signal Route  UFA Signal Route  IjLocation Update]  MIP Signal Route  F i g u r e 3.3: B l o c k D i a g r a m of a M o b i l e User  37  a reply.  Registered state: the M U _ P r o c e s s enters this state after receiving a connection acceptance from the U F A . It waits for user requests that include execute an application or perform network services.  Negotiation state: the M U - P r o c e s s enters this state after sending requests for the user's service profile and the U F A ' s service profile and awaits the replies.  3.3.3  User Foreign Agent Block  T h e U F A block describes a U F A . F i g u r e 3.5 illustrates the block diagram of the U F A block. There is one process in the U F A block called U F A _ P r o c e s s , whose behaviour is described in the attached extended F S M , in figure 3.6. T h e U F A _ P r o c e s s consists of four states: the Idle state, the Process C o n n e c t i o n Request state, the Session Established state, and the User Service Profile Request Processing state.  Idle state: in this state, the U F A J P r o c e s s is ready to accept a connection request from the M U .  Process Connection Request state: in this state, the U F A _ P r o c e s s processes the connection request from the M U . It contacts the specified U H A to authenticate the login user and awaits an authentication reply.  Session Established state: the U F A . P r o c e s s enters this state after it grants a connection to the M U . In this state, it waits for further requests from the M U , such as a request for using network services.  38  F i g u r e 3.4: M o b i l e User Agent's Extended F i n i t e State M a c h i n e  39  Block  U F A (User Foreign Agent)  Connection_Rep UserServiceProfile_Rep UFA_ServiceProfile_Rep  Connection_Req UserServiceProfile_Req UFA_ServiceProfile_Req Deregistration_Req  Authen_Rep USP_Rep  Authen_Req USP_Req  UFA Process M U Signal Route  UHA Signal Route  UFA Debug Signal Route  Error_Report WrongSeqno_Debug InvalidConnectID_Debug Message_Debug  F i g u r e 3.5: B l o c k D i a g r a m of a User Foreign A g e n t  40  User Service Profile Request Processing state: in this state, the U F A - P r o c e s s processes the request for a user service profile from the M U . It contacts the user's U H A to request the user's service profile and awaits the reply.  3.3.4  User Home Agent Block  The U H A block describes a U H A . F i g u r e 3.7 diagrams the U H A block. There is one process i n the U H A block called U H A _ P r o c e s s , whose behaviour is described in the attached extended F S M , i n figure 3.8. T h e U H A _ P r o c e s s consists of three states: the Idle state, the C h e c k i n g I D and Password state, and the Service Profile Request Processing state.  Idle state: in this state, the U H A _ P r o c e s s is ready to accept any requests from the UFA.  Checking ID and Password state: the U H A _ P r o c e s s enters this state after receiving a request for user authentication.  Service Profile Request Processing state: the U H A _ P r o c e s s enters this state after receiving a request for a user's service profile.  3.4  Prototype Implementation of U P C  After having a concise specification, we implemented a prototype of R S N P on Sun M i c r o s y s t e m Solaris 2.x using C as the p r o g r a m m i n g language. T h e user graphical interface was written in T c l / T k . T h e implementation code space is roughly about 8000 lines. T h e prototype of R S N P is subjected to the following assumptions and requirements:  F i g u r e 3.6:  User Foreign A g e n t ' s Extended F i n i t e State M a c h i n e 42  Block U H A (User Home Agent)  Authen_Rep USP_Rep  Authen_Req USP_Req U H A Process  U F A Signal Route  U H A Debug Signal Route ErrorJReport WrongSeqno_Debug Messag_Debug  F i g u r e 3.7: Block D i a g r a m of a User H o m e A g e n t  43  44  3.4.1  A s s u m p t i o n s and R e q u i r e m e n t s :  • T h e applications supported here are limited to internet applications such as web browsers (e.g. Netscape, M o s a i c ) , news clients , mail clients, and so o n . • T h i s prototype implementation does not support multi-platforms. T h e supported platform considered here is U N I X . • A local user whose login mobile t e r m i n a l comes from a foreign network is considered a visiting user since the mobile t e r m i n a l may not support all the services t h a t a fixed t e r m i n a l in this network supports. • T h e U F A and the M o b i l e - I P Foreign A g e n t ( F A ) are required to operate on. the same machine, or in other words, they should have the same I P address. T h i s requirement makes the agent ( U F A ) discovery procedure in the U P C efficient and simple. A s a mobile t e r m i n a l ( M T ) and a mobile user enter a foreign network, the M o b i l e I P detects the move and informs the M U of the current U F A ' s I P address (this should be the same as the F A I P address). T h e M o b i l e - I P need to be modified to provide this location update service.  • A mobile user is required to know the U H A ' s location, whether it is a U H A ' s I P address or the name of the host that U H A is currently r u n n i n g o n . T h e U H A location can be extracted from the L U I , but this requires that the U H A resides on the same host as the internet mail server. It is unsafe to run any user program on the mail server's host, and to the extent that this is a prototype implementation, this requirement is reasonable.  If the user is local and the  terminal is also local, then this requirement is waived.  45  3.4.2  R e g i s t r a t i o n and Service N e g o t i a t i o n P r o c e d u r e  T h e behaviour of the R S N P depends on the type of terminal, fixed or mobile. There is no hand-off and U F A location update procedures for a fixed terminal. For a mobile terminal, by default, the M o b i l e User ( M U ) is configured to know the location of the U F A in its home network. T h e following is the sequence of events during the Registration and Service Negotiation:  • After receiving the user's information, such as the L U I , the password, and the U H A ' s I P address, the M U at the login terminal verifies whether the user is local or foreign by comparing the d o m a i n portion of the L U I and the current U F A ' s I P address. T h e terminal's type, fixed or mobile, is identified from the t e r m i n a l configuration. If the user is local in this administrative d o m a i n and the terminal is fixed, the M U allows this user to login locally. T h e user has full access to any services and applications available. If the user is from a foreign administrative d o m a i n , or the user is local in this administrative d o m a i n but the terminal is a foreign t e r m i n a l , the M U contacts U F A for a connection request.  • After receiving a connection request from a M U , the U F A checks its current status, i.e.  number of connections available.  If the U F A is able to handle  another connection, it contacts the user's U H A for user authentication. • T h e user's U H A validates the requested L U I and its corresponding password. If both the L U I and password are valid, the U H A returns a valid authentication reply to U F A .  46  • A s the U F A receives a valid authentication reply from the user's U H A , it generates a connection I D and sends a connection acceptance message along w i t h this connection I D to the M U . • After the registration succeeds, the M U initiates the service negotiation procedure by sending a request for the User Service Profile to the U F A . T h e U F A forwards this request to the user's U H A . T h e reply comes to the U F A arid is then forwarded to the M U . • If the M U receives a valid reply, it creates a U s e r - T e r m i n a l Service Profile by intersecting the User Service Profile w i t h the T e r m i n a l Service Profile. • If the U s e r - T e r m i n a l Service Profile is not empty, the M U contacts the U F A to retrieve the U F A ' s Service Profile and then produces a Session Service P r o file by intersecting the U F A ' s Service Profile w i t h the U s e r - T e r m i n a l Service Profile.  3.4.3  R e - r e g i s t r a t i o n after E x p i r a t i o n of C o n n e c t i o n L i f e t i m e  E a c h connection granted from the U F A has a unique I D and a limited lifetime. A connection becomes invalid if the connection lifetime at the U F A expires. T o m a i n tain a connection, the M U has to send a re-registration request whenever its connection lifetime expires. T h e re-registration procedure after expiration of a connection lifetime is very simple compared to the re-registration procedure after a hand-off. W h e n a connection lifetime expires, the M U sends a re-registration request with the associated connection I D and requested desired lifetime. If the connection I D is valid, the U F A updates the connection.lifetime for this connection I D and then sends a reply back to M U .  47  3.4.4  R e - r e g i s t r a t i o n after H a n d - o f f  Hand-off only occurs w i t h a mobile t e r m i n a l . T h e hand-off in the mobile t e r m i n a l is handled by the M o b i l e IP. T h e M U detects a move into a foreign network when it receives a location update message from the M o b i l e I P and the U F A ' s I P address in the location update message is different from its current connected U F A ' s I P address. If the M U is serving an ongoing session, it performs the re-registration  procedure.  T h e M U contacts the new U F A and provides it w i t h all the user's information such as the L U I , the password, and the U H A ' s I P address. T o authenticate the user, similar steps as used in the registration procedure are carried out. T h e ongoing session is terminated if either the new U F A is not available for any services or authentication of the user failed. After successful registration w i t h the new U F A , the M U contacts the new U F A to retrieve the new U F A ' s Service Profile. A new Session Service Profile is created from intersecting the User- T e r m i n a l Service Profile and U F A ' s Service Profile. C u r r e n t running services or applications t h a t do not exist in the Session Service Profile are considered illegal and are immediately terminated by the M U .  3.4.5  D a t a g r a m F o r m a t used i n R e g i s t r a t i o n and Service N e g o t i a tion Protocol  Communication between M I P and M U T h i s is the datagram format for the location update packet from M o b i l e IP. • U D P fields  -  Source P o r t : variable  -  Destination P o r t : 9999 48  • T h e U D P Header -  Type: Location Update  -  L o c a t i o n : I P address of U F A  C o m m u n i c a t i o n between M U / U F A or  UFA/UHA  There is only one header type used for all the request and reply packets between M U and U F A , or U F A and U H A . User I D , password, and service profile are inserted into the d a t a portion after the header..  • U D P fields — Source P o r t : variable — Destination P o r t : copied from the source port of the corresponding R e quest or * from M U to U F A use  8888  * from U F A to U H A use  6666  * from U H A to U F A use 7777 • T h e U D P Header — Type: * Connection Request * Connection Reply * A u t h e n t i c a t i o n Request * A u t h e n t i c a t i o n Reply * User Service Profile Request  49  * User Service Profile Reply * U F A Service Profile Request * U F A Service Profile Reply C o d e : A value indicating the result of the request. It is set to 0 i n the request packet. Possible errors are: * F o r Connection Request • Registration Accepted • Registration Denied • Unspecified Reason • Insufficient  Resources  • A u t h e n t i c a t i o n Failed • Requested Lifetime Too L o n g • P o o r l y Formed Request • U n k n o w n U H A Address • U H A host is Unreachable • U H A port is Unreachable * For A u t h e n t i c a t i o n Request • Authentication O K • Authentication E R R O R : • Unspecified Reason • Identification M i s m a t c h • P o o r l y Formed Request • Un-Registered User  50  . '  * F o r User Service Profile Request  •OK • E R R O R , Unspecified • U H A Unreachable * F o r U F A Service Profile Request  • OK • E R R O R , Unspecified • U F A Unreachable Lifetime:  T h e number of seconds remaining before the registration is  considered expired. A value of Oxffff indicates infinity. It is set to 0 for the reply packet w i t h an error code. U H A : I P address of the User H o m e A g e n t Seqno: the sequence number of this packet. I D : the connection I D of this connection. It is set to 0 in packet type C o n nection Request, except in the case of re-registration after a connection lifetime expires. In this case it is set to the actual connection I D . D a t a length: the length of the d a t a following the header.  51  Chapter 4  CORBA-based U P C Prototype  4.1  C O R B A - b a s e d U P C Prototype Implementation  In this chapter, we present the implementation of the C O R B A - b a s e d U P C prototype. A s mention in section 2.5, C O R B A - b a s e d U P C architecture is an alternative approach in modeling the U P C concept. In this architecture, the U P C components are modeled as distributed objects w i t h C O R B A as the object bus that facilitates the interaction, integration, and d i s t r i b u t i o n of these objects. W e implemented the prototype using J a v a as the p r o g r a m m i n g language, Visigenic's V i s i B r o k e r for J a v a as the C O R B A framework, and Sun M i c r o s y s t e m ' s Solaris 2.x as the c o m p u t i n g platform. T h e prototype code space is approximately 5000 lines. Because the implementation is a prototype and there are insufficient computing resources, the prototype is implemented based on the following simplifications and requirements:  52  • T h e U P C architecture utilizes a wide range of services defined by the C O R B A Object Services, such as the N a m i n g Service, the Trader Services, the Life C y c l e Services, and the Security Services.  However, some  implementations  of these services (i.e. the Trader Services) were not available at the time we implemented the U P C prototype.  A s a result, the lack of C O R B A  services  has influenced our implementation of the prototype to a certain extent. T h e service discovery and service negotiation procedure is simplified to a direct mapping in the application name and configuration name. T h u s , the terminal profile is simpler than the t e r m i n a l profile proposed in Z h u , Toeroe, Leung, and Vuong[35]. O n our implementation the terminal profile defines only the software capability of the terminal, w i t h no information regarding the terminal's physical capability.  • T h e terminal must support J a v a and C O R B A ' s O R B . In addition, there must be enough memory in the t e r m i n a l to download the application client class file and the application configuration file.  A s the first step in the implementation, we defined all the U P C objects' interfaces using the Interface Definition Language ( I D L ) . A n overview of I D L was presented in section 2.5. T h e n , we ran the I D L files through C O R B A compliant pre-compiler to generate the stubs and skeletons, which were used as a frame in implementing an object. T h e following sections present the I D L interface definition for all the major objects as well as their functionalities in the C O R B A - b a s e d U P C architecture, such as Personal C o m p u t i n g E n v i r o n m e n t ( P C E ) , User H o m e A g e n t ( U H A ) , T e r m i n a l Profile, T e r m i n a l A g e n t ( T A ) , and Initial A g e n t .  53  4.1.1  Personal C o m p u t i n g E n v i r o n m e n t ( P C E )  E a c h user has a P C E which is kept and maintained at the User H o m e A g e n t . T h e P C E is designed to specify enough information so that the T e r m i n a l A g e n t can untilize the C O R B A Trader Services to discover and negotiate the services available for a user while they visit a foreign network. T h e I D L code of the P C E is attached in. A p p e n d i x A . T h e P C E is a list of service structures, each of. which is composed of: • Service N a m e : the.name of a service object, defined as a string. • Service T y p e : the type of service object, i.e. .  an application client object,  application configuration, or network resources.  • Service Object: the reference to a service object. T h i s object can be an applica' tion client object, an object that allows access to an application configuration, or an object that allows access to network resources. • Trade Information: a structure t h a t stores all the necessary information needed for the C O R B A Trader Services t o discover or locate a service, i.e. the service type, the service properties, the constraint of the search and the search policies. • Hardware capability: a list of the requirements about physical hardware support for this "service. F o r example, to play a midi file, a t e r m i n a l is at least required to be equiped w i t h a sound card and speakers.  4.1.2  U s e r H o m e Agent ( U H A )  '  For each administrative d o m a i n , there is a U H A . T h e U H A manages the list of users registered in its administrative d o m a i n , and the users' corresponding P C E s .  54  The  I D L code of the U H A is attached in A p p e n d i x A . T h e U H A exports the following services: • boolean tokenauthent(in string L U I , in string password, out Token token): T h i s method authenticates a, user identified by the L U I and the  password.  U p o n successful authentication, a token (or a validation ID) is returned to the caller. • i n f o r m J o c a t i o n ( i n string L U I , in string address): T h i s method informs the U H A of the current location of the user (i.e.  IP  address of the terminal). • P C E : : P r o f i l e getprofile(in string username): T h i s method retrieves a user's P C E . • string download (in Token token, in string filename): T h i s method downloads a file from the user's home network. • boolean upload (in Token token, in string filename, in string d a t a ) : T h i s method uploads a file from the T A to the user's home network. • boolean updateProfile(in string username, in P C E : : P r o f i l e p): T h i s method allows a user to modify their P C E . • void logout (in Token token): T h i s method informs the U H A that a user is logging out.  4.1.3  T e r m i n a l Profile  E a c h terminal has a terminal profile which is stored in a file at the t e r m i n a l . In our prototype, the terminal profile is implemented as a J A V A class t h a t maintains a list 55  of the software application names that are available at the terminal (e.g. M o s a i c , and Internet M a i l ) .  Netscape,  These software application names determine which  software applications are available at a terminal to a user when they login to this terminal. In addition to the application name, for each software application, the following corresponding information is kept in the t e r m i n a l profile:  • T h e full path executable file name of the software application (e.g. for Netscape, the file name is /usr/application/netscape.exe  ). T h i s full path executable file  name specifies where to fire up the software application. • A list of configuration names and preference names (e.g. bookmarks) and the corresponding full path configuration file names and preference file names (e.g. /usr/application/netscape/bookmarks.html).  T h e list of configuration names  specifies and limits the ability of a visiting user to replace these configurations w i t h their own configuration from their home network. W h e n a configuration file is downloaded from a user's home network, the configuration name and configuration file name are used to map the downloading configuration file to the local configuration file at the t e r m i n a l .  In order to aid in the generating and updating of a service profile, we implemented a utility application w i t h G U I , called Service M a n a g e r . T h e Service M a n a g e r utility is available to the system administrator or the owner of the portable t e r m i n a l . T h e Service M a n a g e r utility supports the following functions:  • A d d a new application name and its executable file name into the t e r m i n a l profile.  56  Add  Delete  Quit  Application Name  netscape  j calendar calculator j printer  Help  Exec Path  I /cs/pubIic/bin/netscape  Con fig Name , bookmarks j preferences (cookies ! plugin—list j history  File Name  /grads2/thuynh7.UPC /grads2/thuynh/.UPC /grads2/thuynh/.UPC /grads2/thuynh/.UPC /grads2/thuynh/.UPC  F i g u r e 4.1: M a i n screen of the Service M a n a g e r u t i l i t y  • A d d a new configuration name and its configuration file name t o an existing application in the t e r m i n a l profile. • Delete an existing configuration name and its configuration file name from an existing application in the t e r m i n a l profile. • Delete an existing application name and its corresponding  executable file  name, the configuration name list and configuration file name list from the terminal profile.  A screen shot of the Service M a n a g e r is illustrated in F i g u r e 4.1.  57  4.1.4  Terminal Agent (TA)  T h e T A is implemented as an application server for the Initial A g e n t . Residing locally at a terminal, the T A communicates w i t h the login user's U H A to perform the following tasks:  • Process a login request for a user. • Retrieve the user' P C E from their home network. • Perform service discovery and negotiation.  T h i s process produces a set of  network services and applications requested by the user and which are also available at the login t e r m i n a l . • D o w n l o a d the configuration or preference files that a user specifies for a particular application when this application is locally executed. • D o w n l o a d the class files of the client of the application t h a t is remotely executed. • A t shutdown, synchronize the downloaded configuration or preference  files  w i t h copies at the home network.  T h e following describes the interfaces supported by T A . These interfaces are defined using O M G ' s I D L . Refer to A p p e n d i x A for the entire I D L code.  • boolean login (in string L U I , in string password) raises (Fail): T h i s method uses the domain name portion given in the L U I and the C O R B A N a m e Services to resolve the object reference of the login user's U H A . After obtaining the U H A object reference, this method then invokes the a u t h e n t i c a t e O  58  method exported by U H A to authenticate the user. If the authenticate operation is successful, this method invokes the g e t p r o f i l e Q method from the U H A to get a reference to the user's P C E . T h i s method compares the user's P C E w i t h the T e r m i n a l Profile to produce a list of network services and applications specified by the user in the user's P C E which are also available at the login t e r m i n a l . T h i s method also extracts from the P C E all the network services and applications that are remotely available. " R e m o t e l y available" network services or applications are network services t h a t can be executed at the home network or applications that are implemented using the C O R B A C l i e n t / S e r v e r framework. void logout() raise (Fail): ' T h i s method first closes all the running network's services and applications. Secondly, for local applications, if any of the configuration files downloaded from the user's U H A had been modified, these files are synchronized w i t h copies at the user's U H A by invoking the u p l o a d ( )  method exported by the  U H A . A n d finally, t h i s method deletes both the configuration and class files downloaded d u r i n g this login session. string r u n L o c a l A p p ( i n string appName) raise (Fail): T h i s method executes a local application.  If there is a configuration file  specified w i t h this application in the user's P C E , this method invokes the d o w n l o a d O method exported by t h e U H A to download t h i s configuration file. string r u n R e m o t e A p p ( i n string. appName) raises (Fail):. T h i s method executes a remote application. It first downloads the "client" of the application from the U H A , as specified in the user's P C E , then instantiates  59  the object and runs it. • string getLocalServiceList() raises (Fail): T h i s method returns a list of network services and applications specified by the user in the P C E which are also available at the foreign t e r m i n a l . • string g e t R e m o t e S e r v i c e L i s t Q raises (Fail): T h i s method returns a list of network services that can be executed at the home network and applications that are implemented using the C O R B A C l i e n t / S e r v e r framework.  4.1.5  Initial Agent  T h e Initial A g e n t is an active process executed at a t e r m i n a l . It is responsible to accept inputs from users and output the responses from the U P C system. T h e I A is implemented as a T A ' s C O R B A client application. T h e I A invokes the service provided by the T A corresponding to the user input. T h e I A is implemented as a Java class t h a t consists of two inner classes called Login W i n d o w class and A p p l i c a t i o n M a n a g e r class.  • T h e L o g i n W i n d o w class provides a screen where a user can make a login request by entering their L U I and password.  T h e screen shot of the L o g i n  screen is shown i n the F i g u r e 4.2. • T h e A p p l i c a t i o n M a n a g e r class provides a window where a user can select to execute a software application or request a network service.  T h e r e are  two selectable lists of software applications and network services that a user is granted to access. T h e first list displays all the network services that are available at the visiting network and software applications that are locally 60  Help  U e l c o n e t o UPC  User ID  t8st@ece.ubc.c3  Password  OK I  Clear [  Jxit  F i g u r e 4.2: Login screen of the U P C  available at the login t e r m i n a l , and the second list displays all the network services and software applications that are available at the home network which can be remotely executed. T h e screen shot of the A p p l i c a t i o n M a n a g e r screen is shown in F i g u r e 4.3.  After a user enters their L U I and password, the I A instantiates a T A object and invokes the l o g i n O method exported by the T A object.  If the login request  is successful, the I A closes the login window and displays the application manager window. T h e I A obtains the list of locally available network services and applications and the list of remotely available network services and applications by invoking the g e t L o c a l S e r v i c e L i s t O and g e t R e m o t e S e r v i c e L i s t Q method respectively from the T A . These two lists are displayed in the window manager so that a user can easily select to execute the desired network service or a p p l i c a t i o n . D e p e n d i n g on  (ii  Local Services  Remote Services  j netscape {calendar i calculator I printer  Exec  Cancel\  F i g u r e 4.3: U P C A p p l i c a t i o n M a n a g e r screen  62  Logout  the user selection, one of the following actions will be carried out.  • If the user chooses to run a remote application, the I A invokes the r u n R e m o t e A p p O method from the T A w i t h the appropriate  parameters.  • If the user chooses to run a l o c a l application, the I A invokes the r u n L o c a l A p p O from the T A with the appropriate  4.1.6  parameters.  Testing and Results  Testing  Preparation  T h e prototype supports mobile users w i t h transparent access to their personalized c o m p u t i n g environments wherever they roam on the Internet, using wireless or wired connections. T o demonstrate this capability of the prototype, we have prepared the followings items:  • Software A p p l i c a t i o n There are two main categories of network resources and software applications, i.e. local and remote. T h e " l o c a l " category includes all the network services t h a t are available at the visiting network and all the software applications that are installed in the visited t e r m i n a l . O n the other hand, the networks services that are available outside the visiting network (i.e.  at the home network)  and software applications that can be remotely executed (i.e. applications developed based on C O R B A ' s framework) fall into the "remote" category. F o r local application, we used the web browser (i.e. Netscape) as an example. T h e user would be able to run Netscape with the preference and configuration files (i.e. bookmarks, preference, cookie files) from their home network. In regards  63  to the remote application, we implemented a C O R B A - b a s e d software application, a distributed T i c T a c T o e game. It consists of a very thin application client (i.e. G U I ) and an application server. A user can play a game half way and save it, then resume the previously paused game any time later. • User We created a user called "test" under the administrative domain "ece.ubc.ca". In the user P C E , we specified the user would like to use netscape as their web browser, and the " b o o k m a r k s . h t m l " and the "preferences" files are defined as the preference files for the application "netscape". In addition to this, the user wants to be able to play a T i c T a c T o e game away from home. • Terminal We configured a foreign t e r m i n a l in a second administrative d o m a i n , "cs.ubc.ca", to support U P C , and created a terminal profile for this terminal using the Service M a n a g e r utility application. T h e terminal profile specifies that a web browser called "netscape" is installed at the t e r m i n a l . T h e m a p p i n g information for all the reference and configuration files for netscape are also added to the terminal profile. F o r example "netscape" is installed at " / u s r / b i n / n e t s c a p e " and the bookmarks file is mapped into the " / u s r / b i n / n e t s c a p e / b o o k m a r k s . h t m l " •  file.  Results  „  W h e n the user "test" moves away from home and visits the "cs.ubc.ca" network, they are able to login and have the same c o m p u t i n g environment as they have at home (i.e. ece.ubc.ca). T h e user can run netscape w i t h the same bookmarks and  64  preferences as they have at home, and any change to the b o o k m a r k s or preferences files is synchronized w i t h the corresponding files at the home network: T h e user can also remotely play a T i c T a c T o e game and resumes a previously paused game. T o get a reading on the performance of the C O R B A - b a s e d U P C prototype implementation, we have recorded the time that it takes to perform a task in different situations. T h e following shows some figures calculated based on an average of 80 runs:  • T i m e to resolve the User A g e n t : 702 msecs • T i m e to process a login request : 174 msecs • D o w n l o a d file rate : 27 bytes/msecs  65  Chapter 5  Conclusion and Future Works 5.1  Conclusion  T h i s thesis addresses implementation issues regarding the support of mobile c o m puting over the Internet using a new c o m p u t i n g paradigm called Universal Personal C o m p u t i n g ( U P C ) [ 3 0 , 3 5 ] . U P C is a c o m p u t i n g environment which enables a mobile user to access c o m p u t i n g resources, network services, personal applications, d a t a files, and environmental configurations through any t e r m i n a l , stationary or mobile, anywhere on the Internet [21]. T h e core of U P C ' s mobility management is the Registration and Service Negotiation protocol ( R S N P ) . W e first specified the U P C ' s R S N P using Specification and D e s c r i p t i o n Language ( S D L ) . W e then simulated R S N P using different scenarios to demonstrate the protocol's behaviour, and to verify the protocol's completeness and correctness. W i t h the concrete and precise understanding gained from U P C ' s R S N P S D L specification, a prototype of U P C ' s R S N P was subsequently implemented in C and on Sun Solaris with the user interface written in T c l / T k .  66  T h e specification and simulation of R S N P using S D L has made the implementation of the U P C ' s R S N P prototype easier and simpler. In S D L specification, an agent's behaviour is described-using an extended finite state machine ( F S M ) and coding from a F S M is a straightforward task. M o r e i m p o r t a n t , the simulation has verified the response of a F S M against different combinations of inputs and states. T h e F S M is proved to correctly work before any coding a t t e m p t . T h i s results in a huge reduction i n debugging time in the implementation phase. Unfortunately, using C language to implement all the distributive components in U P C is very complex and even impossible.  T h e U P C prototype imple-  mented using C language supports only one feature proposed in the U P C framework, i.e.  executing a local application using the downloaded configuration and  preference file from the user's home network. However, there is no support for other features such as remotely executing an application or a service in the home network from the foreign network, or downloading an application from the home network and executing at the foreign network. To successfully implementing all the features in the U P C framework, a combination of a platform independent d i s t r i b u t e d object architecture support (i.e. C O R B A ) language (i.e. J A V A ) is necessary.  and a platform independent p r o g r a m m i n g  T h e distributed object architecture w i l l make  the implementation of a distributed application easier than using only C language. L o o k i n g for an object, marshalling d a t a from one language to another, or invoking a method on a remote object are performed transparently by the distributed object framework. In addition, the platform independence of J a v a will make all the client side of all the distributed components portable across platform. A s a result, this thesis has presented an alternative approach to modeling the U P C concept using distributed objects, called C O R B A based U P C [30, 35]. In this  67  architecture, the U P C components are modeled as distributed objects w i t h C O R B A . as the object bus that facilitates the interaction, integration, and d i s t r i b u t i o n of these objects.  T o demonstrate the concept, a prototype of C O R B A - b a s e d U P C  was implemented using J a v a 1.1.x and Visigenic's C O R B A for J a v a 3.0 on a Solaris platform. W i t h the advantage of using J a v a and C O R B A , we were able to implement most of the features proposed in the U P C framework. T h e implementation is very simpler as compared to the C / T c l / T k implementation: T h e prototype implementation supports a mobile user to transparently access their configuration and preference file, and execute their personal software application whenever and wherever <  they roam on the Internet. T h e application could be a local application r u n n i n g w i t h the user's configuration and preference file, or an application t h a t is remotely executed at the user home network.  5.2  Future Works  Since the implementation of the C O R B A - b a s e d U P C is only a prototype and some of the C O R B A service implementations are not available at the time the prototype was implemented, many features remain to be implemented in the future. .,  • In the P C E , the set of values that describe the required hardware capabilities for a service remains to be standardized and implemented. • In the terminal profile, the set-of values that describes the terminal's hardware capabilities remains to be standardized and implemented. • A s the C O R B A ' s Trader Service becomes available, the T e r m i n a l A g e n t could ; be enhanced to support service discovery at the visiting network.  68  A s the C O R B A ' s C o n c u r r e n c y C o n t r o l is available, the User A g e n t could use this service to control access to the P C E , and the T e r m i n a l A g e n t could use this service to synchronize file downloading and uploading. P o r t i n g this project into a Web-based framework would be a possible extension. Last but not least, a detailed study of the U P C ' s protocol performance and security issues needs to be conducted.  69  Bibliography [1] R . B a g r o d i a , W . W . C h u , L . K l e i n r o c k , and G . Popek, " V i s i o n , Issues, and Architecture for N o m a d i c C o m p u t i n g " , IEEE Magazine,  Personal  Communications  pages 14-27, December 1995.  [2] F . Belina, D . Hogrefe, and A . S a r m a , " S D L w i t h A p p l i c a t i o n from P r o t o c o l Specification", Prentice  Hall International  (UK) Ltd., 1991.  [3] J . C . Benard-Dende, R . Nevoux, and J . C . D a n g , " N e t w o r k s , Users a n d Terminals in U M T S / F P L M T S " ,  Vehicular  Technology  Conference  ^th.,  pages 681-685, 1994. [4] R . Braek, " S D L B a s i c s " ,  Handouts.  [5] D . Chess, B . Grosof, C . Harrison, D . Levine, C . P a r r i s , and G . T s u d i k , " Itinerant Agents for M o b i l e C o m p u t i n g " , IEEE  Personal  Communications,  pages 34-49, October 1995. [6] C O R B A Home Page, URL: http://www.omg.org, 1998. [7] T . V . D o , and J . A u d e s t a d , " T e r m i n a l M o b i l i t y Support in T I N A " , ceedings of TINA's  97, pages 38-50, 1998.  70  Pro-  [8] T . E c k a r d t , and T . M a g e d a n z , " T h e Role of Personal C o m m u n i c a t i o n s in D i s t r i b u t e d Office E n v i r o n m e n t s " , Autonomous Proceedings,  Decentralized  Systems  pages 316-322, 1995.  [9] T . E c k a r d t , and T . M a g e d a n z , "Personal C o m m u n i c a t i o n s Support on T M N and T I N A Concepts" proceedings  based  of IN's 96, pages 196-200, 1996.  [10] M . P. Gervais, " A Framework for M o b i l i t y in Wireless Personal C o m m u n i cations", Proceedings  of ICC/SUPERCOMM's  96, pages 1148-1152, v o l . 2,  1996. [11] V . G u p t a , and A . D i x i t , " T h e Design and Deployment of a M o b i l i t y S u p p o r t Network",Proceedings Second International tectures, Algorithms,  and Networks,  Symposium  on Parallel  Archi-  pages 228-234, 1996.  [12] J . G . Hemmady, J . R . M a y m i r , and D . J . Meyers, " N e t w o r k E v o l u t i o n to Support Personal C o m m u n i c a t i o n s Services", Global Conference,  Telecommunications  pages 710-714, v o l . 21994.  [13] T . D . Hodes, and R . H . K a t z , " C o m p o s a b l e A d hoc Location-based Services for Heterogeneous M o b i l e C l i e n t s " , , 1997. [14] C . ' S . H o n g , Y . K o g a , and Y . M a t s u s h i t a , " A N e t w o r k i n g A r c h i t e c t u r e for M o b i l i t y Services U s i n g M o b i l e A g e n t A p p r o a c h " , Proceedings  of  TINA's  97, pages 297-307, 1998. [15] I. Iida, T . Nishigaya, and K . M u r a k a m i , " D U E T : A n Agent-Based Personal C o m m u n i c a t i o n s N e t w o r k " , IEEE November 1995.  71  Communications  Magazine,  pages 44-49,  [16] T . Imielinski, and H . F . K o r t h , " M o b i l e C o m p u t i n g " , Kluwer Academic .  Publishers , 1 9 9 6 . • [17] J . Ioannidis, and G . Q . M a g u i r e J r . , " T h e Design and Implementation of a M o b i l e Internetworking A r c h i t e c t u r e " ,  Winter USENIX, 1993. -  [18] E . J u n g , Y . J . P a r k , and C . P a r k , " M o b i l e A g e n t Network for Supporting Personal M o b i l i t y " ,  Proceedings Twelfth International on Information  Networking, pages 131-136, 1998. [19] M . Liljeberg, K . Raatikainen, M . Evans, S. F u r n e l l , N . M a u m o n , E . V e l d kamp, B . W i n d , and S. T r i g i l a , " U s i n g C O R B A to Support T e r m i n a l M o bility",  Proceedings of TINA's 97, pages 59-67, 1998.  [20] Y . L i , a n d V . C M . Leung, " S u p p o r t i n g Personal M o b i l i t y for N o m a d i c C o m p u t i n g over the Internet",  ACM Mobile Computing and Communications  Review , V o l . 1, N o . 1, pages 22-31, A p r i l 1997. [21] Y . L i , a n d V . C . M . Leung, " P r o t o c o l A r c h i t e c t u r e for Universal Personal Computing",  IEEE Journal on Selected Areas in Communications , V o l .  15, N o . 8 , pages 1467-1476, October 1997. [22] A . L o m b a r d o , P . Nicosia, S. P a l a z z o , and M . Samarotto, "Service A r c h i tecture Support of Personal M o b i l i t y i n a M u l t i - D o m a i n  Environment",  Proceedings of TINA's 97, pages 51-58, 1998. [23] R . Orfali, and D . Harkey, " C l i e n t / S e r v e r P r o g r a m m i n g w i t h J A V A and CORBA";  John Wiley and Sons, Inc., 1997.  72  [24] J . P a v o n , and J . Tomas, " C O R B A for Network and Service M a n a g e m e n t in the T I N A F r a m e w o r k " , IEEE Communications  Magazine, pages 72-79,  M a r c h 1998. [25] C . Perkins, E d . , R F C 2 0 0 2 , I P M o b i l i t y Support, M a r c h 1997. [26] R . Ramjee, T . F . L a P o r t a , and M . Veeraragahvan, " T h e Use of NetworkBased M i g r a t i n g User Agents for Personal C o m m u n i c a t i o n Services", IEEE Personal Communications, pages 62-68, December 1995. [27] D . Samfat, and R . M o l v a , " A M e t h o d P r o v i d i n g Identity P r i v a c y to M o b i l e Users d u r i n g A u t h e n t i c a t i o n " , pages 196-199, Workshop on Mobile Computing Systems and Applications,  pages 196-199, 1995.  [28] A . S a r m a , "Introduction to S D L - 9 2 " , Handouts. [29] H . M . Sneed, " Encapsulating Legacy Software for Use in C l i e n t / S e r v e r Systems", Proceedings of WCRE'96, [30] M . Toeroe,  pages 104-119, 1996.  J . Z h u , Y . L i , and V . C . M L e u n g ,  " A CORBA  based  Framework for U n i v e r a l Personal C o m p u t i n g on the Internet",Proceedings SCI/ISAS'''98,  Orlando, FL, J u l y 1998.  [31] V i n o s k i S., " C O R B A : Integrating Diverse A p p l i c a t i o n s w i t h i n D i s t r i b u t e d Heterogeneous Environments, IEEE Communications Magazine, pages 4655, v o l . 35, 1997. [32] S. V i n o s k i , " D i s t r i b u t e d Object C o m p u t i n g W i t h C O R B A " , C++ Report Magazine, J u l y / A u g u s t 1993. [33] Visigenic P r o g r a m m e r ' s G u i d e , Version 3.0, V i s i B r o k e r for Java. 73  [34] M . Z a i d , " P e r s o n a l M o b i l i t y . in P C S " , IEEE Magazine  Personal  Communications  , pages 12-16, F o u r t h Q u a r t e r 1994.  [35] J . Z h u , M . Toeroe, V . C . M . - L e u n g , and S. V u o n g , " S u p p o r t i n g Universal Personal C o m p u t i n g on Internet w i t h J a v a and C O R B A " , Practice  and Experience,  1998.  74  Concurrency:  Appendix A The IDL files for all the agents in the C O R B A - b a s e d U P C architecture. / / A u t h o r : Thong Huynh module TA { i n t e r f a c e TerminalAgentf enum F a i l R e a s o n { UNABLE_TO_LOCATE_SERVER, NO_IMPLEMENT_SERVER, CLASS_N0T_F0UND,  INSTANTIATION_ERROR, ACCESS.ERROR, CLASSFILE_DOWNLOAD_ERROR, ERROR_EXEC_APPLICATION, UNKNOWN.HOST}; exception F a i l { F a i l R e a s o n reason; };  v o i d u p d a t e L o c a t i o n ( i n s t r i n g newLocation) r a i s e s boolean l o g i n ( i n s t r i n g L U I , i n s t r i n g password) void logoutQ raises  (Fail); raises  (Fail);  s t r i n g r u n L o c a l A p p ( i n s t r i n g appName) r a i s e s s t r i n g runRemoteApp(in s t r i n g appName) r a i s e s string getLocalServiceListQ raises  75  (Fail);  (Fail); (Fail);  (Fail);  string getRemoteServiceListO  };  >;  //Author  : Kangming L i u  module PCE { typedef  string  ServiceName;  typedef  string  ServiceObj;  typedef  string  ServiceTypeName;  typedef  string  Constraint;  typedef  s t r i n g Preference;  typedef  s t r i n g PolicyName;  typedef  s t r i n g PropertyName;  typedef  string PolicyValue;  typedef  string PropertyValue;  typedef  s t r i n g HpropertyValue;  enum P r o p e r t y M o d e { PR0P_N0RMAL, PR0P_READ0NLY, PROP.MANDOTORY, PR0P_MAND0T0RY_READ0NLY .};  76  raises  (Fail);  enum. ObjectRefType { APPLI.OBJECT, • : '.. APPLI_CONFIG,  •  APPLI_RESOURCE_FILE  >; . s t r u c t HardwareCap{ s t r i n g Hname; HpropertyValue  value;  >; typedef sequence<HardwareCap>HardwareCapSeq s t r u c t Property {  .  PropertyName name; PropertyValue v a l u e ; PropertyMode mode; >; typedef sequence <Property> PropertySeq; struct Policy{ PolicyName name; . PolicyValue value; };  •typedef  sequence<Policy>PolicySeq;  s t r u c t Trade{ ServiceTypeName type; Constraint constr; Preference p r e f ;  77  PolicySeq p o l i c i e s ; PropertySeq  Properties;  >; struct Service{ ObjectRefType t y p e ; ServiceName serviceName; ServiceObj s e r v i c e O b j ; Trade t r a d e ; HardwareCapSeq hardwareCapSeq; >; typedef interface  sequence<Service>ServiceSeq; Profile{  a t t r i b u t e ServiceSeq s e r v i c e S e q ; void s e t ( i n PCE::ServiceSeq serviceSeq); P C E : : S e r v i c e S e q g e t ( i n s t r i n g username); };  interface  ProfileFactory{  P r o f i l e c r e a t e P r o f i l e ( i n s t r i n g User_name, i n ServiceSeq s e r v i c e S e q ) ; void deleteProfile(in Profile p); >; >;  module UA { s t r u c t Token{  78 \  s t r i n g low; string high; };  i n t e r f a c e UserAgent { boolean a u t h e n t i c a t e ( i n  string LUI,  in string boolean t o k e n a u t h e n t ( i n  password);  string LUI,  i n s t r i n g password, out Token t o k e n ) ; void inform_location(in string LUI, i n s t r i n g address); P C E : : P r o f i l e g e t p r o f i l e ( i n s t r i n g username) s t r i n g download(in s t r i n g f i l e n a m e ) ; boolean u p l o a d ( i n Token t o k e n , i n s t r i n g filename, i n s t r i n g data); boolean u p d a t e P r o f i l e ( i n s t r i n g username, in PCE::Profile p); v o i d l o g o u t ( i n s t r i n g username); };  79  

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-0051309/manifest

Comment

Related Items