A bstract
T here is much research in the literature regarding the construction of distributed v irtual reality im plem entations. A fter evaluating some well-known v irtu a l reality systems, it was determ ined th a t several problem s exist th a t need to be solved. In particnlar: network efEciency, object distribution and coherency, inadequate system resource m anagem ent, and overall performance.
In order to properly address these issues, a holistic design approach is taken. The entire system is examined, rather th an focusing on a specific problem area (such as th e hum .an-com puter interface).
T he m ajor component of this work, the Newtonian A rchitecture for V irtual Land scapes (NAVL), is presented to respond to the problems areas discovered. Highlights of the architecture include:
• A distributed client/server network th a t addressed the networking issues.
• A utonom ous objects encapsulate control and object sta te into a single entity. Using autonom ous objects avoids lengthy synchronization processes (e.g., full database locking).
• ForceLets, a novel synchronization m ethod, minimize the network bandw idth required to keep an object synchronized a t remote locations. In addition, ForceLets provide mnch improved synchronization of the object a t the remote locations in the presence of network lag.
Im plem entation details of the NAVL prototype are also presented. The imple m entation consists of an object sim ulation and execution unit, rendering and collision detection unit, and network snbsystem and protocols.
An evaluation of th e NAVL system architecture examines the efficiency of th e key architectural components:
• A bandw idth and latency analysis examines the efficiency of the d istrib u ted client/server network.
• The object distribution and coherency com ponents are tested directly from the prototype. Profiles of actual prototype execution are used to show th e efficiency gains of the ForceLet approach as compared to the commonly used stream -of- d a ta coherency mechanism.
• The rendering and collision detection unit is tested by examining the effects on CPU utilization and frame rate with increases in th e num ber of virtual objects.
Examiners:
Dr. K. F. Li, Supervisor(D ept. of Electrical and Com puter Engineering)
_____________________
Dr. F. ffl-G uibaly, Supervisor(Dept. of Electrical and Com puter Engineering)_________________________
Dr. V. Bhargava, D epartm ental M ember(Dept. of Electrical and Com puter Engg.)Dr. ^ > JJ o n g /b u ts id e M ember(Dept. of Mechanical Engineering)
___________________________
Dr. S. Shimojo, E xternal Exam iner(Com putation Center, Osaka University)A bstract il
Table o f C ontents iv
List o f Tables v il
List o f Figures v iii
List o f A cronym s x
Acknowledgem ents x ii
D edication x iii
1 D issertation O bjectives and Organization 1
1.1 D issertation O r g a n i z a t i o n ... 3
2 Introduction 4 2.1 Defining V irtual R e a l i t y ... 5
2.2 DVR Term inology... 6
2.3 DVR Layer R e p resen tatio n ... 7
2.4 Case Studies of D VR I m p le m e n ta tio n s ... 10
2.4.1 VRML(2, 5 ) ... U 2.4.2 D IV E (2 ,3) ... 12
2.4.3 .A.lpha W o r l d ( l ) ... 13
2.4.4 MR Toolkit w ith Peer Package(2, 3) ... 15
2.4.5 D I S ( 5 ) ... 15
2.4.6 RTIME Interactive Networking Engine(2, 3 ) ... 17
2.4.7 Physical Simulation S y s t e m s ( l ) ... 17
2.5 Problems w ith Existing Im p le m e n ta tio n s... 19
T A B L E O F C O N T E N T S v
2.5.2 O bject D istribution and Coherency M o d e ls... 21
2.5.3 Inadequate System Resource M a n a g e m e n t... 23
2.5.4 Overall P e r fo r m a n c e ... 23
2.6 General C riteria for Effective DVR S y s t e m s ... 25
2.6.1 B etter G raphics ( D L ) ... 25 2.6.2 Fast N e tw o rk in g (E L )... 26 2.6.3 Synchronized V irtu al B v e n ts ( E L )... 26 2.6.4 Ease of U s e ... 26 2.6.5 Autonomous V irtual O b je c ts ... 27 2.6.6 Heterogeneous G om puting P l a t f o r m s ... 27 2.7 C hapter S u m m a r y ... 28 3 NA VL System Architecture 29 3.1 Objectives of System A rc h ite c tu re ... 29
3.2 T h e NAVL A rchitecture a t a Glance ... 31
3.3 Network A rc h ite c tu re ... 32
3.4 O bject D istribution and C o h e re n c y ... 34
3.4.1 Autonomous M aster/Slave R e p lic a tio n ... 37
3.4.2 ForceLet S i m u l a t io n ... 39
3.4.3 Route M a p p in g ... 44
3.5 Rendering and Collision D e te c tio n ... 45
3.5.1 R e n d e rin g ... 46
3.5.2 Collision D e te c tio n ... 48
3.5.3 System P e r s p e c tiv e ... 50
3.6 Chapter Sum m ary ... 51
4 NA VL P rototyp e 53 4.1 O verview ... 54
4.1.1 Service D i s p a t c h e r ... 57
4.2 The O bject Simulation and Execution U n i t ... 57
4.2.1 O bject Simulation ... 59
4.2.2 O bject Behavior E x ecu tio n ... 60
4.2.3 A pplication and O bject Program m ing In te rfa c e s ... 61
4.3 Rendering and Collision D e te c tio n ... 67
4.3.1 OpenG L-Based R e n d e rin g ... 67
4.3.2 N ested-Loop Collision Detection... ... 70
4.4 Network Subsystem and P ro to c o ls... 72
4.4.1 UDP T ransport M e c h a n is m ... 72
4.4.2 Protocol D ata U n i t ... 73
4.5 Route M a p p in g ... 77
4.6 P roject P l a n n i n g ... 79
4.6.1 NAVL Coding P h a se s... 80
4.7 C hapter S u m m a r y ... 82
5 Evaluation o f NAVL System A rchitecture 84 5.1 Network A rc h ite c tu re ... 85
5.1.1 Bandw idth Analysis ... 85
5.1.2 Latency A n a ly s is ... 89
5.1.3 Discussion of R e s u l t s ... 96
5.2 O bject D istribution and C o h e re n c y ... 99
5.3 Rendering and Collision D e te c tio n ... 104
5.4 Chapter Sum m ary ... 105
6 Conclusions and Future Work 107 6.1 C o n c lu s io n s ... 107
6.1.1 C o n trib u tio n s ... 108
6.1.2 NAVL is an Effective DVR S y s t e m ... 109
6.2 Future W o rk ... 113
B ibliography 115 A R ou te M apper C Language Im plem enation 120 B NAVL Header Files 144 B .l N A V L .h ... 144 B.2 a p i . h ... 149 B.3 o p i . h ... 151 B.4 n e t . h ... 153 B.5 c l i e n t A P I .h ... 156 B.6 c o r e A P I .h ... 157
List o f Tables
3.1 Com parison of coherency algorithm s ... 43
4.1 A PI C a l l s ... 64
4.2 D P I C a l l s ... 66
4.3 Client helper A PI c a l l s ... 69
4.4 Core NAVL s h a p e s ... 70
4.5 A P I/O P I to PD U mapping ... 76
4.6 Sine ForceLets param eters used as p a rt of the route mapping example 80 4.7 Overall prototype im plem entation statistics ... 81
4.8 Prototype im plem entation task s t a t i s t i c s ... 82
5.1 Bandw idth analysis s y m b o ls ... 86
5.2 Sum m ary of network bandw idth e x p r e s s io n s ... 89
5.3 Sum m ary o f network latency e x p re s s io n s ... 96
5.4 E rrors for m aster/slave execution p r o f i l e ... 103
2.1 Three elements of V R ... 6
2.2 DVR layer s t r u c t u r e ... 8
2.3 Simplified Hirzinger model for te le ro b o t... 19
3.1 D istributed client/server network a r c h i t e c t u r e ... 33
3.2 NAVL architecture e le m e n ts ... 35
3.3 NAVL im plem entation o f virtual o b j e c t ... 36
3.4 Profile for coherency a lg o r ith m s ... 43
3.5 2-D route m a p p i n g ... 45
3.6 Foley’s graphics p i p e l i n e ... 47
3.7 M irtich’s collision detection p ip e lin e ... 49
3.8 Hybrid rendering/collision detection p ip e lin e ... 50
4.1 NAVL service layers ... 55
4.2 Block diagram of the NAVL p r o t o t y p e ... 56
4.3 D ispatch c y c le ... 58
4.4 The sim ulation and execution u n i t ... 59
4.5 M annequin’s object h i e r a r c h y ... 60
4.6 A PI protocol ... 62
4.7 API code ex a m p le... 65
4.8 O PI sample c o d e ... 68
4.9 N ested-Loop collision detection c o d e ... 71
4.10 Example of route m a p p in g ... 79
5.1 Bandw idth plots ... 90
5.2 Queue tim ing d i a g r a m ... 91
5.3 Latency analysis p a r a m e te r s ... 92
5.4 Physical model for latency a n a l y s i s ... 94
5.5 Delay plots ... 97
5.6 M aster/slave execution profile - no d e l a y ... 100
L IS T O F F IG U R ES ix
5.8 M aster/slave execution profile - 200ms d e la y ... 101
5.9 M aster/slave execution profile - 500ms d e la y ... 102
5.10 M aster/slave execution profile - 1000ms d e l a y ... 102
A P I A pplication Program m ing Interface A T M Asynchronous Transfer Mode
B S D Berkeley Software D istribution B W Bandw idth
C / S Client/Server
C A D Com puter Aided Design C C W Counter Clock Wise D C / S D istributed Client/Server D E M U X De-multiplexor
D IS D istributed Interactive System
D I V E D istributed Interactive V irtual Environment D L Display Lag
D V R D istributed V irtual Reality E L Environm ent Lag F T P File Transfer Protocol G U I Graphical User Interface H D L C High-level D ata Link Control
H M D Head Mounted Display I P Internet Protocol I P v 6 Internet Protocol Version 6
I R C Internet Relay C hat
IS O International Standards Organization L A N Local Area Network
U S T OF A C R O N Y M S
L o C Lines of Code L o D Level o f Detail
M / D / 1 Memoryless, Determ inistic, Single-Server Queue M A C Medium Access Control
M U T E X M utual Exclusion M U X Multiplexor
N A V L Newtonian A rchitecture for V irtual Landscapes N F S Network File System
N I C Network Interface Card
N P C Normalized Projection Coordinates O P I O bject Program m ing Interface P - P Peer-to-Peer
P D U Protocol D ata Unit Q oS Q uality of Service R S V P Reservation Protocol
S E U Sim ulation and Execution Unit
S M P Symmetric Multiprocessing (also Shared Memory Multiprocessing) T C P T ransport Control Protocol
U D P User D atagram Protocol
V R M L V irtual Reality Modeling Language W A N W ide Area Network
I wish to acknowledge the support and encouragement I’ve received by my teachers an d professors thoughout my journey of learning and self-exploration.
I dedicate this work to my family and friends, who have encouraged me to pursue my am bitions.
D isserta tio n O bjectives and
O rganization
W hile com puter graphics dom inate our perception of distributed virtual reality(DVR), th e fact is th a t com puter graphics is only one of several research areas. Com puter graphics are an essential first step to providing virtual reality (VR), bu t th a t alone will no t be enough to provide effective user environments.
To improve the immersion, there may be a need to add audio or tactile feedback (e.g., force feedback) to the application. DVR systems require networking fabrics to com m unicate between participants.
Each aspect adds more capabilities to the V R application, but also increases overall complexity and requires more resources to be managed. Most research imple m entations of V R and DVR systems focus on a small subset o f the whole system, preferring to off-load the responsibility of m anaging these ex tra resources to operating system s(OS) or other program m ing system environments.
C H A P T E R 1. D ISSE R T A T IO N O B JE C T IV E S A N D O R G A N IZ A T IO N 2
the range o f system activities, rath er than focusing on any one p art. In this way, the DVR system developer has the ability to efficiently accom m odate many different resource needs within the system.
Once th e resources and their needs are identified, strategies can be developed to deal w ith them . For DVR systems, this typically involves m anaging C P U scheduling, rendering speed, networking, and I/O .
T his research has five overall objectives:
1. Exam ine current DVR im plem entations looking at their effectiveness as holistic solutions — where they work well, and where they do not. From this analysis, a list o f specific problem areas is found. This list helps point ou t where th e work should concentrate.
2. As p a rt of the analysis, a benchm ark (or check list) is created th a t can be used to evaluate specific im plem entations. This task differs from th e task above in th a t this check list evaluates a particular implementation, while the previous task looked a t a range of im plem entations. This check list specifies the most im portant item s in a DVR system.
3. T he Newtonian A rchitecture for V irtual Landscapes(NAVL) system architec tu re is developed from considering the list of problems with current implemen tations. This architecture is intended to address most (if not all) o f the current im plem entational deficiencies observed w ith existing systems.
4. A prototype of the NAVL system architecture is developed to serve as a proof of concept and an experim ental test-b ed for further ideas and concepts.
5. An evaluation of the NAVL system architecture is performed using a combina tion of theoretical analysis, sim ulation, and direct evaluation of the prototype.
1.1
D isserta tio n O rganization
This dissertation is arranged in the following manner:Ch. 2 T his chapter introduces DVR systems, provides case studies of some well-known D V R systems, and presents both the problems with current DVR system s and checklist for effective DVR systems.
Ch. 3 T his chapter presents the NAVL system architecture. The architecture’s m ajor com ponents are the network architecture, object distribution and coherency model (with autonom ous objects and ForceLet coherency), and the render ing/collision detection unit.
Ch. 4 T his chapter details the NAVL prototype. M ajor components of th e prototype are th e sim ulation and execution unit(SE U ), the rendering/collision detection unit, and the network subsystem /protocol system. In addition, a route m ap per is proposed th a t maps a path defined by reference points into a group of ForceLets. Finally, some statistics on th e prototype im plem entation design ef fort is presented.
Ch. 5 T his chapter evaluates the NAVL system architecture using theoretical analysis, sim ulation, and direct evaluation of the prototype where appropri.ate. T h e areas of evaluation include the bandw idth and latency analysis of the network archi tecture, evaluation of the ForceLet coherency algorithm using sim ulation and prototype tracing d ata, and an evaluation of the rendering/collision detection unit.
Ch. 6 T his chapter concludes the dissertation and presents future directions for th is work.
C hapter 2
In trodu ction
This chapter provides background inform ation regarding DVR systems. A DVR layer representation is presented to help communicate the degree of focus for specific im plementations provided as case studies.
The case studies of DVR im plem entations includes; VRML. DIVE, A lpha World, MR Toolkit (peers), DIS, RTIME and a few physical simulation systems. A list of DVR problems is distilled ou t of the process of exam ining the DVR im plem entations for their shortcomings. T his list of problems gives a sense of direction for our atte m p ts to improve DVR systems.
Some thought was also placed into describing the features th a t make for an ef fective DVR im plem entation. This becomes the general criteria for effective DVR systems.
2.1
D efining V irtu al R eality
T h e literature shows many atte m p ts to define VR. Some take a focused point o f view an d define VR directly. For example, Wang[49, p. 1] suggests th a t V R is a “highly interactive three dimensional user interface.” W hile this definition works well for focusing attention on th e specific area of interest (the user interface in this example), it fails to acknowledge th e larger issues such as “W here does V R stop and Reality s ta rt? ”
B urdea and Coiffet[4, pp. 2-5] examined the issue and propose th a t V R is th e m erger of three components; Immersion, Interaction and Imagination. T he term im agination, here, is m eant to describe the hum an element folded into the V R system during its development. T he imagination of the scientists, engineers and artists are integrated into the final product. While immersion and interaction fit our sense of VR, the im agination com ponent seems ou t of place. There are many examples of p roducts th a t embody hum an creativity th a t are not VR.
C a rr and England[6, pp. 1-9] take a more philosophical approach and suggest th a t V R is the act of synthesizing human perception. They suggest th a t purists a t one extrem e accept only technology driven definitions (e.g., com puter graphics, head m ounted displays). P urists at the other extrem e insist th a t dream s and immersive entertainm ent (e.g., books and movies) should be included in the definition. W hile it is appreciated th a t the definition for V R has expanded beyond simple technology driven elements, it is noted th a t this definition is too broad to be used in a practical way.
In this work, an approach derived from Burdea and Coiffet is suggested - V R is decomposed into three elements, viewed as a pyram id (see Fig. 2.1). Unlike B urdea and Coiffet, the im agination element is replaced w ith com puter technology. V irtual
C H A P T E R 2. IN T R O D U C T IO N
VR Application
im m ersion Interaction'
C om puter Technoiogy
Figure 2.1: T hree elements of VR
R eality is then defined as:
The experience the user has when he or she becomes im m ersed while in teracting with computer technology.
In this way, we view immersion and interaction as essential elem ents of VR, with com puter technology as an enabler th a t supports VR applications. W ithout com puter technology, we can not construct the system th a t provides interaction and immersion to the user.
2.2
D V R Term inology
T he following term s are used throughout this dissertation:
A v a t a r A graphical representation of the user. It is often represented as an articu lated mannequin^
^The word is derived from Sanskrit to describe th e coming into being o f a devine entity in the shape o f man or beast.
V i r t u a l O b je c t An object as represented in the V R world. T he term is chosen to avoid conflict with object oriented programming.
O b je c t B e h a v io r For the NAVL system, special routines are embedded w ithin the v irtual objects. These routines are invoked upon receiving an event.
E v e n t For NAVL, events are messages sent to a virtual object to indicate a special occurrence, such as a collision. The receipt of the event will trigger a corre sponding event callback (behavior routine).
O b je c t S t a t e For NAVL, virtual objects contain their own sta te inform ation such as the object’s shape, color, position and orientation.
2.3
D V R Layer R epresentation
V irtual Reality systems run the full spectrum ; from simple single-node V R (SVR) im plem entations such as VRML 1.0[47], to complex multi-node DVR applications such as the D istributed Interactive Simulations(DIS) standard[14].
Borrowing from operating system design, DVR systems can be described using a layered stack as shown in Fig. 2.2. The DVR layers are: application layer, language and A PI layer, programming system (PS) layer, operating system (OS) layer, and the network protocol layer.
Each layer of the stack services the layer above. However, there need not be a single im plem entation of a service layer; in fact, we can expect to see significant com petition between software developers regarding the im plem entation of the service layers.
Inform ation and service dependency flow in this representation is shown by a large arrow. The arrow indicates th a t the application layer is serviced by the Language/.API
C H A P T E R 2. IN T R O D U C T IO N
(1) A pplication (2) Language an d API
(3) Program m ing System
g
(4a) O b ject Synchronisation(4b) O perating System (5) N etw o rk Protocol
Figure 2.2: DVR layer structure
layer, and so forth. Note th a t when generalizing many DVR systems, some ra ria tio n is to be expected. For example, it is not unexpected to find a system whereby th e application has direct connections to the language/A P I layer and to the OS layer. It is unusual, however, to see the implicit ordering violated (e.g., a DVR PS layer th a t services requests for the OS layer).
L a y e r 1: A pplication
T h e application layer represents the set of DVR applications. There are many variations of applications possible, th e following is a short list of some appli cation areas being implemented for V R and DVR systems (see[4. Ch. 8] for a comprehensive survey, and more recently[18]).
E n te r t a i n m e n t is likely the largest growing m arket segment of VR applica tions. Given our earlier definition of VR, many home com puter games are sm all scale V R systems, such as car-racing or airplane simulators.
P h y s ic a l S im u la to rs are much more complex versions of the entertainm ent class sim ulators. In addition to real-tim e com puter graphics, physical
simula-tors provide feedback to the user in term s of force (e.g., through mechanical actuators), typically in response to a dynamics model. Futherm ore, tighter tolerances to the real world are used for the dynam ics models. For example, airline physical sim uators are sophisticated enough th a t pilots can upgrade their license via sim ulator training alone[26].
S c ie n tific S im u la tio n a n d V is u a liz a tio n use immersive display techniques to allow the scientist a b etter view of the phenomena m easured. For example, VR techniques are used in the visualization of electro-m agnetic fields for micro devices[29).
P r o d u c t iv i t y E n h a n c e m e n t T o o ls allow people to work together b etter. Video conferencing, for example, allows meetings to be held w ithout flying people in from around the country. People can participate w ithout leaving their office. DVR allows the participants to be immersed in the same cyber environment while perform ing complex tasks[20].
L a y e r 2: Language and API
Applications employ DVR system services with either a set of languages (pos sibly extensions of existing languages) or application program m ing interface (API) calls. The advantage of a language/.API layer is the abstraction and encapsulation of services.
Exam ple of languages include the Java-3D[31j, and Inven/TCL[16] language extensions, and th e purpose-built VRML language[47]. For DVR systems, com mon A PIs include OpenGL for graphics[37] and WinSock[44] for networking.
L a y e r 3: Program m ing System
T he DVR program m ing system layer handles requests m ade through the lan guage extensions and A PI layer, providing infrastructure for m anaging
dis-C H A P T E R 2. IN T R O D U dis-C T IO N 10
trib u ted V R environments. An exam ple is the Java V irtual Machine[28].
L a y e r 4 : O bject Synchronisation and O perating System
T h e object syncrhonisation and o perating system services layer m aintains low- level machine services such as synchronising virtual objects, C PU scheduling, m em ory allocation, local I/O , and networking. Most DVR im plem entations are built on top of an existing operating system like UNIX, Linux, or Windows-NT.
L a y e r 5 : Network Protocol
T h e protocol layer describes the com position of the networking connections; th e bits on the wire. For example: T C P/IP[45], Network File S ystem [Il], Network Inform ation Service[ll], Dom ain Name Service[Il] and Simple Network M anagem ent Protocol[45].
2.4
C ase Studies o f D V R Im plem entations
T he following is a sum m ary of some of the more prominent DVR system s found in the litera tu re and how they fit into the DVR layer structure; the DVR layer num bers involved are listed parenthetically. It appears th a t many DVR systems are focused on a sm all subset of the DVR layers.
In particular, it is evident th a t existing im plem entations leverage the OS services from th eir native OS (e.g., Windows-NT or UNIX). From this list of case studies, the reader will notice th a t none of them im plem ent services in the OS layer (layer 4).
2.4 .1
V R M L (2 , 5)
T h e VRML specification was created to provide a standard framework for the de velopment of V R languages over the Internet (Version 2.0 - ISO /IE C 14772)[47], T he initial version, 1.0, specifies a textual language for describing sta tic v irtual en vironments. W ith VRML 1.0, authors can describe reasonably complex scenes using w i o u s shape primitives (e.g., cone, box, sphere, plane) and lighting primitives (e.g., directional, ambient, point light).
T he second version of VRML, 2.0, was adopted from the SG I Moving V7orlds[42] proposal. Version 2.0 specifies mechanisms to add behavior routines to the graphic objects. G raphic objects in VRML 2.0 can issue input and o u tp u t events th a t may be used by other objects (or scripts) in th e scene. T he scripting facility allows for a program m ed behavior to generate and receive events. For example, a user activating a touch sensor generates an event th a t sta rts up a script. The script may, in turn, generate other events as a result of its execution.
There are significant shortcomings of the standard; for example, the VRML speci fication does not allow for m ultiple users in the same environment. In addition, there needs to be a tighter reign on the specifications to support m ultiple users appropri ately. In particular, the VRML 2.0 specification explicitly m entions th a t the passage o f tim e is determ ined by the browser, which may decide to speed up or slow down the virtual ivorld a t its discretion. To support m ultiple users in the sam e virtual en vironm ent, the passage of tim e m ust be closely synchronized between distan t hosts. In response to this problem, the Living Worlds[48] group has proposed a collection of changes to the VRML specification to allow m ultiple users via explicit points of synchronization.
C H A P T E R 2. IN T R O D U C T IO N 12
server m ust be large enough to handle the expected load, which can be considerable. For the m oment, the load activity is limited to downloading VRML docum ents, b u t the Living Worlds extensions would require th a t the VRML server also synchronizes v irtual objects, thereby greatly increasing network traffic and CPU loads in the server.
2.4.2
D IV E (2 , 3)
T he DIVE DVR system, developed to experim ent w ith distributed virtual worlds, is fully distributed (i.e., every node connects to every other node in the network) using reliable IP m ulticast to transm it messages to all nodes[5]. V irtual objects are replicated on each node such th a t every node in the system has equal access to every v irtu a l object. Because there is no centralized server node, a change made to any replica of a virtual object will affect all other replicas. This is accomplished w ith th e em ulated shared memory. The local node updates sta te inform ation for a virtual object, and the DIVE networking subsystem replicates the change using the m ulticast IP. M utual exclusion (MUTEX) operators serialize simultaneous u pdates to the shared virtual objects.
Controlling the sta te of the virtual objects is a collection o f event driven behavior routines w ritten in a hybrid D IV E /T cl language. These routines are started when an event is received such as a user interaction signal, tim er or collision.
T he user’s representation in the virtual world, called an A vatar, is integrated into DIVE a t a fundam ental level. Many VR systems implement avatars as a regular virtual object th a t is tied to the user’s position; when the user changes position the avatar virtual object responds in kind. In DIVE, however, the avatar object is a fundam ental p art of the user’s state; for example, the rendering process shows the view from the avatar’s left eye; or both eyes if using a head m ounted display (HMD).
T he position of the avatar dictates w hat the user sees.
Since D IV E’s development in the early ’90s, it has been shown th a t more sophisti cation is required to deal w ith interactive distributed virtual environments. P articular criticism is placed on the decision to use an em ulated shared memory com m unication model w ith MUTEX protection. T his model greatly increases the latency to up date v irtu a l objects. The choice of peer-to-peer networking w ith m ulticast IP causes concern for those who do not have system adm inistrator privileges to enable the mul ticast IP mechanism. DIVE can be set up to em ulate m ulticast IP via a series o f UD P transm issions, however the networking load grows to order packets per tim e cycle. It quickly becomes apparent th a t an efficient network architecture is needed.
2.4 .3
A lp h a W o r ld (l)
_41pha World, a b e ta release of Worlds C hat and now the property o f Circle of Fire Studios, Inc., is a m ultiple-user V R system for socializing - very much like a V R form of IRC (Internet Relay Chat)[9]. A special browser, used to enter the A lpha World system , supports the rendering of th e three dimensional graphics and the com m unication protocols to interface w ith the A lpha World server.
Users wander around the A lpha World city looking for interesting places to meet and talk. T he b eta version lim ited talking to keyboard entry, however the production version allows for voice transmissions. An interesting feature is the ability of users to build v irtual structures in the A lpha World city. The city is always changing and evolving, providing an interesting backdrop for conversations.
T he networking architecture is based on the client/server paradigm where th e com m unication protocols follow two independent networking mechanisms:
C H A P T E R 2. IN T R O D U C T IO N 14
sim ilar to VRML in th a t they are ASCII based.
2. Interaction between users and the virtual environment is handled with a pro p rietary communication protocol.
These mechanisms naturally segment the communication flow into a low prior ity bulk download packets, and high priority synchronization packets. As th e user moves through the virtual environment, v irtual objects are continuously coming into view. The delay while the virtual object description file is being downloaded is quite ap p aren t to the user. However, when the user interacts with the av atar of another user, the interaction response is very quick. T his division of networking bandw idths is very well suited to v irtual society applications, where the focus is typically on the ch at aspects rath er th an th e virtual environment.
The A lpha World system works very well for the virtual society application. The em phasis on interaction w ith people rath er th an virtual environment keeps people involved w ith their conversations a t the expense of environment lag.
As a general purpose DVR system, however, the .Alpha World system has some significant shortcomings. In particular, A lpha World uses a client/server networking architecture. As will be seen in Ch. 5, the client/server networking architecture does not distribute the network load; all network traffic funnels through the server machine. T his implies th a t the A lpha World server m ust have a very wide Internet bandw idth connection, and it m ust have enough CPU power to support all the clients. .As the A lpha World city grows, the available bandw idth and CPU will not be enough to com pensate.
2 .4 .4
M R T oolkit w ith P eer P ackage(2, 3)
T he M R Toolkit is a collection of libraries to build simple V R applications, initially developed to experim ent w ith HMDs and V R input devices[49, 38, 39, 40]. The system is m odular, so additional subsystem s may be deployed a t will. T he base MR Toolkit is a collection o f libraries and device drivers to support research into real-tim e interaction for a single user virtual environments. The Peer Package[38] provides su p p o rt systems for m ultiple M R Toolkit applications to com m unicate using UDPs. T he communication subsystem allows M R Toolkit processes to u p d a te their peers with current local device d a ta - essentially checkpointing their sta te onto th e set of peer MR Toolkits. In addition, the Peer Package allows for application specific communication between peers using a sim ulated shared memory communication model.
T h e connection topology is peer-to-peer; lim iting the scope o f the peer package to approxim ately five distributed users[38j. To com pensate for th e lack of available bandw idth, th e Peer Package uses a system whereby virtual objects are owned by M R Toolkit processes. W hen a process owns the virtual object, the sim ulation is perform ed locally and the effects are transm itted to all other participants, b u t a t a reduced update rate (e.g., every fifth simulation result for the hand-ball example in [38]). T h e overall effect is th a t the owner of the virtual object sees it move with much b e tte r fidelity than the remote users.
2 .4 .5
D IS (5)
T h e DIS standard[14] describes a protocol for managing warfare sim ulators over a wide range of communication media. The sim ulation exercise is separated into a collection of sim ulation applications; each application is responsible for representing th e virtual m anifestation o f one or more simulation entities (e.g., m anned vehicle
C H A P T E R 2. IN T R O D U C T IO N 16
sim ulator).
These sim ulation applications are distributed throughout the network w ith a sta n dardized protocol for com m unicating ground tru th data. Changes in sta te are de term ined by the controlling sim ulation application, and the perception o f events is determ ined by the receiving application. For example, it is possible for targets to be obscured by smoke or terrain. Since the ground tru th is transm itted throughout the network, the receiving application is responsible for not showing th e obscured targets to the user.
To reduce network load, DIS uses a dead reckoning protocol. Each sim ulator m aintains two states: the internal (i.e., real) state, and the approxim ate (i.e., dead reckoning) sta te . Only the dead reckoning sta te is transm itted to receiving appli cations. T h e dead reckoning sta te is evaluated according the dead reckoning model chosen, and when the dead reckoning sta te diverges from the internal sta te the dead reckoning sta te is updated to m atch th e internal state. Messages are only transm itted to the receiving applications when the dead reckoning sta te changes.
T here are nine dead reckoning models defined in the standard (and an additional two m odels are suggested), w ith the following model being the m ost general (other models are lower-order simplifications):
P = Po + F o A 4 + i.4 o A t^ (2.1)
(2 .2 )
where P , V , and A represent position velocity and acceleration; [R] and [DR] are the orientation and dead reckoning m atrix.
D ead reckoning provides a very nice beginning step, however it is too lim ited for general purpose use. T he quadratic form shown above is excellent for munitions
trajectories; but it can not be used as a basis function for generating complex paths through space-tim e. W henever a virtual object m ust follow such a p ath , the internal sta te an d dead reckoning sta te will constantly be out of sync; thus requiring a refresh. Also, th ere is a com putational drain associated with having to m aintain two sta te s (and converting from the internal to the dead reckoning state).
2.4.6
R T IM E In tera ctiv e N etw o rk in g E n gin e(2, 3)
The RTIM E Interactive Networking Engine[36] is an elementary object based pro gram m ing system , developed to support m ulti-user games over the Internet. T h e en gine is client/server based with capabilities for decoupling the environm ent u pdates from the graphic refresh rate, global tim e synchronization, virtual object filtering (based on object type a n d /o r distance). T he overall purpose is to provide fair access to the server for all clients (e.g., players) in a m ulti-user game.
T he engine A PI provides calls for: m anaging virtual objects (e.g., c reatio n /d e struction), updating virtual objects (e.g., assigning position, velocity, and accelera tion), finding objects (e.g., finding objects by nam e or association).
As w ith A lpha World, the client/server connectivity paradigm lim its the scalability of this im plem entation. To accommodate larger virtual worlds, significant upgrades of both th e com putational and com m unication resources are required.
2 .4 .7
P h y sica l S im u lation S y s te m s (l)
Robotics an d autom ation experts have been using dynamics sim ulators for many years, generally to model physical equipm ent. The Newton general-purpose dynam ics simulator[12] was developed to Investigate many^degrees-of-freedom articulated objects (i.e., robotic limbs). A special com puter language was developed to allow the
C H A P T E R 2. IN T R O D U C T IO N 18
user to describe physical and geometric attrib u tes of the objects to be sim ulated. A binding element called a hinge, defines how objects are attached (e.g., spherical jo in t or pin joints). T he generated system of Newton-Euler equations is then evaluated for each tim e step to perform the sim ulation. Collisions are handled using a relatively simple im pact resolution scheme: a t the point of im p art, the geometry of the objects is consulted to determ ine the resulting changes in veîeeity and angular m om entum .
In addition to modeling real-world devices, the dynam ics sim ulators approach has been increasingly popular am ong the anim ation community. The kinem atic clones system[58] models articulated figures (e.g., cartoon characters) using a kinem atics model. T he essential idea is to model an anim ated figure as a mechanical puppet with springs and dam pers to provide a n atu ral flow to the anim ation. This requires fewer “key frames” th a t the anim ator m ust be involved with. The kinem atic clone is sim ulated using a dynam ics sim ulator sim ilar to the Newton system described above.
We may also gain inspiration from systems involving remote space-born robotics. Hirzinger[23] suggests a state-space model for a telerobotic system. T he state-space model incorporates the transmission delays to and from the satellite, thereby allow ing for the com putation of the predictive sta te of the robotic arm (see Fig. 2.3). T he operator, on the ground, is shown a com puter graphic representation of the pre dicted position of the robotic arm th a t is m anipulated in the operator’s real-time; the controls are tran sm itted to the remote robot and the results (e.g., position) are transm itted back to E arth to update the state-space model.
The CPU requirem ents for a dynamics sim ulator, kinem atic clones, or state-space approach are too high for a real-time graphics display, even w ith today’s high perfor mance CPUs. For use in interactive applications like VR, we need to strike a balance between the physics based modeling and w hat can really be achieved on contem porary com puters.
S p ace Ground Delay Downlink S tate-S pace Model of Robot Error Function Delay Uplink
Robot
U ser O perated ControllerFigure 2.3; Simplified Hirzinger model for telerobot. T he State-Space model of the robot is used to drive a 3-D graphics display
2.5
Problem s w ith E xistin g Im plem en tation s
T he preceding case studies show th a t many of the current DVR systems have inherent difficulties. The following issues have been identified: (1) network efficiency, (2) coherency models, (3) v irtual object distribution strategies, (4) inadequate system resource balancing, and (5) overall performance. It is argued th a t many of these problem areas are ultim ately caused by inadequate system architectures, and lack of holistic design.
2.5 .1 N etw ork E fficien cy
Nearly all DVR systems use either m ulticast Peer-to-Peer (PPmc), unicast Peer-to- peer (PPuc) or client/server (C /S ) network architectures. T he abbreviation, P-P, will be used to indicate a peer-to-peer network architecture w ith an unspecified transm is sion mode.
C H A P T E R 2. IN T R O D U C T IO N 20
PPmc is a one-to-many transm ission mode in which a single message is sent to multiple network destinations[15, p. 4]. All nodes may send messages over the m ulticast channel to communicate w ith all o th er nodes with a single message.
PPuc is a one-to-one transm ission mode in which a single message is sent to a single network destination[15, p. 6]. M ultiple messages are sent in order to cover m ultiple destinations.
C / S is when a special node called the server is responsible for handling requests m ade by the remaining nodes (called clients). The clients are only perm itted to communicate to the server, while the server communicates to all th e clients using either a unicast or m ulticast protocol.
Several problems exist w ith P -P and C /S architectures:
1. T he bandw idth required by PP„c grows by the square of the participants.
2. M ulticast suffers from the problem where clients receive messages th a t they are not interested in, thus leading to wasted bandwidth.
3. M ulticast networks require special setup in order to be deployed. Many busi nesses and universities do no t allow m ulticast transm issions due to the extra bandw idth required.
4. T he C /S model exhibits a severe bottleneck a t the server node. Both commu nication resources and com putation resources must be scaled according to the num ber of participants.
5. T he C /S model also snffers from low availability due to being a single point of failnre. The entire system comes down in the event the server crashes.
An interesting example of a DVR system th a t does not use either P -P o r C /S is the WAVES architecture[25]. T his architecture uses special nodes called message
managers to partition the network and coordinate between rem ote regions of the
network. N either a P -P or C /S paradigm is suggested, instead a “tree-like” structure is built up w ith message managers com m unicating between “sub-trees” .
2 .5 .2
O b je ct D istrib u tio n an d C oh eren cy M o d els
P roper m anagem ent of virtual objects in a DVR system is critical when the numbers o f virtual objects and hosts in the DVR system grows. The litera tu re has shown m any approaches to m anaging virtual objects on multiple hosts; for example;
L a iss e z -fa ire or optim istic concurrency control[11] assumes th a t no interaction is required between virtual objects and corrects the assum ption when proven wrong (such as a collision event). Often, a special “synchronize now” call is m ade available to the application program m er to be used a t his discretion.
The laissez-faire approach can only work when there is little need for synchronizing virtual objects. Anytime virtual objects are used by multiple parties, the system breaks down.
A C e n tr a liz e d D a ta b a s e m aintains th e object’s state inform ation in a single server, thereby allowing the server to easily synchronize the sta te . T his is used by the client/server systems such A lpha World[9|. The centralized database approach requires all requests to be funneled into a single resource (e.g., network router, or server machine). The lack of distribution causes bottlenecks w ithin the network fabric which are only addressed by deploying larger and faster system s (expensive). Ill addition, the centralized database represents a single point of failure. If the server machine goes down, then the entire database is unavailable until restored.
C H A P T E R 2. IN T R O D U C T IO N 22
O b je c t O w n e r s h ip T ra n s fe ra l systems replicate the database on all hosts, b u t only one host has ownership over an object a t any point in tim e. T he MR Toolkit describes object ownership transferal[38]. It is difficult to see where generalized use for ownership transferal mechanisms can come into play. This scheme is only appropriate for applications where a n atu ral ownership is exhibited, such as a game of squash (specified in [38]).
L o c k in g th e v irtual world database enforces consistency by restricting access to the database itself. The DIVE DVR[5] system locks the database w ith m utual exclu sions. Locking provides a good mechanism for ensuring th a t transactions are carried o u t sequentially, however using a locking mechanism for distributed applications in volves a lot of network traffic and involves long tim e lags. Typical distributed locking schemes require messages to be sent repeatedly to all h o sts[ll]; m aking it nearly impossible a t current network latencies to have real-tim e interaction.
D e a d R e c k o n in g is used by the DIS standard[14] to reduce network load. Dead reckoning provides a mechanism to describe behavior of a virtual object over tim e w ithout the need for a steady stream of update messages from th e sim ulator process. U nfortunately, the behavior is lim ited to simple, static mechanisms (e.g., m unitions trajectories and steady sta te velocities). The choice to have two sim ulation models (the real application’s sim ulation model plus the dead reckoning model) requires ex tra work on the p a rt of the application to tran slate from the application’s model to the dead reckoning model. U nfortunately, the model used by the dead reckoning protocol is not sophisticated enough to host generic application objects.
2 .5 .3
In ad eq u ate S y ste m R esou rce M an agem en t
Many D VR developers leverage operating system (OS) services to manage system resources. While many o f the a ttrib u te s of DVR systems parallel those o f distributed o perating systems (e.g., A m oeba[8,11]), there are two m ain differences between them :
F irst, distributed OS do no t require high levels o f immersion or interaction. For example, the Network File System (NFS) is a common distributed OS component. However, the NFS is not suitable for supporting hundreds of hosts m anipulating the sam e files; both in term s of file integrity and performance.
Second, many distributed systems emphasize accuracy and d a ta integrity; often going to long lengths to ensure transactions are atomic[8, 11]. D istributed virtual reality systems, however, are typically concerned, primarily, w ith providing immersion and interaction to the participant; d a ta integrity comes second.
These differences are often a result of the m anner for which the system manages the resources (e.g., early vs. late binding of resources).
2 .5 .4
O verall P erform an ce
It is inherently difficult to assess th e relative performance m erits of one DVR imple m entation over another. One reason is because of the “apples and oranges” com par isons th a t inevitably arise. For example, we would find it very difficult to compare the M R Toolkit to the DIS protocol - they are ju st too different. A nother problem is the difficulty in defining performance in the first place.
Traditionally, applications are gauged by their elapsed tim e. For example, a com piler th a t finishes in 23 m inutes is faster than one th a t compiles in 38 minutes. Elapsed tim e m easurem ents work well for sequential programs.
C H A P T E R 2. IN T R O D U C T IO N 24
DVR applications, however, are not sequential applications. Instead, they are driven by th e user clicking the mouse or gesturing w ith the DataGlove. M aintaining a high degree of interaction is often th e m ost im portant task for DVR system . The degree o f interaction can be improved by increasing the frame rate, reducing tim e lags when operating virtual controls, and using more sophisticated rendering models (e.g., tex tu re m aps and shading models).
Furtherm ore, m anaging the fidelity of the environment as a whole takes on a new im portance. For example, a fast frame rate is considered im p o rtan t for users to feel connected to the virtual world; however, a fast frame rate with wire-frame graphics m ight not be as appropriate as a m oderate frame ra te with fully rendered graphics.
Even though it is difficult to measure the performance of DVR systems, it is still im portant to provide a suitable platform for executing D VR applications. Tak ing these issues into account, the following criteria are suggested for m easuring the perform ance of a DVR system:
S y n c h r o n iz a tio n F id e lity is the measure of the disparity between hosts’ views of the same virtual world. To support interaction between users, their views of the virtual world m ust be as close as possible to each other.
E n v ir o n m e n t L a g is the am ount of tim e it takes to notify a rem ote host of a change made to a virtual object. A long environment lag prom otes confusion within the virtual environment as objects become out of sync w ith each other.
D is p la y L a g is the am ount of tim e it takes to draw the scene for th e user. Long display lags prom ote sim ulator sickness, and general confusion for the user.
D V R C a p a c ity is a measure of the m aximum num ber of hosts the DVR system can reasonably support. Ideally, the DVR system will scale by th e num ber of hosts.
G r a p h ic C o m p le x ity indirectly measures the quality of the graphic model. Higher graphic complexity generally reflects a higher sense of realism. For exam ple, more polygons or sophisticated rendering algorithm s create more realistic scenes.
2.6
G eneral C riteria for E ffective D V R S ystem s
A large contribution to the success of a DVR im plem entation is th e effect on the display and environment lags. Display lag, the delay between refreshes, affects the user’s com fort during the virtual experience because a long display lag can lead to the onset o f sim ulator sickness[50, 6]. Environm ent lag, the delay between object updates within th e V R world, affects the user’s ability to interact in the virtual world. A long environm ent lag prevents the user from being able to anticipate an object’s trajecto ry thereby prom oting frustration. Studies indicate th a t the display lag should be less th an 80 ms to m aintain hand-eye coordination[6]. Unfortunately, sim ilar studies for environm ent lag have not been located.
A list of requirements for DVR is provided below. Requirements affecting display lag are tagged w ith D L , and those th a t affect environment lag are tagged E L .
2.6.1 B e tte r G raph ics (DL)
Fast rendering speed is essential for an acceptable refresh rate (e.g., 10-40 Hz). De pending on the scene complexity this may be easily obtained w ith the m ain CPU , or external graphics accelerator cards may be required. This requirem ent also affects the visual realism. High quality com puter graphics (e.g., ray tracing) are also CPU intensive[19], thus a balance must be made between the need for good quality graphics
C H A P T E R 2. IN T R O D U C T IO N 26
an d the available CPU budget.
Scene rendering rates are greatly affected by architectural issues such as the choice of CPU and graphics library. T he DVR designer has some control over the refresh rates by selecting different rendering algorithm s (e.g., using texture m aps and complex lighting models require more CPU power) and limiting scene complexity (e.g., fewer polygons).
2.6.2
Fast N etw ork in g(E L )
Fast networking (low latency and high bandw idth) keeps the distributed nodes syn chronized. Low latency is im portant for quick transm ission of sm all requests and responses, while a high bandw idth is necessary for transm itting large chunks of d ata, such as when loading the virtual world.
2.6 .3
S yn ch ron ized V irtu a l E vents(E L )
T his ensures th a t when two people, in the real world, m anipulate an object sim ulta neously (or nearly) the object will react to b o th interactions. For the virtual envi ronm ent to model this behavior, architectural support m ust be built into the DVR system.
2 .6 .4
E ase o f U se
It is im portant for people to have easy to use interfaces for developing virtual ob jects in the DVR system. Some systems address this by providing means to translate files developed using professional CAD programs, other systems provide a CAD ap
plication w ritten for the DVR system . An easy to use DVR system enables faster deploym ent and quicker adaptation, which is essential for general acceptance.
In addition, the system m ust also be easy to design applications on it. Easy to use program m ing environments encourage the rapid deployment and quick adaptation of m any applications.
2.6 .5
A u to n o m o u s V irtu a l O b jects
A utonom ous virtual objects enable th e objects to react to the virtual environm ent w ith o u t resorting to m onolithic solutions embedded within the system itself. T his increases flexibility of the virtual world because the behavioral component can be extended to provide application program m ing within the virtual world.
2 .6 .6
H etero g en eo u s C o m p u tin g P latform s
People w ith a diverse selection of com puting hardware should be perm itted to interact together. For example, some users in a DVR may have modem connections (i.e., low speed), while others may have low resolution monitors. This requirem ent, however, introduces many difficulties th a t m ust be overcome. For example, a user with a slow connection speed bu t fast CPU will need to emphasize the local com putation ability to overcome the slow connection speed. The opposite is true of fast connection b u t slow CPU bound machines. This balancing of CPU to networking resources introduces a new se t of constraints th a t are critical to be solved in order for participants in th e v irtu a l world to get the most o u t of their hardware.
T h e team th a t created the Cyclades com pute network argues th a t heterogeneity is an advantage[2, p. 11];
C H A P T E R 2. IN T R O D U C T IO N 28
I t allows one to get the best from each system , since it removes the con strain t of having one single type of system for all applications. Machines can be dedicated to the work they are best adapted to (e.g., business oriented, scientific, d a ta base).
2 .7
C hapter Sum m ary
In this chapter we began w ith a discussion to define VR. A fter exam ining some of th e current definitions, we came up w ith three essential p arts of VR: immersion, interaction, and com puter technology.
A series of case studies was then presented to give the reader a feel for the sta te of th e current a rt of V R design. In particular we examined the: VRML, DIVE, Alpha World, M R Toolkit, DIS, RTIME, and Physical Simulation Systems.
T he case studies dem onstrated several problems th a t exist with contem porary DVR systems. These problems were identified as: network efficiency, object distri bution and coherency, inadequate system resource management, and overall perfor mance.
Finally, we itemized the list of item s th a t are required for an effective DVR system - the criteria or benchmark: b etter graphics, fast networking, synchronized virtual events, ease of use, autonom ous virtual objects, and heterogenous com puting p lat forms.
C hapter 3
N AV L S ystem A rch itectu re
T h e NAVL system architecture a ttem p ts to address (from the functional point of view) the problems of DVR system s discussed in Ch. 2.
T h e m ajor components of the NAVL system architecture are:
1. A network architecture th a t reduces bandw idth and latency.
2. An object distribution and coherency model th a t provides b etter user-to-user synchronization.
3. A combined rendering and collision detection system th a t takes advantage of the shared elements of their respective components.
3.1
O bjectives o f S ystem A rch itectu re
T h e m ost im portant objective of the system architecture is to address the problems found in Ch. 2. An engineering approach^ to these problems is used to develop robust
^An engineering approach is different than a scientific approach in th a t it is concerned with efficiently applying technologies to construct products, whereas scientific approaches are often used
C H A P T E R 3. N A V L S Y S T E M A R C H IT E C T U R E 30
solutions. Usually, this involves the integration of common off-the-shelf components. However, on occasion, this also involves th e creation of new technologies as will be seen in the coming sections
In addition, as p art of the engineering approach we desire to use holistic design principles when building our DVR system . As was seen with the case studies, many contem porary DVR systems are focused on a narrow range of services. An effective DVR system of practical value needs to integrate a wide variety o f services. This “wide angle view” requires a holistic approach.
T he final objective is to find solutions th a t scale well. Some argue th a t detailed software engineering is not required with current software products because hardware capabilities are increasing so quickly. In opposition to this view, it is felt th a t trem en dous benefits can be realized if the software is well engineered. In particular, a well engineered distributed system will scale b etter and require less hardw are (i.e., low cost) to function a t a com parable level of performance. The e x tra care placed in the design phase is very small compared to the cost of redesigning a non-scalable system.
NAVL is best able to support applications with little synchronisation requirements (e.g., no atom ic transactions). Applications such as tele-surgery would no t be suitable to NAVL because the NAVL system has no mechanism in place to “roll back” from an operation. Due to the uncertainties of network latencies and the synchronisation mechanism used by NAVL, it is possible for remote hosts to be tem porarily out-of synch, which might cause an operator to make an error in his or her actions.
3.2
T h e NAVL A rch itectu re at a G lance
T he NAVL system architecture has three prim ary components: (1) the network archi tecture, (2) the object distribution and coherency architecture, and (3) the rendering and collision detection architecture. The NAVL architecture exhibits the following capabilities:
A u to n o m o u s V i r t u a l O b je c ts allow an encapsulation of the v irtual object th a t m ay be moved as needed to balance the C PU and networking loads.
D i s t r i b u t e d C lie n t/S e r v e r N e tw o r k A r c h i t e c t u r e reduces bottlenecks w ithin the network by spreading the bandw idth throughout the network, while sim ultane ously reducing the load to the network between peers as com pared to other network architectures (discussed in Ch. 5).
M a s t e r / S la v e V i r t u a l O b je c t D i s t r i b u t i o n a n d C o h e re n c y M o d e l splits the v irtu a l object into a single m aster object and several slave objects. T he m aster object is responsible for the sta te of the object while the slave objects represent th e local m anifestation of the object. T he slave objects execute high-order com m ands called ForceLets th a t describe a path through space for th e object to follow.
L o c a l S im u la tio n o f V i r t u a l O b je c ts b y S la v e O b je c ts reduces network band w idth requirem ents by executing much of the virtual object’s actions local to th e user rath er th an a t a remote location (e.g., server).
C H A P T E R 3. N A V L S Y S T E M A R C H IT E C T U R E 32
3.3
N etw ork A rchitecture
The purpose of the network architecture is to enable m ultiple participants an d a l low the sharing of com puter resources (e.g., CPU and storage). As seen in Ch. 2, problems with existing network architectures are often related to the network’s topol ogy. Client/Server systems do not scale well to increasing numbers of clients due to a severe bottleneck a t th e server node. Peer-to-peer systems also do not scale well to increasing participants because the num ber o f messages sent through the netw ork infrastructure grows quadratically.
The targ et network environment for NAVL is a large-scale network w ith m any local area networks (LAN) connected by a wide area network (WAN). Routers connect th e LANs to the WAN interconnect.
In many network deployment, such as an office environment, people working on the same areas of interest are often placed into their own LANs. Generally, this is a side- effect of the natural evolution of the network w ithin the organization. For exam ple, the engineering departm ent is often located in a different floor (or even building) from th e sales and m arketing departm ents, thus creating a natural boundary for LANs within the organization.
The NAVL DVR network architecture leverages this natural partitioning of n et work resources, employing a dual-region network architecture. The LAN in N.AVL uses a broadcast tran sp o rt mode such as found w ith E thernet, while the WAN is a collection of peer-to-peer channels th a t link up th e LANs.
Using a broadcast LAN allows participants to snoop on messages. Many messages sent in th e DVR system affect virtuai objects distributed between many participants; in the situation where the m ajority of the affected participants are contained w ithin the LAN, a lot of bandw idth can be saved by leveraging th e broadcast medium.
^
^
^
\ [ MM] 1 i l
-Figure 3.1: D istributed client/server network architecture
T he peer-to-peer connections use quality of service (QoS) technologies whenever possible, such as available w ith ATM, IPv6, and RSVP (see [3, 43, 45]). The QoS capabilities allow systems to specify the maximum acceptable latency and jitte r within the packet switching networks.
Q uality of service is helpful for the DVR system to ensure a consistent view of the shared virtual environment to rem ote users. However, it is not always available. For th is reason, the NAVL system architecture employs mechanisms to reduce the effect on the user from latency and jitte r (i.e., ForceLets).
Figure 3.1 shows an example deployment of the NAVL network architecture called D istributed Client/Server. T he WAN is shown as a collection of peer-to-peer chan nels between the LANs, where the LANs are shown as a collection of NAVL hosts connected to a common broadcast medium.
Between the two regions are special server hosts called message m anagers (bor rowed from the WAVES architecture[25j). The message m anager has four tasks:
C H A P T E R 3. N A V L S Y S T E M A R C H IT E C T U R E 34
existing IP routers, albeit a t a different network layer^.
2. F ilter messages going to and from the WAN. By filtering messages going to and from the WAN, the message m anager has control over the loading of the rest of the network. For example, the engineering departm ent m ay not wish to export their virtual objects outside their departm ental LAN.
3. Directory Service allows a quick lookup for virtual objects o r participants in the network.
4. Q uality of Service capabilities within the message m anager enable it to select different QoS service levels. This may be useful if the application needs to briefly increase its QoS resources for some purpose, or to drop its QoS resources.
The distributed LAN architecture described in this section can be thought of as a combined peer-to-peer and client/server model.
3.4
O bject D istrib u tion and C oherency
T h e term “distribution” used here means the overall mechanisms for arranging virtual objects in the network such th a t they can be accessed by m ultiple participants. These mechanisms often include networking architectures (e.g., distributed client/server as seen above) and access algorithm s (e.g., locking and two-phase com m it).
Coherency, however, refers to the mode for which the virtual objects are updated an d kept synchronized. For example, the DIS standard uses dead reckoning to move objects through space.
