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 Of User Mobility Support for U P C in J A V A / C O R B A Environment by Thong T r i Huynh B . A . S c . , Universi ty of Br i t i sh Columbia,1993 B . S c , Universi ty of Br i t i sh Columbia , 1996 A T H E S I S S U B M I T T E D I N P A R T I A L F U L F I L L M E N T O F T H E R E Q U I R E M E N T S F O R T H E D E G R E E O F Master of Science in T H E F A C U L T Y O F G R A D U A T E S T U D I E S (Department of Computer Science) we accept this thesis as conforming to the required standard The University of British Columbia August 1999 © Thong T r i Huynh , 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 X SO 1 1 Date Q Computer Science The 'University of 'British CoCumBia 2366 Main maCC yancovuer, 2?C Canada \6T 1Z4 . Abstract This thesis addresses the specification and implementation of the Universal Personal Comput ing ( U P C ) environment, developed at U B C for support of user mobility. In the U P C computing environment, each user has a unique global identification with which the user can access network services, computing resources, personal applica-tions, da ta files, and environmental configuration through any terminal , 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 Protocol ( 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 tool . A s an ini t ia l 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. C O R B A and Java offers an alternative approach in modelling the U P C concept that is flexible and portable to any computing platform. A U P C prototype is implemented using C O R B A as the architecture framework and Java as the programming language. Contents Abstract ii Contents iii List of Figures vi Acknowledgements vii 1 Introduction 1 1.0.1 Mot iva t ion 1 1.0.2 Thesis Objectives and Contr ibut ions 4 1.0.3 Thesis Outl ine 6 2 Background 7 2.1 Mobi le Host Protocol for IP (Mobile-IP) 7 2.2 Specification Description Language (SDL) 10 2.3 Universal Personal Comput ing ( U P C ) 11 2.3.1 User Identification 12 2.3.2 User Profile 12 2.3.3 Terminal Identification 13 ii i 2.3.4 Terminal Profile 13 2.3.5 U P C Network Architecture 13 2.3.6 Registration and Authent icat ion 15 2.4 Introduction to C O R B A . 16 2.4.1 Interface Definition Language ( IDL) 18 2.4.2 Object Request Broker ( O R B ) 19 2.4.3 C O R B A Object Services (CORBAserv ices ) 20 2.4.4 The C O R B A C o m m o n Facilities (CORBAfac i l i t i e s ) 22 2.5 C O R B A - b a s e d U P C . 22 2.5.1 Faci l i ty object . . . 23 2.5.2 Personal Compu t ing Environment ( P C E ) object . . . . . . . 23 2.5.3 Terminal Profile object . , 24 2.5.4 User Agent ( U A ) object 24 2.5.5 Terminal Agent ( T A ) object: 25 2.5.6 Init ial Agent ( IA) : 25 3 U P C ' s Registration and Service Negotiation Protocol ( R S N P ) 27 3.1 Overview 27 3.2 U P C Protocol Archi tecture Modif icat ion 29 3.3 S D L Specification of R S N P . . . . . . 31 3.3.1 Pseudo Mobi le - IP Block . ' . . . 35 3.3.2 Mobi le User Block 36 3.3.3 User Foreign Agent Block . 38 3.3.4 User Home Agent Block . 4 1 3.4 Prototype Implementation of U P C . 41 3.4.1 Assumptions and Requirements: . . . . . . . . 45 iv 3.4.2 Registration and Service Negotiation Procedure 46 3.4.3 Re-registration after Expi ra t ion of Connection Lifetime . . . 47 3.4.4 Re-registration after Hand-ofF . 48 3.4.5 Datagram Format used in Registration and Service Negotia-t ion Pro tocol • • • • 48 4 CORBA-based UPC Prototype Implementation 52 4.1 C O R B A - b a s e d U P C Prototype Implementation 52 4.1.1 Personal Comput ing Environment ( P C E ) 54 4.1.2 User Home Agent ( U H A ) 54 4.1.3 Terminal Profile . 55 4.1.4. Terminal Agent (TA) 58 4.1.5 Init ial Agent 60 4.1.6 Testing and Results 63 5 Conclusion and Future Works 66 5.1 Conclusion 66 5.2 Future Works 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 Provide Interoperability [23] . 18 2.3 O R B structure [23] •. 20 2.4 Col laborat ion of agents in the C O R B A - b a s e d U P C framework [30] . 26 3.1 System Diagram of U P C ' s Registration and Service Negotiation Pro-tocol 32 3.2 Block Diagram of a Pseudo Mobi le - IP 36 3.3 Block Diagram of a Mobi le User . . . '. 37 3.4 Mobi le User Agent 's Extended Fin i te State Machine 39 3.5 Block Diagram of a User Foreign Agent 40 3.6 User Foreign Agent 's Extended Fin i te State Machine 42 3.7 Block Diagram of a User Home Agent 43 3.8 User Home Agent 's Extended Fin i te State Machine 44 4.1 M a i n screen of the Service Manager uti l i ty 57 4.2 Login screen of the U P C ; . , . 61 4.3 U P C Appl ica t ion Manager screen . 62 vi Acknowledgements I would like to take this opportunity to thank D r . Son Vuong, my supervisor,, who has guided, supported and encouraged me throughout the Master program and especially this thesis. I would also like to thank my second reader, D r . George Tsiknis , for the time and valuable suggestions to this thesis. M a n y thanks to M a r i a Toeroe, Jinsong Zhu, and Kangming L i u for all the lengthy meetings and discussions on the U P C ' s issue. It has been a pleasure to work with all of you. Final ly , 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 of British Columbia August 1999 vi i Chapter 1 Introduction 1.0.1 Mo t i va t ion In recent years, the term "Internet" has become a household word. The 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 , Wor ld Wide Web, Internet chat (e.g. I R C , Microsoft Cha t ) , Internet video conferencing (e.g. CuSeeMe, S D R , NetMeet ing) , and Internet radio (e.g. RealPlayer) are widely used on computers at home and at work. Meanwhile, portable computers have become more compact, yet more pow-erful, wi th increased processing and storage capabilities. They are available in in-creased diversity, ranging from laptop, to notebook and palmtop computers. In addition, the communication capabilities of these portable computers are impres-sive 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 high-speed wireless L A N products, in addition to low-speed wide area wireless network and medium-speed metropoli tan area wireless network services. Th is 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 moving be-tween offices, homes, automobiles, conference rooms, and so forth. Whi le they are on the move, they may want to be able to perform computing and/or communica-t ion. A s they move around, they may have access to enormous computing facilities such as advanced workstations, desktop computers, compact P D A s (Personal D i g -i ta l Assi tant) , and convenient locally available services, such as faxes and printers. However, they often find themselves de-coupled from their familiar "home base" computing environment when using these foreign computing facilities. I t .would be better if the user could have the same personal computing environment, regardless of the computer's platform, the computer's location, or the user's location. The combination of increasing use of portable computers, the rapid advance-ment of wireless communication technologies, and the fact that most users are mo-bile, requires a special computing environment that supports mobile computing. Mobi le computing refers to an area of technology that aims at providing access to computing resources, independent of motion, location, computing platform, com-munication device, and communication bandwidth. The independence refers to the-concept of a computing environment that automatically adjusts to the processing, communications and access available at any moment. Ideally, a user can travel from place to place and sti l l use the computing facilities they desire in their new location or even while they are on the move. 2 Currently, a user can obtain mobile computing by install ing a cellular tele-phone interface into their portable computer and running a protocol such as S L I P •or P P P over a dialup service. Th is approach is simple and cheap; however, there is a severe l imitat ion in that the user can only access Internet resources within a single administrative domain. Th is l imitat ion is due to the Internet's inabil i ty to ' suppor t mobility, neither user nor terminal mobility. In regards to terminal mobil-ity, the current version of the Internet protocol is built, on an implici t assumption that the point at which a computer is attached to the Internet is fixed, and its IP .address uniquely identifies this point of attachment. The IP address is used by the Internet's routing protocol to deliver the IP packets to the intended receiver. When a computer moves to a different network, its network services are lost because its IP address does not reflect its new point of attachment to the Internet, and the routing protocol is unable to correctly route the packets to i t . In this situation, the computer must be reconfigured wi th a new IP address associated with the new network. Doing so causes the lost of already-established transport layer connections (for example, ftp or telnet sessions). Similar l imitat ions apply to mobile users, where each user is registered to one administrative domain and granted a user login ID that allows the user to access only the computing resources and network services in the registered administrative domain. 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 Protocol •for Internet Protocol) that supports terminal (or host) mobil i ty has recently been defined by the Internet Engineering Task Force ( I E T F ) as in R F C 2 0 0 2 [25]. This protocol is often referred to as mobile-IP. Mobi le - IP allows a terminal to roam 3 freely on the Internet while sti l l maintaining one permanent IP address. However, supporting only terminal mobili ty is not sufficient to provide a seamless mobile computing environment. Even with mobile-IP support, a mobile user st i l l can not login to any available terminal , stationary or mobile, in a foreign administrative domain. A s a result, this introduces a need for an addit ional level of mobili ty on top of terminal mobil i ty: user (or personal) mobility. Personal mobil i ty is different from terminal mobility. Terminal mobil i ty refers to the abili ty of a portable terminal to access services from any location while in motion, and the capability of the network to locate and identify the mobile terminal as it moves [10]. On the other hand, personal mobil i ty refers to the abili ty of the end user to send and receive calls, and to access subscribed services on any terminal in any location, and the abili ty of the network to identify the end user as they move [10]. 1.0.2 Thesis Object ives and Contr ibut ions Support ing both terminal and personal mobil i ty is the fundamental requirement of mobile computing; however, very little work has been done to support personal mo-bility on the Internet. A new computing paradigm that supports both terminal mo-bility and personal mobil i ty over the Internet, called Universal Personal Computing ( U P C ) , has been developed [20,35] jo int ly in the Department of Computer Science and the Department of Electr ical and Computer Engineering of the Universi ty of Br i t i sh Co lumbia . . Th is research constitutes a major activity of Internetworking Wireless D a t a Networks for Mobi le Comput ing (TWIN), a project joint ly funded by the N S E R C of Canada and Moto ro l a Canada . U P C is a computing environ-ment which enables a mobile user to access computing resources, network services, personal applications, da ta files, and environmental configurations through any ter-4 minal , stationary or mobile, anywhere on the Internet [21]. In this environment, terminal mobil i ty and personal mobil i ty are managed separately. Terminal mobil i ty is supported using mobile-IP with some enhancements in TCP-connec t ion manage-ment; whereas personal mobili ty is managed v i a an agent-based architecture. The core of U P C ' s mobili ty management is the Registration and Service Negotiation protocol ( R S N P ) . In this thesis, we use the Specification and Description Language (SDL) to produce a clear and precise specification of R S N P . We also simulate R S N P using a S D L supported tool to verify for R N S P completeness and correctness. In addit ion, the R S N P simulation can be used to 'simulate 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 programming 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. The distributed nature of U P C ' s components makes the implemen-tation of U P C very complex and even impossible. Fortunately, several technologies that support platform independent distributed object architecture, such as C O R B A and D C O M , are available. Combining of concept of the U P C and C O R B A tech-nology 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 Java as the programming language, Visigenic's Vis iBroker for Java as the C O R B A framework, and Sun Microsystem's Solaris 2.x as the. comput-ing platform. 5 1.0.3 Thesis Out l ine The rest of the thesis is organized as follows: • Chapter 2 provides the necessary background material including 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 . • Chapter 3 presents U P C ' s R S N P formal specification using S D L , and a pro-totype of U P C ' s R S N P using C and T c l ' / T k . • Chapter 4 presents the prototype the of C O R B A - b a s e d U P C . • Chapter 5 concludes the thesis and discusses possible future works. 6 Chapter 2 Background 2.1 M o b i l e Host P r o t o c o l for I P (Mobi l e - IP ) The current version of Internet Pro tocol (IP v 4 ) has been built on the implici t assumption that the point of attachment of a computer to the Internet is fixed and uniquely identified by its IP address. IP packets sent to a computer are delivered based on the location information in the IP packet's headers, i.e^ the destination IP address. When a mobile computer moves to a new network, the IP address that is configured in the computer does not reflect the new point of attachment. Thus, the IP 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 IP address that reflects the new point of attachment in the visit ing network. Unfortunately, although the suggested method above may solve the routing problem, it presents two new problems. The first problem is the loss of any established transport and higher-layer connection during handoff when changing the IP address. The second problem rests on the burden 7 of informing potential correspondents of the new IP address. Therefore, we need a new mechanism to support the mobil i ty of a computer (often referred as host) over the Internet. Mobi le Host Pro tocol for IP (Mobile-IP) is an enhancement to IP that allows a mobile computer with a permanent IP address to communicate data transparently to application software, and independent of its current point of attachment to the Internet. The Mobi le - IP is standardized by the Internet Engineering Task Force ( I E T F ) as defined in the R F C 2 0 0 2 [25]. The standard Mobi le - IP supports host mobil i ty independent of the communication medium in use. It works as effectively in a wireless environment as it does in a wired internetworking environment. The Mobi le - IP architecture consists of a set of special entities called the Mobi le Host [MH],- the Home Agent [HA] , 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 attach-ment to the Internet from one network to another. Each M H belongs to a unique home network and is assigned a permanent IP address. When a M H is away from the home network, it is associated wi th a temporary IP address that is often referred as a care-of IP address. The care-of IP address identifies the M H ' s current point of attachment to the Internet. A care-of IP address could be either the IP address of the F A that the M H is registered to, or a local IP address that is assigned to the M H at the visi t ing 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 IP address) for all mobile hosts under its administrat ion. The H A is responsible for intercepting IP packets destined for a M H and tunnelling these IP packets to the M H via 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. The F A is re-sponsible for de-tunneling and delivering IP packets sent from the M H ' s H A to the registered M H . A F A also serves as a default router for IP packets sent by a registered M H . The H A and F A advertise their presence in the network using an Agent Adver t is ing message. The Agent Adver t is ing message is a router advertisement message with a special Extension 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 mobil i ty services. However, i f the M H has just returned to its home network from a foreign network, de-registration with the H A is required. A s a M H detects it is on a foreign network, it obtains its care-of IP 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 IP address). When a M H is away from the home network, IP packets destined to it are always first sent to its home network, and then encapsulated by the H A and re-sent to the M H ' s current F A . Encapsulat ion refers to the process of enclosing the original IP packet as data inside another IP packet with a new IP header. The routing information in the original IP packet, source and destination address, remain unchanged. The outer IP packet header specifies the M H ' s care-of IP address as the destination address and the M H ' s H A IP address as the source address. The encapsulated IP packet is then sent to the care-of IP address v ia a conventional IP routing mechanism. Wi thou t IP encapsulation, IP 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 IP address as the destination address in their headers. Upon receiving an encapsulated IP packet, the F A extracts-the inner IP packet from the encapsulated IP packet and delivers the extracted packet to the appropriate visi t ing M H on its local network. Conversely, when the M H sends IP packets, they are directly routed by the F A to their destination using conventional IP routing mechanisms. Passing these IP packets through the M H ' s H A is not necessary. 2 . 2 Specification Descr ip t ion Language ( S D L ) The Specification Description Language ( S D L ) , developed and standardized by Comite Consul ta t i f International Telegraphique et Telephonique ( C C I T T ) , is a for-mal specification language. The S D L can be applied to specify a variety of systems from telecommunication systems, data communication systems, real t ime systems and interactive systems, to distributed systems. The S D L focuses on the reactive behaviour of a system. It is concerned with how external s t imuli and responses are related at system interfaces, instead of the internal and physical construction of a system. The S D L can be used in both textual and graphical representations. The 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. The textual S D L looks similar to a programming language. Fragments of textual S D L can be embedded in diagrams where text is more suitable or the graphical symbol does not exist (e.g. signal declarations, data 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 wi th each other and the environment v ia channels. The 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. We can describe S D L processes as extended. F in i te State Machines ( F S M ) . Each S D L process works autonomously and concurrently wi th other S D L processes. S D L processes communicate with each other using discrete messages called signals. Each signal has a name, sender identity, and possible addit ional data. The F S M uses the name of the signal to make a transition from one state to another state. 2.3 Unive r sa l Personal C o m p u t i n g ( U P C ) Universal Personal Comput ing ( U P C ) is a computing paradigm that supports loca-tion independent network computing 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 computing over the Internet, rather than telecommunica-tions. In the U P C environment, each user has a unique global identification. Using this identification, the U P C network enables users to access network services, com-puting resources, personal applications, da ta files, and environmental configuration through any terminal, stationary or mobile, wired or wireless networking, anywhere 11 on the Internet. 2.3.1 User Identif ication In U P C , each user is assigned a Logical User Identifier (LUI) that is globally unique and independent of the user's current location. A s proposed in L i and Leung [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. Using the email address as L U I has several advantages. F i r s t of a l l , 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 IP address from the user's home domain address port ion in the L U I . "This obviates the need for global user-names server, and is compatible with the current Internet architecture" [21]. 2.3.2 User Prof i le Another component of U P C is the User Profile. Each mobile user has a service profile kept in a user database at their home network. The service profile contains authentication information, such as the user login ID and the corresponding pass-word. The service profile also defines a set of computing resources, network services, and personal applications that a mobile user is entitled to while at home or on the road. For each personal application, computing resource, or network service, there is a set of user preferences, such as environmental requirements, configuration, de-fault settings, and so on. Modi fy ing 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 Termina l Identif ication In the U P C environment, each terminal is identified by a Logical Terminal Identifier (LTI) . In the current I E T F standard of Mobi le-IP, each mobile terminal ( M T ) is associated with two IP addresses, in particular the M T ' s permanent IP address and the M T ' s care-of IP address. The M T ' s permanent IP address is used in identifying the M T at the network level, and the M T ' s care-of IP address is used in discovering the M T ' s current location. IP packets addressed to a M T are redirected to the M T by tunneling to the M T ' s care-of IP address. Since we want to achieve back-ward, compatibi l i ty with the current Internet protocol suite, we selected the M T ' s permanent IP address as the M T ' s L T I , and the M T ' s care-of IP address provides the M T ' s current location. We can then use the same tunneling mechanism as in mobile-IP to redirect packets to the M T ' s current location. 2.3.4 Termina l Prof i le The terminal profile is used to re-create the computing environment specified by a user. Each mobile terminal has a terminal profile kept in a terminal database at the mobile terminal 's home network. The 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 Arch i tec ture U P C network is an agent-based architecture that consists of three functional entities: a Terminal Home Agent ( T H A ) , a User Home.Agent ( U H A ) , and a Foreign Agent 13 ( F A ) . User Home Agent (UHA): Each administrative domain has a User Home Agent . The U H A maintains a database of all the users registered in this administrative domain as well as their associated user profiles. A l o n g with the user profile, the U H A also keeps a record of all users' current location information. Th is location information is a binding information between the mobile user (i.e. L U I ) , the terminal (i.e. LTI ) that the mobile user is currently using, and the current location of the terminal (i.e. care-of IP address). Whenever the user moves or changes their association with 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 Terminal Home Agent ( T H A ) . The T H A maintains a database of all the mobile terminals that the network is configured to serve, as well as their associated terminal information, such as the terminal identity, the terminal profile, the terminal authentication key, and the current location of the terminal (i.e. care-of IP address). Foreign Agent (FA): If the administrative domain serves mobile users, it has a Foreign Agent . The F A enables the user and mobile terminal to be temporarily use the network so that 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 visi t ing the network. 14 2.3.6 Regis t ra t ion and Authent ica t ion In the U P C environment, user mobil i ty is handled independently from terminal mobili ty; thus, registration is separated into two registration procedures, terminal registration for the mobile terminal and user registration for the mobile user. Ter-minal registration must be performed before user registration so that the terminal is recognized by the foreign network and ready for user registration. Bo th 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 Mobi le- IP . The sequence of events for terminal registration is as follows: 1. The M T registers wi th the F A in the visited network. 2. The 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 IP address. 3. Upon successful registration and authentication, the terminal 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. The M U sends a registration request to the F A in the visi t ing network. 2. The 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 IP address of the M T ' s T H A that the M U is currently on. 15 3. - The M U ' s . U H A retrieves the M T ' s terminal profile from the M T ' s T H A and then evaluates a set of suitable services for the M U . 4. Upon 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 In t roduct ion to C O R B A The Common Object Request Broker Archi tecture ( C O R B A ) , proposed by the Ob-ject Management Group ( O M G ) , is a new software technology that combines object-oriented technology and distributed client-server.computing to provide an industrial standard distributed object architecture. C O R B A enables applications to interact with one another without knowing where the corresponding application resides, how the corresponding application is implemented, or what operating system the corre-sponding 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. Th is section provides a tour of major components of C O R B A such as the In-terface Definition Language ( IDL) , the Object Request Broker ( O R B ) , the C O R B A Object Services (CORBAserv i ce s ) , and the C O R B A Common Facilities ( C O R B f a -cilities). Figure 2.1 presents C O R B A ' s Object Architecture . 16 Application Objects Common Facilities (CORBAfacilities) Object Request Broker (ORB) ^Trade^ bcfricurrenc) ^ i m e ^ R^ lationshipfe f^Query^ (^ oltection^  ^Security) lia^ isactio^ is ^Events^ ficensing) Ej/ernalizati^ n Common Object Services (CORBAservices) Figure 2.1: CORBA Object Architecture [23] 17 c + + , (smjj ^MaJ ^ 0 B 0 | 0 Client D C Server Object Request Broker (ORB) Figure 2.2: I D L Language Bindings Provide Interoperability [23] 2.4.1 Interface Def in i t ion Language ( IDL) 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 . The I D L is a lan-guage that is used to describe the external behaviour of an object without providing any underlying implementation details about an object. The I D L makes a strong 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. Thus, I D L enables an object wri t ten in one language to communicate with another object writ ten in an unknown language. Figure 2.2 presents the I D L interoperability concept. The I D L grammar uses the same lexical rules as 0 + + , introduced with several new keywords to support distributed-computing concepts. A n object's at-tributes, 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. The 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 Object Request Broker ( O R B ) The O R B is the central component of C O R B A . In the OSI network model, the O R B sits between the data and application layers. The 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. The 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. The 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 dynamic method invocations. The static method invocation interfaces are defined at compile time and presented to the client as stub code. The dynamic method invocation interfaces are dynamical ly discovered at run time using the C O R B A Interface Repository. A n Interface Repository is an on-line database that contains real-time information describing all the interfaces that an object supports along with its parameters. The 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 ia the Internet In te r -ORB Proto-col ( H O P ) . "The H O P is basically a T C P / I P with some C O R B A - d e f i n e d message exchanges that serve as a common backbone protocol" [23]. 19 Object Implementation A Static Skeletons Dynamic Skeleton nvnnatinn Object Adapter lm ilementati 31 Repository Object Request Broker Co re (MOP) Figure 2.3: O R B structure [23] 2.4.3 C O R B A Object Services ( C O R B A s e r v i c e s ) The term C O R B A Object Services refers to fundamental (system-level) object in-terfaces that extend the functionality of O R B . They are the most commonly used services in building any application. The 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 providing operations for monitoring the use of an object. Currently, 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 terminating an object. The Persistence Service: provides common interfaces to persistently store the state of an object. The Naming Service: locates an object by object name. 20 T h e Event Service: supports the asynchronous communication between objects using events. T h e Concurrency Control : provides distributed locks on a given object. T h e Transaction Service: provides two-phase commit coordination among ob-jects. The Relationship Service: provides mechanisms to create, delete, navigate, and manage the dynamic association between objects. T h e Externalization Service: provides mechanisms to convert the state of an object into a stream of data and vice versa. T h e Query Service: provides query operations for objects. T h e Licensing Service: provides operations for monitoring the use of an object. T h e Properties Service: provides mechanisms to associate properties to an ob-ject. T h e T i m e Service: supports time synchronization in a distributed object envi-ronment. The Security Service: offers a framework for distributed object security. The Trader Service: matches or locates an object by its properties. The Collection Service: provides interfaces to create and manage the most com-mon collections. T h e Startup Service: starts up an object when an O R B is invoked. 21 2.4.4 The C O R B A C o m m o n Faci l i t ies ( C O R B A f a c i l i t i e s ) The 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. They are related to and extended from the existing C O R B A s e r v i c e s . The C O R B A f a c i l i t i e s is st i l l under construction. 2.5 C O R B A - b a s e d 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 Broker Architecture, C O R B A , is selected as a middleware layer that provides a homogeneous distributed computing environment independent from the underlying hardware and software technology. In addition to providing a homogeneous distributed computing environment, C O R B A also defines a set of Common Object Services (CORBAserv ices ) and C o m -mon Facilities (CORBAfac i l i t i e s ) that provide building blocks for developing any C O R B A based application. The C O R B A s e r v i c e s support generic and common func-tionality, such as creating an object, naming an object, and resolving the reference of an object. The 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. Taking 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 Cycle Service, the 22 Naming 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, terminal mobil i ty is handled by the Mobi le- IP . Terminal migration in Mobi l e - IP is transparent to the T C P and the higher network layers in the OSI model. Since C O R B A sits above the T C P / I P layer, terminal 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 Faci l i ty object, the Personal Comput ing Environment object ( P C E ) , the Terminal Profile object, the User Agent object ( U A ) , the Terminal Agent object ( T A ) , and the Initial Agent object ( IA) . 2 . 5 . 1 Faci l i ty object A facility object is a representation of a computing 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. On the other hand, a shared facility is specialized for a group of users and available on a certain network. To a great extent, a shared facility can be general-purpose and available for everyone, everywhere. 2 . 5 . 2 Personal Comput ing Env i ronment ( P C E ) object Each user has a Personal Comput ing Environment ( 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 Terminal Profile object). The 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 Termina l Prof i le object Each terminal has a terminal profile object kept locally at the terminal that defines the capabilities of the terminal . B o t h the terminal 's physical and software capabili-ties are specified in the terminal profile object. B y Physical capabilities, we refer to the physical properties of a terminal , 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 terminal . 2.5.4 User Agent ( U A ) object Each user has a U A object that acts on behalf of the user in the system. The U A object's main task is to manage a user's P C E object. In addit ion, 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. The 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 in C O R B A ' s Naming Services. Thus, an U A object can be located from a user's L U I with the assistance of the C O R B A ' s Naming Service. 24 2.5.5 Terminal Agent (TA) object: •Each terminal has a T A object that represents the user at the foreign network. The T A object has a reference to the user's terminal 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 maintain. Moreover, the T A object is also responsible to discover all the facilities that are available at the visi t ing network, using both C O R B A ' s Name Service and C O R B A ' s Trader Service. 2.5.6 Initial Agent (IA): A n ini t ia l agent is an active process that runs at a terminal 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 Name 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 terminal specific P C E object at a terminal . Figure 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 Protocol ( 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 behav-ior of a system, such as Language of Temporal Ordering Specifications ( L O T O S ) and Estelle Formal Description Technique. 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 ISO (International Standards Organizat ion). This fact ensures that S D L wil l be maintained and supported in the future. 27 • S D L is popular and widely used in the telecommunication industry. • The graphical S D L is intuitive and easy to work wi th . It clearly displays the relationships between blocks, processes and how they interact. • The nature of S D L is suitable for specification of a communication protocol since the S D L process is described as Extended F S M . The F S M is an excellent model for any communication protocol design. In regards to the S D L tool, we used the tool developed at the K F K I Research Institute for Measurement and Comput ing Techniques in Hungary. Th is S D L tool 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 grammar of the S D L 1992 version. The editor has a syntax checker, which helps to create syntactically correct S D L specification. The S D L simulator represents a S D L system as a block diagram, and displays the output of the simulation in the form of a time diagram or a message sequence chart ( M S C ) . We 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. For 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 that come up. 28 3.2 U P C P r o t o c o l Arch i t ec tu re Modi f i ca t ion R S N P is specified with 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. The modifications and their justification are as follows: • Terminal related information such as the terminal identity and the terminal profile are kept locally at the terminal . The terminal identity is the perma-nent IP address of a terminal . The terminal profile is basically the terminal configuration information, such as resident operating system, file format, and monitor display mode, and so on. Th is information is currently available at any terminal so there is no need to replicate the information at the T H A . This alleviates the need for database management in the T H A . • We extended the terminal profile to store information about software appli-cations 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. The 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 terminal . • Since the terminal profile is kept locally at the terminal, there is no need for a Terminal Home Agent . • We introduce a new agent, called Mobi le User Agent . Th is agent runs locally at a terminal and provides a login interface to users. The Mobi le 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 that restrains the user from unregistered services. Each foreign network has a Service Profile that specifies the computing re-sources and network services that are available at this particular network, and the personal applications that are allowed to execute while the mobile user is visi t ing the network. The U F A provides access to this Service Profile during the service negotiation phase. We introduce a temporary service profile located at a terminal , called User-Terminal Service Profile. Th is profile has the same format as any other service profile and is created after a successful registration. The User-Terminal.Service Profile is the intersection between the User Service Profile and the Terminal Service Profile, and is created once for each login session. Th i s service profile exists because the binding between a mobile user and mobile terminal 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 terminal experiences a hand-off wi th an ongoing session. We introduce a temporary service profile located at a terminal , called Session Service Profile. Th is profile is specific to a particular valid login session within a particular visit ing network. It is the intersection between the User-Terminal Service Profile and the U F A Service Profile. The login user's access is limited to the services that only exist in the Session Service Profile. Th is 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. Th is system consists of one block called M o b i l e l P , one block called Mobi le 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 Home Agent ( U H A ) . Figure 3.1 presents the System Diagram of the U P C ' s Registration and Service Negotiation Pro tocol . (Please note this diagram is for i l lustrat ion purpose only, it is not the system diagram that is directly printed put from the S D L ' s graphical representation.) • The M U block is connected to the environment through a channel called User, to the Mobi le - IP block through a channel called M I P , and to the U F A block through a channel called M U - U F A . • The U F A block is connected to the U H A block v ia a channel called U F A J J H A , and to the environment v ia a channel called U F A J D e b u g . • The U H A block is connected to the environment through a channel called U H A _ D e b u g . On 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 User channel: this channel carries the S D L ' s signals between the environ-ment (i.e. a user) and a M U block. The S D L signals carried in this channel are as follows: 31 JC u E o o m X c o V (A 3 < 0X1 s Q S 3 cr s i) xs w 3 < cr tu *, 1/2 O Cu C •s-3 < a . tu ai i C/5 4V c • C s I t l . p. X> CU Q, 0 0 I 3 O XI _ c tu a a n tu tu M i fe 'S M 2 2 S w £ 2 ocr is tu o =' 8 c r CD ai, 1 cr 1 ) 2 OS. - C 3C -cn o c s •a — 4—S-< o o o o O H C _o .2 •' o W> cu Z a> '> •— <L> 0 0 -o. c ni C _g 03 6 0 OS u H3 4> •4-P 2 % I so < a UH U . O Q eu S s cs -C U s-0 0 3 X) CU Q t o1 8..§-' C O 0 0 c o 5 § 00 3 XI tu °, C J « -5H O0 3 a S3 c« > tU 0) in a> B o o o m e U a. o .5 § . oo so o. o 00 . 3 X c-Q a . 1 . a. « CM p j" SO C3 . B S es J = U - tn Figure 3.1: System Diagram of UPC's Registration and Service Negotiation Protocol Login signal: this signal describes a login request from a user with the in-put parameters, such as the user's L U I , the user's password, and the IP 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 prompt 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 Mobi le - IP sends to the M U , informing it that the te rminal is moving into a new foreign network. It has the new U F A IP 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. The 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 IP 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 ID, 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 ID , 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 ID , 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- reg-istration of a valid established connection. It has a connection ID 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. The S D L signals carried in this channel are as follows: • 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 output parameters. The UFAJDebug and the UHA_Debug 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 M I P channel: this channel carries the S D L signals between a M U block and a Mobi le - IP block. There is only one signal, called Locat ion Update , on this channel. Th is signal has the new U F A ' s IP address as the input parameter. 3.3.1 Pseudo Mob i l e - IP B lock The Mobi le - IP block describes a pseudo mobile-IP. Figure 3.2 is the block diagram of the Mobi le - IP block. The Mobi le - IP block contains one single process called MIP_Pseudo 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 / \ MIP Pseudo From MIP Signal Route Process \ / Figure 3.2: Block Diagram of a Pseudo Mobi le - IP 3.3.2 Mob i l e User B lock The M U block describes a Mobi le User Agent as mentioned in section 3.3. This 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. This block contains one process called MU-Proces s whose behaviour is de-scribed in the attached extended F S M , in figure 3.4. The MU_Process consists of four states: the Idle state, the Registering state, the Registered state, and the Negotiation state. Idle state: in this state, the MU_Process is ready to accept a login request from a .; user. Registering state: the MU_Process enters this state after receiving a login request from a user or a location update message from the Mobi le - IP . Dur ing this state, the MU_Process contacts the U F A to request a connection and waits for 36 Block M U (Mobile User) Prompt Error Report Message_Debug Login Logout User Signal Route MU Process Connection_Rep UserServiceProfile_Rep UFA_ServiceProfile_Rep Connection_Req UserServiceProfile_Req. UFA_ServiceProfile_Req Deregistration_Req UFA Signal Route IjLocation Update] MIP Signal Route Figure 3.3: Block Diagram of a Mobi le User 37 a reply. Registered state: the MU_Process 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 MU-Proces 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 B lock The U F A block describes a U F A . Figure 3.5 illustrates the block diagram of the U F A block. There is one process in the U F A block called UFA_Process , whose behaviour is described in the attached extended F S M , in figure 3.6. The UFA_Process consists of four states: the Idle state, the Process Connection Request state, the Session Established state, and the User Service Profile Request Processing state. Idle state: in this state, the UFAJProcess is ready to accept a connection request from the M U . Process Connection Request state: in this state, the UFA_Process processes the connection request from the M U . It contacts the specified U H A to authen-ticate 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 Figure 3.4: Mobi le User Agent 's Extended Fin i te State Machine 39 Block U F A (User Foreign Agent) Connection_Rep UserServiceProfile_Rep UFA_ServiceProfile_Rep Connection_Req UserServiceProfile_Req UFA_ServiceProfile_Req Deregistration_Req M U Signal Route UFA Process Authen_Rep Authen_Req USP_Rep USP_Req UHA Signal Route UFA Signal Debug Route Error_Report WrongSeqno_Debug InvalidConnectID_Debug Message_Debug Figure 3.5: Block Diagram of a User Foreign Agent 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 . Figure 3.7 diagrams the U H A block. There is one process in the U H A block called UHA_Process , whose behaviour is described in the attached extended F S M , in figure 3.8. The UHA_Process consists of three states: the Idle state, the Checking ID and Password state, and the Service Profile Request Processing state. Idle state: in this state, the UHA_Process is ready to accept any requests from the U F A . Checking ID and Password state: the UHA_Process enters this state after re-ceiving a request for user authentication. Service Profile Request Processing state: the UHA_Process enters this state after receiving a request for a user's service profile. 3.4 P ro to type Implementat ion of U P C After having a concise specification, we implemented a prototype of R S N P on Sun Microsystem Solaris 2.x using C as the programming language. The user graphical interface was written in T c l / T k . The implementation code space is roughly about 8000 lines. The prototype of R S N P is subjected to the following assumptions and requirements: Figure 3.6: User Foreign Agent 's Extended Fin i te State Machine 42 Block U H A (User Home Agent) Authen_Rep USP_Rep U F A Signal Route Authen_Req USP_Req U H A Process U H A Signal ErrorJReport WrongSeqno_Debug Messag_Debug Debug Route Figure 3.7: Block Diagram of a User Home Agent 43 4 4 3.4.1 Assumpt ions and Requi rements: • The applications supported here are l imited to internet applications such as web browsers (e.g. Netscape, Mosaic) , news clients , mail clients, and so on. • Th is prototype implementation does not support multi-platforms. The sup-ported platform considered here is U N I X . • A local user whose login mobile terminal comes from a foreign network is considered a visi t ing user since the mobile terminal may not support all the services that a fixed terminal in this network supports. • The U F A and the Mobi le - IP Foreign Agent (FA) are required to operate on. the same machine, or in other words, they should have the same IP address. This requirement makes the agent ( U F A ) discovery procedure in the U P C efficient and simple. A s a mobile terminal ( M T ) and a mobile user enter a foreign network, the Mobi le IP detects the move and informs the M U of the current U F A ' s IP address (this should be the same as the F A IP address). The Mobi le - IP 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 IP address or the name of the host that U H A is currently running on. The 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 Regis t ra t ion and Service Negot ia t ion Procedure The 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 Mobi le User ( M U ) is configured to know the location of the U F A in its home network. The following is the sequence of events during the Registration and Service Negotiat ion: • After receiving the user's information, such as the L U I , the password, and the U H A ' s IP address, the M U at the login terminal verifies whether the user is local or foreign by comparing the domain portion of the L U I and the current U F A ' s IP address. The terminal 's type, fixed or mobile, is identified from the terminal configuration. If the user is local in this administrative domain and the terminal is fixed, the M U allows this user to login locally. The user has full access to any services and applications available. If the user is from a foreign administrative domain, or the user is local in this administrative domain but the terminal is a foreign terminal , 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. • The 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 ID and sends a connection acceptance message along with this connection ID to the M U . • After the registration succeeds, the M U initiates the service negotiation pro-cedure by sending a request for the User Service Profile to the U F A . The U F A forwards this request to the user's U H A . The 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 User-Terminal Service Profile by intersecting the User Service Profile wi th the Terminal Service Profile. • If the User-Terminal 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 Pro-file by intersecting the U F A ' s Service Profile wi th the User-Terminal Service Profile. 3.4.3 Re-regist rat ion after Exp i ra t i on of Connect ion L i fe t ime Each connection granted from the U F A has a unique ID and a l imited lifetime. A connection becomes invalid if the connection lifetime at the U F A expires. To main-tain a connection, the M U has to send a re-registration request whenever its connec-tion lifetime expires. The 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 ID and requested desired lifetime. If the connection ID is valid, the U F A updates the connection.lifetime for this connection ID and then sends a reply back to M U . 47 3.4.4 Re-regist rat ion after Hand-of f Hand-off only occurs with a mobile terminal . The hand-off in the mobile terminal is handled by the Mobi le IP. The M U detects a move into a foreign network when it receives a location update message from the Mobi le IP and the U F A ' s IP address in the location update message is different from its current connected U F A ' s IP address. If the M U is serving an ongoing session, it performs the re-registration procedure. The M U contacts the new U F A and provides it wi th all the user's information such as the L U I , the password, and the U H A ' s IP address. To authenticate the user, similar steps as used in the registration procedure are carried out. The 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 wi th 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 cre-ated from intersecting the User- Terminal Service Profile and U F A ' s Service Profile. Current running services or applications that do not exist in the Session Service Profile are considered illegal and are immediately terminated by the M U . 3.4.5 Datagram Format used in Regis t rat ion and Service Negot ia-t ion Pro toco l Communication between MIP and M U This is the datagram format for the location update packet from Mobi le IP. • U D P fields - Source Por t : variable - Destination Por t : 9999 48 • The U D P Header - Type : Locat ion Update - Locat ion: IP address of U F A Communicat ion between M U / U F A or U F A / U H A 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 ID, password, and service profile are inserted into the data portion after the header.. • U D P fields — Source Por t : variable — Destination Por t : copied from the source port of the corresponding Re-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 • The U D P Header — Type : * Connection Request * Connection Reply * Authent icat ion Request * Authenticat ion Reply * User Service Profile Request 49 * User Service Profile Reply * U F A Service Profile Request * U F A Service Profile Reply Code: A value indicating the result of the request. It is set to 0 in the request packet. Possible errors are: * For Connection Request • Registration Accepted • Registration Denied • Unspecified Reason • Insufficient Resources • Authent icat ion Failed • Requested Lifetime Too Long • Poor ly Formed Request • Unknown U H A Address • U H A host is Unreachable . • U H A port is Unreachable ' * For Authent icat ion Request • Authent icat ion O K • Authent icat ion E R R O R : • Unspecified Reason • Identification Mismatch • Poor ly Formed Request • Un-Registered User 50 * For User Service Profile Request • O K • E R R O R , Unspecified • U H A Unreachable * For U F A Service Profile Request • O K • E R R O R , Unspecified • U F A Unreachable Lifetime: The 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 wi th an error code. U H A : IP address of the User Home Agent Seqno: the sequence number of this packet. ID: the connection ID 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 ID . D a t a length: the length of the data 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 Pro to type Implementat ion In this chapter, we present the implementation of the C O R B A - b a s e d U P C proto-type. 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 wi th C O R B A as the object bus that facilitates the interaction, integration, and distr ibution of these objects. We implemented the prototype using Java as the programming language, Visigenic's Vis iBroker for Java as the C O R B A framework, and Sun Microsystem's Solaris 2.x as the computing platform. The prototype code space is approximately 5000 lines. Because the implementation is a prototype and there are insufficient comput-ing resources, the prototype is implemented based on the following simplifications and requirements: 52 • The U P C architecture utilizes a wide range of services defined by the C O R B A Object Services, such as the Naming Service, the Trader Services, the Life Cycle 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. The service discovery and service negotiation procedure is simplified to a direct mapping in the application name and configuration name. Thus, the terminal profile is simpler than the terminal profile proposed in Zhu, Toeroe, Leung, and Vuong[35]. O n our implementation the terminal profile defines only the software capability of the terminal , wi th no information regarding the termi-nal's physical capability. • The terminal must support Java and C O R B A ' s O R B . In addit ion, there must be enough memory in the terminal 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. Then, 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. The 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 Comput ing Environment ( P C E ) , User Home Agent ( U H A ) , Terminal Profile, Terminal Agent ( T A ) , and Initial Agent . 53 4.1.1 Personal Compu t i ng Env i ronment ( P C E ) Each user has a P C E which is kept and maintained at the User Home Agent. The P C E is designed to specify enough information so that the Terminal Agent 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. The I D L code of the P C E is attached in. Append ix A . The P C E is a list of service structures, each of. which is composed of: • Service Name: the.name of a service object, defined as a str ing. • Service Type : the type of service object, i.e. an application client object, . application configuration, or network resources. • Service Object: the reference to a service object. This object can be an applica-' t ion client object, an object that allows access to an application configuration, or an object that allows access to network resources. • Trade Information: a structure that stores all the necessary information needed for the C O R B A Trader Services to discover or locate a service, i.e. the service type, the service properties, the constraint of the search and the search policies. • Hardware capabili ty: a list of the requirements about physical hardware sup-port for this "service. For example, to play a midi file, a terminal is at least required to be equiped with a sound card and speakers. 4.1.2 User Home Agent ( U H A ) ' For each administrative domain, there is a U H A . The U H A manages the list of users registered in its administrative domain, and the users' corresponding P C E s . The 54 I D L code of the U H A is attached in Appendix A . The U H A exports the following services: • boolean tokenauthent(in string L U I , in string password, out Token token): This method authenticates a, user identified by the L U I and the password. Upon successful authentication, a token (or a validation ID) is returned to the caller. • informJocat ion(in string L U I , in string address): This 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): This method retrieves a user's P C E . • string download (in Token token, in string filename): This method downloads a file from the user's home network. • boolean upload (in Token token, in string filename, in string data): This 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): This method allows a user to modify their P C E . • void logout (in Token token): This method informs the U H A that a user is logging out. 4.1.3 Termina l Profile Each terminal has a terminal profile which is stored in a file at the terminal . In our prototype, the terminal profile is implemented as a J A V A class that maintains a list 55 of the software application names that are available at the terminal (e.g. Netscape, Mosaic , and Internet M a i l ) . 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 fol-lowing corresponding information is kept in the terminal profile: • The full path executable file name of the software application (e.g. for Netscape, the file name is /usr/applicat ion/netscape.exe ). Th 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 /appl ica t ion/netscape/bookmarks .h tml) . The list of configuration names specifies and l imits the abili ty of a visi t ing user to replace these configurations wi th 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 terminal . In order to aid in the generating and updating of a service profile, we imple-mented a uti l i ty application with G U I , called Service Manager . The Service Manager uti l i ty is available to the system administrator or the owner of the portable terminal . The Service Manager uti l i ty supports the following functions: • A d d a new application name and its executable file name into the terminal profile. 56 Add Delete Quit Help Application Name Exec Path I /cs/pubIic/bin/netscape netscape j calendar calculator j printer Con fig Name File Name , bookmarks j preferences (cookies ! plugin—list j history /grads2/thuynh7.UPC /grads2/thuynh/.UPC /grads2/thuynh/.UPC /grads2/thuynh/.UPC /grads2/thuynh/.UPC Figure 4.1: M a i n screen of the Service Manager ut i l i ty • A d d a new configuration name and its configuration file name to an existing application in the terminal profile. • Delete an existing configuration name and its configuration file name from an existing application in the terminal 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 Manager is i l lustrated in Figure 4.1. 57 4 .1 .4 Termina l Agent (TA) The T A is implemented as an application server for the Initial Agent . Residing locally at a terminal, the T A communicates with 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. Th is process produces a set of network services and applications requested by the user and which are also available at the login terminal . • Download the configuration or preference files that a user specifies for a par-ticular application when this application is locally executed. • Download the class files of the client of the application that is remotely exe-cuted. • A t shutdown, synchronize the downloaded configuration or preference files wi th copies at the home network. The following describes the interfaces supported by T A . These interfaces are defined using O M G ' s I D L . Refer to Appendix A for the entire I D L code. • boolean login (in string L U I , in string password) raises (Fail): This method uses the domain name portion given in the L U I and the C O R B A Name Services to resolve the object reference of the login user's U H A . After ob-taining 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 oper-ation 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 . This method compares the user's P C E wi th the Terminal Profile to produce a list of network services and ap-plications specified by the user in the user's P C E which are also available at the login terminal . Th is method also extracts from the P C E all the network services and applications that are remotely available. "Remotely available" network services or applications are network services that can be executed at the home network or applications that are implemented using the C O R B A Cl ient /Server framework. void logout() raise (Fail): 'This 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 wi th copies at the user's U H A by invoking the up load ( ) method exported by the U H A . A n d finally, th i s method deletes both the configuration and class files downloaded during this login session. string runLoca lApp( in string appName) raise (Fail): Th is method executes a local application. If there is a configuration file specified wi th 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 the U H A to download this configuration file. string runRemoteApp( in string. appName) raises (Fail):. This 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 i t . • str ing getLocalServiceList() raises (Fail): Th is 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 terminal . • string getRemoteServiceListQ raises (Fail): Th is 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 Cl ient /Server framework. 4.1.5 In i t ia l Agent The Initial Agent is an active process executed at a terminal . It is responsible to accept inputs from users and output the responses from the U P C system. The I A is implemented as a T A ' s C O R B A client application. The I A invokes the service provided by the T A corresponding to the user input. The I A is implemented as a Java class that consists of two inner classes called Login Window class and Appl ica t ion Manager class. • The Login 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. The screen shot of the Login screen is shown in the Figure 4.2. • The Appl ica t ion Manager class provides a window where a user can select to execute a software application or request a network service. There are two selectable lists of software applications and network services that a user is granted to access. The first list displays all the network services that are available at the visi t ing network and software applications that are locally 60 Help Uelcone t o UPC User ID t8st@ece.ubc.c3 Password OK I Clear [ J x i t Figure 4.2: Login screen of the U P C available at the login terminal , and the second list displays all the network services and software applications that are available at the home network which can be remotely executed. The screen shot of the Appl ica t ion Manager screen is shown in Figure 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 IA closes the login window and displays the application manager window. The IA 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 getRemoteServiceLis tQ 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 applicat ion. Depending on (ii Local Services Remote Services j netscape {calendar i calculator I printer Exec Cancel\ Logout Figure 4.3: U P C Appl ica t ion Manager screen 62 the user selection, one of the following actions wil l be carried out. • If the user chooses to run a remote application, the IA invokes the runRemoteAppO method from the T A with the appropriate parameters. • If the user chooses to run a loca l application, the IA invokes the r u n L o c a l A p p O from the T A with the appropriate parameters. 4.1.6 T e s t i n g a n d Resu l t s Testing Preparation The prototype supports mobile users wi th transparent access to their personalized computing environments wherever they roam on the Internet, using wireless or wired connections. To demonstrate this capabili ty of the prototype, we have prepared the followings items: • Software Appl ica t ion There are two main categories of network resources and software applications, i.e. local and remote. The " loca l " category includes all the network services that are available at the visi t ing network and all the software applications that are installed in the visited terminal . On the other hand, the networks services that are available outside the visi t ing network (i.e. at the home network) and software applications that can be remotely executed (i.e. applications de-veloped based on C O R B A ' s framework) fall into the "remote" category. For local application, we used the web browser (i.e. Netscape) as an example. The 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 appli-cation, a distributed T icTacToe 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 "bookmarks .h tml" 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 TicTacToe game away from home. • Terminal We configured a foreign terminal in a second administrative domain, "cs.ubc.ca", to support U P C , and created a terminal profile for this terminal using the Service Manager ut i l i ty application. The terminal profile specifies that a web browser called "netscape" is installed at the terminal . The mapping informa-tion for all the reference and configuration files for netscape are also added to the terminal profile. For example "netscape" is installed at " /usr /b in /netscape" and the bookmarks file is mapped into the " /us r /b in /ne t scape /bookmarks .h tml" • file. Results „ When the user "test" moves away from home and visits the "cs.ubc.ca" network, they are able to login and have the same computing environment as they have at home (i.e. ece.ubc.ca). The user can run netscape with the same bookmarks and 64 preferences as they have at home, and any change to the bookmarks or preferences files is synchronized with the corresponding files at the home network: The user can also remotely play a T icTacToe game and resumes a previously paused game. To 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 t ime that it takes to perform a task in different situations. The following shows some figures calculated based on an average of 80 runs: • T ime to resolve the User Agent : 702 msecs • T ime to process a login request : 174 msecs • Download file rate : 27 bytes/msecs 6 5 Chapter 5 Conclusion and Future Works 5 .1 Conc lus ion This thesis addresses implementation issues regarding the support of mobile com-puting over the Internet using a new computing paradigm called Universal Personal Comput ing (UPC)[30,35] . U P C is a computing environment which enables a mo-bile user to access computing resources, network services, personal applications, data files, and environmental configurations through any terminal , stationary or mobile, anywhere on the Internet [21]. The core of U P C ' s mobil i ty management is the Registration and Service Negotiation protocol ( R S N P ) . We first specified the U P C ' s R S N P using Specification and Description Language ( S D L ) . We then simu-lated 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 The specification and simulation of R S N P using S D L has made the imple-mentation 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 important , the simulation has verified the response of a F S M against different combinations of inputs and states. The F S M is proved to correctly work before any coding attempt. Th is results in a huge reduction in debugging time in the implementation phase. Unfortunately, using C language to implement all the distributive compo-nents in U P C is very complex and even impossible. The U P C prototype imple-mented using C language supports only one feature proposed in the U P C frame-work, 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 distr ibuted ob-ject architecture support (i.e. C O R B A ) and a platform independent programming language (i.e. J A V A ) is necessary. The distributed object architecture wi l l make the implementation of a distributed application easier than using only C language. Looking for an object, marshalling data from one language to another, or invoking a method on a remote object are performed transparently by the distributed object framework. In addit ion, the platform independence of Java wil l 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 wi th C O R B A . as the object bus that facilitates the interaction, integration, and distr ibution of these objects. To demonstrate the concept, a prototype of C O R B A - b a s e d U P C was implemented using Java 1.1.x and Visigenic 's C O R B A for Java 3.0 on a Solaris platform. W i t h the advantage of using Java and C O R B A , we were able to implement most of the features proposed in the U P C framework. The implementation is very simpler as compared to the C / T c l / T k implementation: The prototype implemen-tation supports a mobile user to transparently access their configuration and pref-erence file, and execute their personal software application whenever and wherever < they roam on the Internet. The application could be a local application running with the user's configuration and preference file, or an application that 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 t ime 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 Terminal Agen t could ; be enhanced to support service discovery at the visit ing network. 68 A s the C O R B A ' s Concurrency Cont ro l is available, the User Agent could use this service to control access to the P C E , and the Terminal Agent could use this service to synchronize file downloading and uploading. Por t ing this project into a Web-based framework would be a possible exten-sion. 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 . Bagrodia , W . W . C h u , L . Kleinrock, and G . Popek, " V i s i o n , Issues, and Architecture for Nomadic Comput ing" , IEEE Personal Communications Magazine, pages 14-27, December 1995. [2] F . Bel ina, D . Hogrefe, and A . Sarma, " S D L wi th Appl ica t ion from Protocol Specification", Prentice Hall International (UK) Ltd., 1991. [3] J . C . Benard-Dende, R . Nevoux, and J . C . Dang , "Networks, Users and 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 Basics" , Handouts. [5] D . Chess, B . Grosof, C . Harrison, D . Levine, C . Parr is , and G . Tsudik , " Itinerant Agents for Mobi le Comput ing" , 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 . Do , and J . Audestad, "Terminal M o b i l i t y Support in T I N A " , Pro-ceedings of TINA's 97, pages 38-50, 1998. 70 [8] T . Eckardt , and T . Magedanz, "The Role of Personal Communicat ions in Distr ibuted Office Environments" , Autonomous Decentralized Systems Proceedings, pages 316-322, 1995. [9] T . Eckardt , and T . Magedanz, "Personal Communicat ions Support based on T M N and T I N A Concepts" proceedings of IN's 96, pages 196-200, 1996. [10] M . P. Gervais, " A Framework for Mob i l i t y in Wireless Personal Communi -cations", Proceedings of ICC/SUPERCOMM's 96, pages 1148-1152, vol . 2, 1996. [11] V . Gup ta , and A . D i x i t , "The Design and Deployment of a Mob i l i t y Support Network",Proceedings Second International Symposium on Parallel Archi-tectures, Algorithms, and Networks, pages 228-234, 1996. [12] J . G . Hemmady, J . R . M a y m i r , and D . J . Meyers, "Network Evolut ion to Support Personal Communicat ions Services", Global Telecommunications Conference, pages 710-714, vol . 21994. [13] T . D . Hodes, and R . H . K a t z , "Composable A d hoc Location-based Services for Heterogeneous Mobi le Cl ients" , , 1997. [14] C . ' S . Hong, Y . Koga , and Y . Matsushi ta , " A Networking Architecture for M o b i l i t y Services Using Mobi le Agent Approach" , Proceedings of TINA's 97, pages 297-307, 1998. [15] I. Iida, T . Nishigaya, and K . Murakami , " D U E T : A n Agent-Based Personal Communicat ions Network", IEEE Communications Magazine, pages 44-49, November 1995. 71 [16] T . Imielinski, and H . F . K o r t h , " M o b i l e Compu t ing" , Kluwer Academic . Publishers , 1996 . • [17] J . Ioannidis, and G . Q . Maguire Jr . , " T h e Design and Implementation of a Mobi le Internetworking Archi tecture", Winter USENIX, 1993. -[18] E . Jung, Y . J . Park, and C . Park , " M o b i l e Agent Network for Support-ing 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. Furnel l , N . M a u m o n , E . Veld-kamp, B . W i n d , and S. Tr igi la , " U s i n g C O R B A to Support Terminal M o -bi l i ty" , Proceedings of TINA's 97, pages 59-67, 1998. [20] Y . L i , and V . C M . Leung, "Suppor t ing Personal Mob i l i t y for Nomadic C o m -puting over the Internet", ACM Mobile Computing and Communications Review , V o l . 1, No . 1, pages 22-31, A p r i l 1997. [21] Y . L i , and V . C . M . Leung, "P ro toco l Architecture for Universal Personal Compu t ing" , IEEE Journal on Selected Areas in Communications , V o l . 15, No.8, pages 1467-1476, October 1997. [22] A . Lombardo, P. Nicosia, S. Palazzo, and M . Samarotto, "Service A r c h i -tecture Support of Personal Mob i l i t y in a M u l t i - D o m a i n Environment" , Proceedings of TINA's 97, pages 51-58, 1998. [23] R . Orfal i , and D . Harkey, "Cl ien t /Server Programming with J A V A and C O R B A " ; John Wiley and Sons, Inc., 1997. 72 [24] J . Pavon, and J . Tomas, " C O R B A for Network and Service Management in the T I N A Framework", IEEE Communications Magazine, pages 72-79, M a r c h 1998. [25] C . Perkins, E d . , R F C 2 0 0 2 , IP 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 Network-Based Mig ra t i ng User Agents for Personal Communicat ion 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 Provid ing Identity Pr ivacy to Mobi le Users during Authent ica t ion" , pages 196-199, Workshop on Mobile Com-puting Systems and Applications, pages 196-199, 1995. [28] A . Sarma, "Introduction to S D L - 9 2 " , Handouts. [29] H . M . Sneed, " Encapsulat ing Legacy Software for Use in Cl ient /Server Systems", Proceedings of WCRE'96, pages 104-119, 1996. [30] M . Toeroe, J . Zhu, Y . L i , and V . C . M Leung, " A C O R B A based Framework for Univeral Personal Comput ing on the Internet",Proceedings SCI/ISAS'''98, Orlando, FL, Ju ly 1998. [31] Vinosk i S., " C O R B A : Integrating Diverse Applicat ions wi th in Dis t r ibuted Heterogeneous Environments, IEEE Communications Magazine, pages 46-55, vol . 35, 1997. [32] S. V inosk i , "Dis t r ibuted Object Comput ing 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 Programmer 's Guide, Version 3.0, Vis iBroker for Java. 73 [34] M . Zaid , "Personal M o b i l i t y . in P C S " , IEEE Personal Communications Magazine , pages 12-16, Four th Quarter 1994. [35] J . Zhu, M . Toeroe, V . C . M . - L e u n g , and S. Vuong, "Suppor t ing Universal Personal Comput ing on Internet with Java and C O R B A " , Concurrency: Practice and Experience, 1998. 74 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. / /Author : Thong Huynh module TA { in te r face TerminalAgentf enum Fai lReason { UNABLE_TO_LOCATE_SERVER, NO_IMPLEMENT_SERVER, C L A S S _ N 0 T _ F 0 U N D , INSTANTIATION_ERROR, ACCESS.ERROR, CLASSFILE_DOWNLOAD_ERROR, ERROR_EXEC_APPLICATION, UNKNOWN.HOST}; exception F a i l { Fai lReason reason; }; vo id updateLocat ion( in s t r i n g newLocation) r a i se s ( F a i l ) ; boolean l o g i n ( i n s t r i n g LUI , i n s t r i n g password) r a i se s ( F a i l ) ; vo id logou tQ r a i s e s ( F a i l ) ; s t r i n g runLocalApp(in s t r i n g appName) r a i s e s ( F a i l ) ; s t r i n g runRemoteApp(in s t r i n g appName) r a i s e s ( F a i l ) ; s t r i n g g e t L o c a l S e r v i c e L i s t Q ra i ses ( F a i l ) ; 75 s t r i n g g e t R e m o t e S e r v i c e L i s t O r a i s e s ( F a i l ) ; } ; >; / / A u t h o r : Kangming L i u module PCE { typede f s t r i n g ServiceName; typedef s t r i n g S e r v i c e O b j ; typedef s t r i n g ServiceTypeName; typede f s t r i n g C o n s t r a i n t ; t ypede f s t r i n g P r e f e r e n c e ; t ypede f s t r i n g Po l i cyName; typede f s t r i n g PropertyName; typedef s t r i n g P o l i c y V a l u e ; typedef s t r i n g P r o p e r t y V a l u e ; typedef s t r i n g H p r o p e r t y V a l u e ; enum PropertyMode { PR0P_N0RMAL, PR0P_READ0NLY, PROP.MANDOTORY, PR0P_MAND0T0RY_READ0NLY . } ; 76 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 value; PropertyMode mode; >; typedef sequence <Property> PropertySeq; s t r u c t P o l i c y { PolicyName name; . PolicyValue value; } ; •typedef sequence<Policy>PolicySeq; s t r u c t Trade{ ServiceTypeName type; Constraint constr; Preference pref; 77 Pol i cySeq p o l i c i e s ; PropertySeq P rope r t i e s ; >; s t ruc t Serv ice{ ObjectRefType type; ServiceName serviceName; ServiceObj serv iceObj ; Trade t rade; HardwareCapSeq hardwareCapSeq; >; typedef sequence<Service>ServiceSeq; in te r face P r o f i l e { a t t r i b u t e ServiceSeq serv iceSeq; v o i d s e t ( i n PCE::ServiceSeq serv iceSeq) ; PCE::ServiceSeq g e t ( i n s t r i n g username); } ; in te r face P r o f i l e F a c t o r y { 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 serv iceSeq) ; v o i d d e l e t e P r o f i l e ( i n P r o f i l e p ) ; >; >; module UA { s t ruc t Token{ 78 \ s t r i n g low; s t r i n g h igh ; } ; i n t e r face UserAgent { boolean au then t i ca te ( in s t r i n g LUI , i n s t r i n g password); boolean tokenauthent( in s t r i n g LUI , i n s t r i n g password, out Token token); v o i d i n fo rm_loca t ion ( in s t r i n g 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 lename) ; boolean upload( in Token token, i n s t r i n g f i lename, 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, i n P C E : : P r o f i l e 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:
https://iiif.library.ubc.ca/presentation/dsp.831.1-0051309/manifest

Comment

Related Items