ORIGINAL ARTICLE

Olarn Wongwirat Æ Shigeyuki Ohara

Performance evaluation of compromised synchronization controlmechanism for distributed virtual environment (DVE)

Received: 14 March 2003 / Accepted: 20 April 2005 / Published online: 24 May 2005� Springer-Verlag London Limited 2005

Abstract Synchronization in a distributed virtual envi-ronment (DVE) involves mechanisms to ensure a con-sistent view of a virtual world for all participants. Mostapplications in the DVE are related to collaborativeactivities that include non-contention and contentioncases. Using transmission of update messages is suitableenough to support synchronization for only non-con-tention activity. The contention activity requires anadditional mechanism to control accessing a commonobject for synchronization. In this paper, we present thecompromised synchronization control mechanism tosupport both non-contention and contention activities.The mechanism employs frequent update event andmultiple-lock checking to control the synchronization.Frequent update event is used to support a dynamicvirtual world for non-contention activity. Multiple-lockchecking is embedded to ensure consistency whenaccessing the common object is required simultaneouslyfor the contention event. Performance measurement ofthe compromised synchronization is provided by simu-lation in terms of locking time, sampling event, numberof logical processes, and traffic tolerance. Prototypeapplication is also implemented to compare the result ina small scale level. Based on the simulation and experi-mental results, the compromised sychronization controlmechanism is capable to support up to 100 participants

for the non-contention activity. It provides a good per-formance of supporting the contention activity in a smallscale. The mechanism is considered suitable for collab-orative application where contention is considered acritical event.

Keywords Performance evaluation Æ Compromisedsynchronization Æ Dynamic shared states Æ Frequentupdate event Æ Multiple-lock checking Æ Distributedvirtual environment

1 Introduction

Recent computer graphics, multimedia systems, parallel/distributed systems, and high-speed networking tech-nologies are advanced enough to enable computer sci-entists and engineers to establish distributed virtualenvironment (DVE) systems. A DVE is computer-gen-erated 3D graphical spaces (or virtual world) to supportmultiple users locating in different parts of the network.DVE is a distributed system that allows multiple users toconcurrently explore and interact with each other withinthis virtual world. Users who are exploring the DVE canextract relevant information about the virtual environ-ment and communicate in real-time with other users inthe same virtual environment.

Typical applications of DVE system are team train-ing, entertainment, sport, shared design, teleconferenc-ing, education, and other collaborative activities. Thefollowing examples are some dedicated systems thatsupport these types of application. A popular trainingapplication is the US Army project, closed combat tac-tical trainer (CCTT) [1, 2]. CCTT is a simulated-basedtraining system that aims to train ground combat tankand mechanized infantry forces on simulated equipmentusing a high-fidelity representation of actual terrain.Amaze [3], Space war [4], and recent on-line 3D gameson the network are examples of its application inentertainment. An example of the DVE system used in

O. Wongwirat (&)Faculty of Information Technology and Research Center forCommunications and Information Technology,King Mongkut’s Institute of Technology Ladkrabang,Bangkok, 10520, ThailandE-mail: olarn@it.kmitl.ac.thTel.: +66-2-7372447Fax: +66-2-3264332

S. OharaDepartment of Information Media Technology,School of Information Technology and ElectronicsTokai University,Kanagawa 259-121, JapanE-mail: ohara@keyaki.cc.u-tokai.ac.jpTel.: +81-463-581211Fax: +81-463-502412

Virtual Reality (2006) 9: 1–16DOI 10.1007/s10055-005-0158-0

sports is Live 3D stadium in [5] which applies personaltracking system (PTS) that uses spread-spectrum radioranging in a virtual environment to track the bodyposture of sport players. The behavior packets are thentransmitted over a wireless network. Shastra system is ageometric and scientific shared design environment [6].The system emphasizes distributed problem solving forengineering and scientific design work. The systemprovides an infrastructure for user and application levelcooperation and supports synchronous multi-userapplication, connection, and communication. Team-Workplace is a virtual meeting room for teleconferenc-ing which uses VRML and Java based DVE system [7].The virtual meeting room can support voice communi-cations, video avatars, and multimedia presentations.An example of DVE systems’ usefulness in education isthe autonomous underwater vehicle (AUV) which is avirtual submarine designed for underwater world edu-cation [8]. The AUV model is operated in a virtual tankthat imitates the Monterey Bay region. There are moreissues for the DVE system in research and academicareas such as DIVE, MASSIVE, MR Toolkit, andVINCENT that can be found in [9–12] respectively. Thecommon feature of these typical DVE applications iscollaborative activity. Collaborative activity enablesparticipants to interact and share objects as if physicallypresent in the same place. To collaborate in the DVEsystem, each participant has to get a consistent view ofthe virtual world. That is if an action taken by any of theparticipants or if the state of any of the objects in thevirtual world is changed, every participating user shouldbe able to view the change immediately. In order toprovide this consistent view for all users, a DVE systemneeds to perform some form of synchronization [13, 14].

There is a lot of research in synchronization that hasbeen done in DVE systems, e.g., SIMNET [15], DIS [16],NPSNET [17], and NetEffect [18, 19]. These researchworks use generic mechanisms for scalability and aresuitable for a large scale DVE system. Their synchro-nization technique is based on providing a consistentview of the virtual environment by using the transmis-sion of update messages representing the motion ofobjects and avatars (or participating users). This updatetransmission technique is suitable for non-contentionactivity. There are a few works focused directly on thecontention activity for collaboration in the DVE system.Moreover, there are factors to be considered for thesynchronization in the DVE system, such as systemarchitecture, communication, and network. These fac-tors affect synchronization performance in terms ofscalability and reliability that should be achieved underconstraint of delays on the communications and thenetwork. A consistency-throughput tradeoff is also an-other parameter to be considered. This tradeoff isspecified by the above mentioned factors and corre-sponds to the degree of collaboration in the DVE systemas well.

In this paper, we address the issue of synchronizationcontrol mechanism that focuses on contention and

non-contention activities for collaboration in the DVEsystem. Our presented synchronization employs a fre-quent update event and multiple-lock checking mecha-nism to control a dynamic shared state of the object. Thesynchronization is considered compromised because itachieves both consistent and dynamic tradeoff for acertain scale DVE. Performance of the compromisedsynchronization control mechanism has been evaluatedby simulation. The simulation was performed by threedifferent sampling periods under a number of partici-pants, workloads, and bandwidths on the network. Thiswas to verify how the mechanism could achieve thesynchronization to support such collaborative activities,in terms of communication and network factors. Theprototype application using the compromised synchro-nization was also implemented to verify and to comparewith the simulation results.

The organization of this paper is as follows: In Sect.2, we describe the background information of a DVEsystem, collaboration and synchronization features, andrelated work. In Sect. 3, we present the compromisedsynchronization control mechanism in detail to supportcollaboration in the DVE system. In Sect. 4, the exper-iment and performance evaluation method by simula-tion will be expressed. Simulation results are carried outin Sect. 5 to illustrate the performance that the presentedsynchronization control mechanism can achieve. Theimplemented prototype is also included in this section.Finally, conclusions and future works are provided inSect. 6.

2 Background and related work

Basically, DVE emerges from a combination of virtualreality (VR) and of distributed simulation system. Theterm ‘‘virtual environment (VE)’’ is sometimes used toextend the boundary of VR [20]. Research in the paralleland distributed simulation system has also classified thesimulation to support applications of two types, i.e.,analytic simulation and virtual environment [21]. Thegoal of analytic simulation concerns capturing detailquantitative data from the system being simulated. Thepurpose of distributed virtual environment application isdifferent. It concerns achieving sufficiently realistic rep-resentation of 3D graphical spaces as perceived by theparticipants embodied in the virtual environment.

In the DVE system, the term ‘‘object’’ is used torepresent a participant, or other real world objects (e.g.,desk, chair, book, and so on), to be displayed in thevirtual world. In the area of distributed simulation, theobject means a dynamic shared state which is the entitystate variables, e.g., relative location and currentbehavior of the object [21, 22]. The dynamic shared stateconstitutes the change of information about the virtualenvironment that every participant machine (calledlogical process or simulator) must maintain. Thus, syn-chronization involves a mechanism to maintain tempoand relations among the dynamic shared states in the

2

virtual environment on each logical process. The aim ofsynchronization is to preserve a consistent view of thevirtual environment by each participant.

As mentioned in Sect. 1, typical applications of theDVE system involve collaborative activities, which wefind similar to the term ‘‘collaborative virtual environ-ment (CVE)’’ [10, 23, 24]. To support collaboration, thesynchronization is required to maintain a consistentview and coordination between two or more partici-pants. There are two main activities, or behaviors, ofcollaboration to be considered in typical DVE applica-tions, i.e., non-contention and contention. The non-contention activity is considered as an independent eventthat occurs in the virtual environment. In this case, theavatar representing participant has less interaction, orconcern, to the other. For instance, when an avatarwalks around the virtual meeting room, it just sends onlyupdate message to notify the other participants about itscurrent position to be displayed for synchronization.The contention activity is considered as a critical eventsuch as when two, or more, avatars require accessing acommon object simultaneously in the virtual environ-ment. An example of such contention activity can beseen in the scenario when two surgeons try to grab anorgan of a virtual body for surgery. Instead of justsending the only update position, the contention activityneeds additional mechanism to control the dynamicshared state of the object for synchronization.

In addition, the system architecture, communica-tions, and network factors are required to consider forsynchronization as well. These factors determine syn-chronization performance of the DVE system beingperformed under the constraint of delays on the net-work. They result in a consistency-throughput tradeoff,which the virtual world will either be consistent or dy-namic [22]. The tradeoff affects the design of synchro-nization as related to the degree of collaborativeactivities in the DVE system and the delay that can betolerated. For a dynamic DVE, the collaboration can beloosely coupled, or soft synchronization, and applicableto the non-contention activity. In a consistent DVE, thedegree of collaboration must be tightly coupled or hardsynchronization, which is appropriate for the contentionactivity. That is, instead of changing the virtual worlddynamically (or less consistency), the consistent view isnecessary in order to determine which participant ulti-mately has access to the common object.

2.1 Synchronization techniques and standards

Several synchronization techniques have been issued inresearch on the parallel and distributed simulation sys-tem. For instance, the casual ordering control methodfor conservative synchronization can be found in [25].This method uses global checkpoint and reduces the nullmessage for deadlock avoidance. Optimistic synchroni-zation in time warp approach is presented in [26]. Thisapproach uses retraction of previously scheduled events

that is invoked by user to avoid a failure, or break down,process. Space-time memory using shared memoryconstructs for parallel and discrete event simulation intime warp mechanism is introduced in [27]. However,these techniques are designed to support analytic simu-lation purposes that require exactly the same quantita-tive results, as-fast-as-possible calculations, nointeraction by human participants, and tolerable largedelays [21, 28]. There is an effort in [29] to merge theanalytic simulation approach into the DVE system, butthe performance results were non-linear for severallogical processes. The author in [28] provides a welldifferentiated comparison between distributed interac-tive simulation synchronization and parallel discreteevent simulation.

Synchronization techniques and related standardsbeing developed by the VR’s simulation community tosupport the DVE system have been the subject inmany papers. For instance, distributed interactivesimulation (DIS) uses transmission of an update mes-sage corresponding to the change in the state of ashared entity for synchronization [16]. The DIS lateracquired dead reckoning algorithm to reduce thenumber of update messages by using an extrapolationalgorithm [30]. In [31], the authors enhance the DIS byusing selectively reliable multicast protocols to drasti-cally reduce network traffic. In [14], the author sum-marizes synchronization techniques based on the DISinto three approaches and derives the optimal syn-chronization interval for consistent view. The DISemerged from the SIMulator NETworking (SIMNET)[15] and has been later approved as standard ofIEEE1278 [32]. Recently the DIS has prospered to ahigh level architecture (HLA) [33]. The HLA is aframework for reuse and interoperation of simulations.The baseline definition of the HLA includes the rules,interface specification, and object model template. TheHLA attempts to provide a very generic environmentthat any virtual object can attach to in order to par-ticipate in the simulation.

There are also some dedicated systems that supportcollaboration in the DVE system. Distributed interactivevirtual environment (DIVE) is an internet-based multi-user VR system developed at The Swedish Institute ofComputer Science [9]. The system allows its participantsto navigate, see, meet, and interact with others in 3Dgraphical space. The DIVE uses the ISIS communica-tion library to update the local copy of the shared stateentity before broadcasting it to all participating ma-chines. The operation is performed in order, as using atoken pass message, to maintain consistency. MRToolkit is another consistent approach by keeping thedynamic shared state in all participant machines [11]. Apeer packet representing the current state variables ispassed to adjacent nodes, as indicated in an appendinglist, to perform synchronization. The literatures, how-ever, have no mention of the case of contention activityor how to control accessing a dynamic shared statesimultaneously.

3

2.2 Research motivation

From our brief review of the published literatures in theDVE system, the synchronization techniques are de-signed and developed with different communication andnetwork architectures, as well as purpose of cooperativeactivity in the applications. They are considered pro-prietary and may not be compatible. Some standards arealso very generic while others make certain assumptions.For instance, the DIS is used primarily for distributedsimulation of military scenarios and scales up well to alarge number of users on a dedicated platform of thecore network [1, 2, 16]. Due to the continuous stateinformation transfer and dead reckoning technique, DISdoes not appear very suitable for general-purpose multi-participants DVE system [7, 34]. The HLA does also notprescribe a specific implementation, nor does it mandatethe use of any particular set of software or programminglanguage. It is adapted to work on a specific applicationusing various rendering and graphic standards [7, 23,35].

We have found that most research involving theabove synchronization techniques mainly concerns non-contention activity for collaborative application, whichrequires only soft synchronization. Thus the techniqueusing transmission of update messages and extrapola-tion of dead reckoning is good enough to support suchnon-contention activity that requires a less consistentview in term of the dynamic virtual world. If contentionactivity is considered an important event, then the de-gree of collaboration must be tightly coupled. Thus, onlysending the update message might not be enough. It willrequire hard synchronization for which additionalmechanisms to control the dynamic shared state of theobject for contention. The mechanism used for thissynchronization technique should be persistent until theparticipating user has the absolute grant to occupy thecommon object. It must include request attempt, occu-pancy, and release the common object. In the event thatthe application is considered critical, the mechanismmay hold the state to ensure the absolute access to thecommon object.

Although some synchronization, such as DIS [16, 32],provides a mechanism to support contention, the systememploys a central manager to control the dynamicshared stated of common objects, which is designed tosupport specific combat training application on a largescale only. The works in [36, 37] also use a centralmanager to control synchronization for collaborationand identical view of the virtual world. Another centralmanager using distributed central server architecture isNetEffect [18, 19]. The NetEffect employs a similarsynchronization technique as DIS, but partitions thewhole virtual environment into communities. Eachpartitioned community is allocated its own central ser-ver. NetEffect is designed for extending capability oflarge-scale multi participants system. However, thecentral server suffers bottleneck as well as communica-tion lag, due to double-hop exchanged information

through a central server. Consequently reliability prob-lem exists with a single point of failure that loss destroysall dynamic shared state information. These systems aredesigned and suitable for a large scale DVE system.

The HLA also mentions about controlling a dynamicshared state of the common object by using an owner-ship transfer mechanism to indicate which participatinguser is allowed to access or manipulate the object [33,35]. The instance ownership (or dynamic shared state) isshared by the owning federate (or logical process) of theobject. When another federate attempts to acquire theownership of the object, the owing federate grantsthe acquisition and releases the ownership. However, thepapers do not mention the condition upon which theownership will be granted, particularly when an object isrequired by more than one federate simultaneously. Themechanism is implemented in run time infrastructure(RTI) which allows federates to update and delete objectinstances with very few restriction.

Therefore, in our research, we focus on synchroni-zation that supports non-contention and contentionactivities in the DVE system. The distributed serverlessarchitecture using peer-to-peer communications is em-ployed to avoid such central server drawback and is notsuitable for a very large-scale application. The workconcentrates on the contention activity that the hardsynchronization using multiple lock checking mecha-nism is embedded to verify the acquired condition forgranting access. However, the soft synchronization usingfrequent update event is also included in the work. Thereare previous issues that relate to the work we have done.Multiple lock checking mechanism was first introducedin [38]. The dynamic and static delay that affects themultiple lock checking mechanism was issued in [39] andthe background traffic was added in [40]. The compro-mised synchronization control mechanism composed ofsoft and hard synchronization will be described in detailin the following sections, including performance mea-surement and prototype implementation using the pre-sented mechanism.

3 Compromised synchronization control mechanism

As described in Sect. 2, DVE is a derivative form ofdistributed simulation system. In distributed simulationsense, the term logical process (LP) represents a partic-ipant machine (or user host) running the simulation,sometimes called the simulator. The LP emulates thevirtual world being simulated in 3D graphical format.Each LP performs event sequence computation. Theevent sequence indicates where the dynamic shared stateis manipulated and scheduled to the new event. Eventinteraction among LPs representing multiple-participantcollaboration is performed by exchanging event mes-sages. The mechanism that controls the dynamic sharedstate of the entire LPs for synchronization in the DVEsystem will be described next.

4

3.1 Distributed serverless with peer-to-peer

To solve the problems of centralized and distributedserver approaches, distributed serverless architecture isused, as shown in Fig. 1. Each LP is connected in peer-to-peer, and the communications is performed directlyamong the LPs. Thus, no central server is allocated.There is some advantage in using this architecture. Forinstance, the number of CPUs can increase in propor-tion to the number of simulated entities. Distributedserverless has better performance in reliability andmaintainability, since there is no central server to coor-dinate the entire events. When any process goes down,the other LPs still keep communicating. Communicationamong the LPs is performed by exchanging event mes-sages in a distributed manner, thus no bottleneck isintroduced. Casual interaction of event representingnon-contention activity can be updated periodically torefresh the entity state variables of the dynamic sharedstate for realistic perception. For the contention eventthat requires consistency, or hard synchronization, themultiple-lock checking mechanism is used to verify thetransfer of the contended object.

3.2 Frequent update event

Frequent update event is a mechanism that allows eachLP to capture the entity state variables of the dynamic

shared state periodically. Then the captured state is sentto the other LPs in according to the sampling period.The concept of frequent update event is similar to theone found in DIS [32], which is a derivative form of theoriginal networked game in [3]. The frequent updateevent concerns updating the state of simulated entitiesfor having accurate dynamic shared states and creatingrealistic environments, or a dynamic virtual world. Toimprove consistency, locking control mechanism isembedded into the frequent event update for contentionevent synchronization. The captured period (or sam-pling event) for sending the update is specified by threevalues. This is to compare and to verify performance ofthe mechanism that the system can afford in simulation.

State-time diagram in Fig. 2 shows a flow mechanismof the frequent update event. The concept behind thismechanism is to let each LP (i.e., LP1, LP2, ..., LPn)maintain its entity state variables that represent partic-ipant entity and resources (i.e., common object) in theDVE. The entity state variables are captured and sent,whenever they change, to the other LPs periodically (i.e.,at Ts=0, 1, 2, 3,..., m). There are two main processesthat perform on the LP in every sampling period. Thefirst one is to send its captured state variables and thesecond is to update the entity state variables receivingfrom the other LPs. Time-stamped, entity ID, and otherstate variables are defined in the payload of the samplingevent for sending and receiving. By this mechanism, theLPs can maintain a realistic representation of the

Fig. 1 Distributed serverlesswith peer-to-peer connection

5

dynamic world that comes from the update dynamicshared state variables frequently. Causal error from outof order time-stamped is solved by having the new eventmessages to be updated from the other LPs periodically.When the update event cannot be reached to the desti-nation within a sampling interval, the LP discards thatupdate event and waits for the next message to updateinstead. This can be considered as a timeout period ofthe event message, for instance, the Time out message ofthe LP2 at Ts=2 (i.e., at Ts=3) and having the updateat Ts=3 instead.

3.3 Multiple-lock checking mechanism

The frequent update event provides a dynamic virtualworld and is suitable for the non-contention activity, asthe degree of event interaction is not crucial or softsynchronization. When the contention event occurs, anadditional mechanism is required to ensure consistencyfor the entire LPs and to verify the acquired conditionfor granting access. Therefore, the multiple-lock check-ing mechanism is embedded into the synchronization topreserve such requirement for the contention event inthe DVE. The concept of the mechanism comes from alocking algorithm using in transaction process fordatabase applications [41]. However, in the multiple-lock checking approach, there is no central server tocontrol the lock event as used in the database approach.When accessing the common object is required, the LPfirst checks the availability of the object. Before occu-pying the common object, the LP sends a lock requestmessage to the other LPs at the present sampling inter-val and waits for lock acknowledgement messages to bereturned. If no other lock request messages (or multiple-lock) is found, the requested LP can occupy by lockingthe common object as its entity. Then, the update

message informing that the common object has beenoccupied (or locked) is sent to the other LPs on the nextsampling period as in the regular frequent update event.

There are two events for the multiple-lock checkingmechanism to consider. They are the non-contentionand contention cases. The first case is found when onlyone LP requires accessing the common object and noother LPs requests. As shown in Fig. 3, assume only LP1

requests to occupy the common object, the LP1 firstchecks the common object in its virtual environment andsends the lock request message to the other LPs, i.e.,Lock_ Req11 at Ts=2. After receiving the lock requestmessage, the other LPs check whether or not the com-mon object has been locked in their virtual environment.If not, the lock acknowledgement messages allowing therequest are returned, i.e., Lock_ Ack11 from LP2 atTs=3. If the lock acknowledgement cannot be returnedwithin the sampling interval, it will time out, i.e., Lock_Ack11 from LPn at Ts=4. In this case, the requested LPstill cannot occupy the common object and will keepsending the lock request message (i.e., Lock_ Req12 atTs=3 and Lock_ Req13 at Ts=4) till all acknowledge-ment messages are returned (i.e., Lock_ Ack12 from LP2

and LPn at Ts=4). After having an unanimousacknowledgement, the requested LP then occupies thecommon object by locking and sending the update to theother LPs to update ownership at the next samplinginterval, i.e., Update (Occupy) at Ts=5. The lateracknowledgement messages will be omitted after lockingis successful.

In the contention event, as shown in Fig. 4, multiple-lock checking determines the final owner when there aremore than one LPs trying to occupy the common objectsimultaneously (i.e., LP1, LP2, and LPn at Ts=1). In thiscase, the requested LPs send and receive the same lockrequest message within the sampling period. After veri-fying the lock entity field from the payload, the

Fig. 2 Frequent update event

6

requested LPs unlock the common object with a randomtime (s) before re-locking once again. The new lock re-quest messages are then sent as usual. The random timeis used between Ts £ s £ nTs period on each LP foravoiding an echo. The random period might be consid-ered unfair, but acceptable in the virtual environment aslong as the human perception is indistinguishable.

Consider the sample period when two LPs startlocking the common object after unlocking with therandom time, i.e., LP1and LP2 at Ts=3. Delay on thenetwork causes the lock request message from LP1 totime out. The LP1 still receive the lock request fromLP2, which is identical event, i.e., Lock_ Req11 =Lock_ Req21. Thus, the LP1 unlocks the common ob-ject, as indicated at Ts=2. The LP2, at the same time,cannot get the update message contained lock request,

or lock acknowledgement, from the LP1 and keepssending the lock request message, i.e., Lock_ Req22.During Ts=4 to 5 interval, the LP1 receives the lockrequest message and, then, verifies that the messagefrom LP2 has occurred before, i.e., Lock_ Req22 >Lock_ Req11. Then, the LP1 sends lock acknowledge-ment back to allow LP2 to occupy the common objectas in the non-contention process. During the lock re-quest and acknowledgement verifying process, thecommon object and the requested LPs are in the holdstate, or hard synchronization. This is important forthe event that is considered critical. Instead of allowingthe virtual world to change dynamically, the hardsynchronization can verify absolute access of thecommon object and provide consistent view for all LPsin the contention event.

Fig. 4 Locking process forcontention access

Fig. 3 Locking process fornoncontention case

7

4 Performance measurement

The factors affecting the control of dynamic shared statefor synchronization in the DVE are system architecture,communication, and network, as previously mentionedin Sect. 1. Distribution scheme relates to the systemarchitectures, e.g., central server, distributed server, ordistributed serverless. The architecture of the presentsystem uses distributed serverless with peer-to-peerconnection to solve the central server drawback. Thissection addresses the latter two factors in detail forperformance evaluation.

4.1 Related parameters

Communication involves distribution scheme of theevent message as well, and network provides resourcesfor communications, e.g., bandwidth, throughput, anddelay. These two factors are tightly related and are dif-ficult to clearly distinguish. For instance, the bandwidthis proportional to the amount of traffic on the networksuch that increasing in traffic reduces an availablebandwidth. The amount of traffic also depends onapplications and the number of participant machines inthe DVE system. Communication delay is caused by thetraffic condition that is also initiated by processingworkload and queue processes at the nodes on network.Error correction and flow control mechanism used incommunication relate to reliability. A more reliablecommunication results in a greater overhead and delaythat downgrades the throughput achievement.

The communications and network factors define theperformance of synchronization to be achieved at acertain level. Therefore, we verify the performance of thecompromised synchronization control mechanism basedon the parameters under these two factors. The param-eters to be considered are traffic and delay which areinitiated by the sampling period and the number ofparticipant machines. For smaller sampling period orfrequent update, the virtual world can become moredynamic . However, the more frequent update eventresults in extraneous messages throughout the networkthat also increases the traffic volume and delay. Thenumber of participant machines induces the traffic anddelay in the same manner, and the enlarged scale ofDVE is proportional to the number of participant ma-chines also. The available bandwidth relies on theunderlying network that the LPs are located. Reliabilityof the transport layer communication is consideredminor, due to the lightweight payload of the capturedmessage that contains only event ID, time stamp, andresource entity, i.e., related pointer information aboutthe entity state variables of dynamic shared state. Weuse the user datagram protocol (UDP) to deliver themessages for reducing communication overhead.

Therefore, the sampling period and the number ofparticipant machines are the parameters that relate to

the performance parameters being verified. We set thesimulation study to evaluate the performance ofthe compromised synchronization control mechanism.The simulation performs under two cases: non-conten-tion and contention. The performance is measured bylocking time that the LPs use to lock (or occupy) thecommon object successfully, in both cases for compari-son. The locking time identifies the hold period of howlong the mechanism can achieve under effective end-to-end delay on the network. According to [42], theeffective end-to-end delay for interactive simulation andmultimedia data is around 100–300 ms. This end-to-enddelay period is acceptable and cannot be distinguishableby human perception. The simulation performs underthree different sampling periods with the differentnumber of participant machines in the study. Thelocking time affecting the amount of traffic from theincreasing number of frequent update events undervarious participant machines is observed. The simula-tion is also performed under various traffic conditions tosee the maximum workload that the mechanism canwithstand. It can be assumed that there are otherapplications sharing the network bandwidth. The lock-ing time in non-contention case represents the result ofdynamic virtual world that the synchronization can of-fer. The looking time in contention case expresses con-sistency when accessing to the common object isrequired simultaneously.

4.2 Logical process model

Figure 5 describes a state transition diagram of thelogical process model on each participant machine. Thestates in the diagram are classified as idle, sampling,wait, verify message, lock, unlock, and update. Thesestates are carried out to define as the events in simula-tion. The simulation starts with the idle state. When theobject entity of participant in the LP moves, the positionis tracked for the change, i.e., Obj_Movement (), and theLP starts the sampling state. The entity state variables,e.g., event ID, time stamp, position, and resource entity,are captured (or sampling) and transmitted to the otherLPs, i.e., Tx_ Msg(). The LP is then changed to thelistening state for the update event to be received. Whenreceiving the update message, i.e., Rx_ Msg (), the ver-ifying state is activated. Then, the update message isexamined locking condition from attribute in the re-source entity. If there is no lock request, the virtualenvironment is updated and returns to the idle state. Ifthere is a locking request, i.e., Lock_ Req (), the timestamp is compared. There are three conditions to com-pare. First, in case locking happened beforeði:e:; nþ 1) nÞ; the LP performs locking and returnsupdate to inform that the common object has alreadyoccupied, i.e., Tx_ Update(). Second, if locking is ap-peared after ði:e:; n( nþ 1Þ; the LP returns lockacknowledgement allowing the requested LP to occupythe common object. Finally, in case of locking at the

8

same time, or contention access, (i.e., n=n), the LPsunlock the common object with a random period, usingexponential back-off, before changing to the idle processfor locking process once again.

4.3 Network scenario

The local network scenario is used to assess what thelocking performance of the synchronization mechanismcan achieve. The local network is a simple model to startwith. The scenario represents the case of DVE applica-tion, which is composed of several LPs connecting onthe network, i.e., 10BaseT in this case. The simulationexamines the locking time that is effected by the amountof traffic, which is increased by exchanging the frequentupdate messages (e.g., updating position, lock request,and lock acknowledgement) and the number of partici-pant machines. To assess the performance, the intervalbetween the lock request message and the latest lockacknowledgement message is observed at the requestedLP. Each simulation trial is performed under varioustraffic load conditions for verifying the lockingachievement under the available bandwidth and delaythat the mechanism can tolerate.

The simulation is performed by using COMNET IIIRelease 1.3, which is the network simulation and mod-eling tool from CACI Products Company. The followingassumptions are made in the simulation to reflect aphysical network scenario of the DVE system to beverified.

– Each LP representing participant machines runs thesame DVE application.

– Each LP has ownership of its entity and maintains theupdate of common object entity, as well as the otherLP entities on every sampling period of the event.

– The application uses a local clock to generate an eventtime stamp on individual LP. To avoid the cause oftime stamp error and to simplify the simulation, theassumption that the clock on each LP is consistentand has no clock drift is also made. This assumption ismade for contention controls in distributed simulationapproach since there is no global clock as used in thecentral server.

– The sampling periods using in the simulation are 1, 2,and 3 s, and the number of participant machines are5, 10, 50, and 100.

Figure 6 expresses a snapshot of a simulationmodel ofthe network scenario for five processes. Each LP is spec-ified by the corresponding events as stated in the logicalprocess model. The events are scheduled by iteration withinterarrival of 1, 2, and 3 s, which represents the samplingperiods respectively. The LP is defined by using work-station parameters of 0.02 ls processing cycle, 0.01 mspacket processing time, 0.05 ms port processing time, and256-kbyte for I/O port buffer. These parameters reflecttypical workstations on the network. Link parameters onthe local network are 802.3 CSMA/CD standard of10BaseT with 1,024 session limit, 72-byte minimum and1,526-byte maximum frame size, and 30-byte frameoverhead. The payload used for update, lock request, andacknowledgement messages to be exchanged is 160 bytes,

Fig. 5 State transition diagram of the logical process model

9

as defined by the DIS PDU [32]. The payload data arecomposed of entity ID, time stamp, position orientation,and additional flag field for multiple-lock checkingmechanism. The messages employ UDP/IP protocol totransport with 20-byte overhead. The numbers of LPsconnecting to the local network are 5, 10, 50, and 100respectively. The 100 LPs represent the maximum num-ber of actual participants on a single LAN segment.

5 Simulation results

The simulation was performed under traffic conditionson the network, e.g., 0, 10, 20, ..., and 80% respectively.The zero percentage represents the case that no otherapplications share the bandwidth on network. Theincreasing number of traffic loads in percentage repre-sents the case where other applications share the band-width. The number of LPs running the DVE applicationis denoted by N, which are 5, 10, 50, and 100 LPsrespectively. The simulation was run for 900 s on eachtrial expressing 15 min operation with warm-up periodof 30 s. The warm-up period is used to avoid the tran-sient state when collecting data in statistical measure-ment. The 15-min run is long enough to cover all eventsin practice. The performance is measured by lockingtime under two cases: non-contention and contention.The results are plotted in terms of locking time versustraffic loads at a different number of LPs for comparison.

There are three sampling periods verified in the simula-tion. The graphs representing the performance achieve-ment of compromised synchronization mechanism aredescribed in the following sections.

5.1 Non-contention case

Figure 7 illustrates the graphs of non-contention casethat express the performance at the sampling period of1, 2, and 3 s, as shown in Fig. 7a, b and c respectively.

For N=5 and N=10, we can observe from the graphthat the locking time of non-contention case is less than100 ms for all sampling periods. This implies that ittakes only a short period, i.e., around 1–30 ms, to waitfor occupying the common object after the LP startedthe lock request. A difference is found in term of capa-bility that the mechanism can tolerate with differenttraffic conditions of the available bandwidth on net-work. For instance in Fig. 7a, at the sampling period of1 s, i.e., at S=1 s, the mechanism can tolerate under thetraffic around 50–55%. For the sampling period of 2 and3 s, the mechanism can tolerate more traffic, i.e., around60% at S=2 s in Fig. 7b and around 70–75% at S=3 sin Fig. 7c respectively. The reason is that the mechanismitself generates traffic load with the number of messagesfrom frequent sampling event to be exchanged. Thenumber of generated messages reduces the availablebandwidth to support synchronization.

Fig. 6 Network scenario for the simulation model

10

For N=50 and N=100, the locking time is consid-ered longer, i.e., around 100–300 ms, and the synchro-nization can be achieved with different traffic conditionfor all sampling periods. As in Fig. 7a, at S=1 s, thelocking time is around 100–160 ms within 40% of trafficcondition for N=50, and around 190–270 ms within30% of traffic condition for N=100. At S=2 s, as inFig. 7b, the locking time is around 120–230 ms within50% traffic for N=50, and around 220–280 ms within30% traffic for N=100. The locking time is around 140–200 ms at N=50 and around 220–290 ms at N=100, forS=3 s as in Fig. 7c. In addition, the mechanism cantolerate traffic up to 50% at N=50 and 30% at N=100for 2 s sampling period, and up to 60% at N=50 and

50% at N=100 for 3 s sampling period respectively. Wecan observe that the synchronization performance de-creases, as it requires longer time to occupy the commonobject, when the number of participating machines isincreased. In this case, the degree of traffic toleranceresults from not only the sampling period but also thenumber of LPs that participate in the DVE system.However, the locking period lower than 300 ms isacceptable and cannot be distinguishable by humanperception. Therefore, the synchronization mechanismcan support a dynamic virtual world in this non-con-tention case for the scale up to 100 participating users ata certain limit of traffic condition and the frequency ofupdate events.

Fig. 7 Non-contention case. a Frequent update event at 1 s. b Frequent update event at 2 s. c Frequent update event at 3 s

11

5.2 Contention case

Figure 8 describes the graphs in contention case thatexpress the synchronization performance at the sam-pling period of 1, 2, and 3 s, as shown in Fig. 8a, b and crespectively.

As shown in the graphs, the result of synchronizationperformance in contention case is quite different fromthe non-contention case. The locking time can beachieved within 100–300 ms only at the N=5 and N=10for all sampling periods. This implies that, in the con-tention case, the synchronization requires a longer timeto achieve locking, due to the multiple-lock checkingmechanism. However, with the 100–300 ms period that

is indistinguishable by human perception, it is consid-ered a success. Also, as in the non-contention case, thesynchronization can tolerate a higher traffic at the lowsampling rate of frequent update event, i.e., around 60%at S=3 s and 40% at S=1 s in Fig. 8 a and c respec-tively. This can result from the multiple-lock checkingmechanism that performs sending and receiving a lotmore locking messages during contention. These lockingmessages affect the available bandwidth on network.

Thus, for N=50 or higher, the locking time is over100–300 ms, they cannot be observed on the graphs,except at N=50 in Fig. 8a. This expresses that themultiple-lock checking mechanism may not be reachedwithin the range that is acceptable by human perception

Fig. 8 Contention case. a Frequent update event at 1 s. b Frequent update event at 2 s. c Frequent update event at 3 s

12

for a large number of LPs in the contention case.However, it cannot be considered that the synchroni-zation cannot we achieved in performance. This is be-cause the longer locking time denotes a holding periodto ensure that the LP has absolute grant to occupy thecommon object. This holding period representing a hardsynchronization may be acceptable by human percep-tion for the contention activity where the event is con-sidered critical and the consistent virtual world andcorrectness is required.

5.3 Prototype implementation

We built a prototype application using the compromisedsynchronization control mechanism as expressed above.The application of interest is a collaborative work wherethe two users are asked to perform a job in grabbing andplacing the objects on the workbench, as shown in Fig. 9a. The collaborative task contains both contention andnon-contention activities. The user who can take themost objects will be the winner. Each user is provided bya clamp and uses the keyboard to control the clamp forgrabbing, moving, and releasing the objects. There are

three objects to be grabbed, i.e., two cylinders and onebeam.

The prototype application was implemented byWorld Tool Kit (WTK) Release 8 running on the twoSilicon Graphics O2 workstations with IRIX 6.5 oper-ating system in our laboratory. World Tool Kit is anadvanced cross-platform development environment forreal-time 3D graphics simulation from EngineeringAnimation, Inc. The workstations are located in a dif-ferent LAN segment connecting via the Intranet. Fig-ure 9b and c describe the screen snapshot on eachparticipating user machine while working on the col-laborative work.

We set up the experiment to reflect the simulationresulting from non-contention and contention activities.Each activity is divided into three sampling periods,which contain five trials on each value, corresponding tothe frequent update event. We omit to count trafficconditions due to the Intranet connection, which isuncontrollable. It is also less significant compared to thenumber of LPs in the prototype which contains only twomachines. The locking times are measured by calculatingthe time from start sending the lock request message tillgetting the lock acknowledgement message. For non-

Fig. 9 Snapshot of prototype application. a Environment of collaborative work. b User A’s screen. c User B’s screen

13

contention activity, the participants are free to grab theobjects and put them on the workbench. The lockingtimes in each sampling period indicate minimum andmaximum time achievement when grabbing the acquiredobjects for all trials. Then, the average locking time iscalculated. The number of win indicates which partici-pating user can grab more objects. Table 1 expresses theresult from prototype experiment for non-contentioncase. For contention activity, the participants are as-signed to grab only the beam object simultaneously. Thelocking time is calculated in the same fashion as in thenon-contention case, but for only one object. In thiscase, the number of win indicates which participant canacquire the beam object. Tables 1 and 2 expresses theresult from prototype experiment for non-contentioncase.

The results give similar performance as performed bysimulation for both cases. This implies that the perfor-mance of compromised synchronization control mech-anism can be achieved for a small-scale level. Theaverage locking times for contention case may deviatefrom the value that we expect, i.e., 100–300 ms, ascompared with the simulation. However, the variation isonly a small number and is considered insignificant. Weobserve that one participating user, i.e., User B, canacquire the object more often than another. This comesfrom the exponential back off in multiple-lock checkingmechanism and probably the performance of O2 work-stations that cannot be perfectly similar.

6 Conclusion

This paper describes synchronization issues for theDVE system. The synchronization techniques andstandards are discussed relatively with the non-con-tention and contention activities for collaboration inthe DVE system. We present the compromised syn-chronization control mechanism that is composed of

the frequent update event and multiple-lock checkingmechanism. The frequent update event is used to pro-vide a dynamic virtual world, which is suitable tosupport the non-contention activity, as a soft syn-chronization. The multiple-lock checking mechanism isembedded to provide a consistent virtual world for thecontention activity, as a hard synchronization. Thesynchronization performance involves system, commu-nication, and network architectures. The presentedsynchronization architecture uses distributed serverlesswith peer-to-peer connection. There are three parame-ters relating the communications and network, i.e.,sampling period, number of logical processes, andtraffic condition that are used to evaluate the syn-chronization performance in terms of locking time. Thesimulation results imply that sending update eventfrequently, as well as the increasing number of logicalprocesses, decreases an available bandwidth on thenetwork. The increasing bandwidth by these twoparameters affects the synchronization performance interm of lengthily locking time and traffic tolerance tosupport the DVE application.

However, the effect gives a significant impact, onlythere is a large number of logical processes in thecontention activity. For the non-contention activity, themechanism can support a dynamic virtual world with-out holding for a long period for the scale up to 100participating users. That means the synchronizationcontrol mechanism can provide a good performance inthe non-contention case. For the contention activity ina small scale, the multiple-lock checking mechanism canprovide a consistent virtual world to ensure whichparticipant has the absolute ownership of the commonobject. As a result, the consistency-throughput tradeoffcan be balanced, or compromised. The prototypeimplementation using the compromised synchronizationis also carried out to reflect the collaborative activitiesfor a small scale. The outcome yields similar result as insimulation. It can be concluded that the compromisedsynchronization control mechanism is suitable for a

Table 1 Locking time for non-contention activity Sampling period (s) Locking time Number of win

Minimum (s) Maximum (s) Average (s) User A User B

1 0.047 0.082 0.058 1 42 0.032 0.073 0.041 2 33 0.033 0.065 0.040 2 3

Table 2 Locking time forcontention activity Sampling period (s) Locking time Number of win

Minimum (s) Maximum (s) Average (s) User A User B

1 0.352 0.437 0.371 2 32 0.263 0.385 0.314 1 43 0.218 0.319 0.293 1 4

14

small scale where contention activity is consideredcritical as well. It might be applicable to a large scalewhere persistent contention is required. We areresearching to include the compromised synchroniza-tion in a haptic force feedback (HFF) collaborativeapplication and the multimodal synchronization in theDVE system. We, also, look forward to extend theimplementation to a larger scale, if our laboratory re-sources permit. It is our hope that the mechanisms usedin the compromised synchronization will be applicableto the current generic synchronization techniques andstandards, such as high level architecture (HLA) andothers, for contention activity in the future.

Acknowledgements The authors gratefully acknowledge for allcontributions and supports from Research Center for Communi-cations and Information Technology (ReCCIT), KMITL, JapanInternational Cooperation Agency (JICA), and Department ofInformation Media Technology, Tokai University.

References

1. Mastaglio TW, Callahan R (1995) A large-scale complex vir-tual environment for team training. Computer 28(7):49–56

2. Mastaglio TW (1994) Developing a large-scale distributedinteractive simulation system. In: Proceedings of the wintersimulation conference, pp 770–774

3. Berglund EJ, Cheriton DR (1985) Amaze—a multiplayercomputer game. IEEE Software 2-1:30–39

4. Pearce C (1997) Beyond shoot your friends—a call to arms inthe battle against violence. In: Clark D (ed) Digital illusion.ACM Press, New York

5. Bible SR, Brutzman D, Zyda M (1995) Using spread spectrumranging techniques for position tracking in virtual environ-ment. In: Proceedings of Network Realities

6. Anupam V, Bajaj CL (1994) Shastra—multimedia collabora-tive design environment. IEEE Multimedia Summer 1(2):39–49

7. Ferscha A, Johnson J (1999) Distributed interaction in virtualspaces. In: Proceedings of the 3rd international workshop ondistributed interactive simulation and real-time applications.IEEE Computer Society Press, pp 5–13

8. Brutzman D (1995) Virtual world visualization for an auton-omous underwater vehicle. In: Proceedings of IEEE OceansConference, pp 1592–1600

9. Hagsand O (1996) Interactive multiuser VEs in DIVE system.IEEE Multimedia 3(1):30–39

10. Benford S, Bowers J, Fahlen LE, Greenhalgh C, Mariani J,Rodden T (1995) Networked virtual reality and collaborativework. Presence 4(4):364–368

11. Shaw C, Green M (1993) The MR Toolkit peer package andexperiment. In: Proceedings of IEEE virtual reality annualinternational symposium, pp 463–469

12. Lui JCS, Chan MF, Chan TF, Cheung WS, Kwong WW (1997)Virtual exploration and information retrieval system—designand implementation. In: Proceedings of the 3rd internationalworkshop multimedia information systems

13. Shirmohammadi S, Georganas ND (2000) Collaborating in 3Dvirtual environments—a synchronous architecture. In: Pro-ceedings of the 9th IEEE international workshops on enablingtechnologies: infrastructure for collaborative enterprises, pp35–42

14. Lui JCS (2001) Constructing communication subgraphs andderiving an optimal synchronization interval for distributedvirtual environment systems. IEEE Trans Knowl Data Eng13(5):778–792

15. Miller DC, Thorpe JA (1995) SIMNET—The advent of sim-ulator networking. Proc IEEE 83(8):1114–1123

16. Pullen JM, Wood DC (1995) Networking technology an DIS.Proc IEEE 83(8):1156–1167

17. Macedonia MR, Brutzman DP, Zyda MJ, Pratt DR, BarhamPT (1995) NPSNET—a multi-player 3D virtual environmentover the internet. In: Proceedings of ACM symposium oninteractive 3D graphics, pp 93–94

18. Das TK, Singh G, Mitchell A, Kumar PS, McGee M (1997)Developing social virtual worlds using NetEffect. In: Proceed-ings of the 6th workshop on enabling technologies: infra-structure for collaborative enterprises, pp 148–154

19. Das TK, Singh G, Mitchell A, Kumar PS, McGee K (1997)NetEffect—a network architecture for large scale multi uservirtual worlds. In: Proceedings of the ACM symposium onvirtual reality software and technology, pp 157–163

20. Vince J (1995) Virtual reality, systems. Addison-Wesley, Sin-gapore

21. Fujimoto RM (2000) Parallel and distributed simulation sys-tems. Wiley, New York

22. Singhal S, Zyda M (1999) Networked virtual environments,design and implementation. Addison-Wesley, New York

23. Oliveira JC, Shirmohammadi S, Georganas ND (1999) Dis-tributed virtual environment standards—a performance evalu-ation. In: Proceedings of the IEEE/ACM 3rd internationalworkshop on distributed interactive simulation and real timeapplications, pp 14–21

24. Churchill EF, Snowdon N, Munro JA (2002) Collaborativevirtual environment, digital places and spaces for interaction.Springer, Great Britain

25. Wang YM (1997) Consistent global checkpoints that contain agiven set of local checkpoints. IEEE Trans Comput 46(4):456–468

26. Lomow G, Das SR, Fujimoto RM (1991) Mechanisms for user-invoked retraction of events in time warp. ACM Trans ModelComput Simulation 1(3):219–243

27. Ghosh K, Fujimoto RM (1991) Parallel discrete event simula-tion using space-time memory. In: Proceedings of internationalconference on parallel processing, vol 3, pp 201–208

28. Cheung S, Loper M (1994) Synchronizing simulations in dis-tributed interactive simulation. In: Proceedings of the wintersimulation conference, pp 1316–1323

29. Wieland F, Hawley L (1989) Distributed Combat Simulationand Time Warp—the model and its performance. In: Pro-ceedings of SCS multiconference on distributed simulation, vol21, pp 14–20

30. Cai W, Lee FBS, Chen L (1999) An auto-adaptive dead reck-oning algorithm for distributed interactive simulation. Pro-ceedings of IEEE, pp 82–89

31. Pullen M (1999) Reliable multicast network transport for dis-tributed virtual simulation. In: Proceedings of IEEE workshopon distributed interactive simulations and real-time applica-tions, pp 59–66

32. Hofer RC, Loper ML (1995) DIS today. Proc IEEE83(8):1124–1137

33. Dahmann JS (1997) High level architecture for simulation. In:Proceedings of the IEEE/ACM 1st international workshop ondistributed interactive simulation and real time applications, pp9–14

34. Pullen M, Myjak M, Bouwens C (1999) Limitations ofinternet protocol suite for distributed simulation inlargemulticast environment. Request for Comments (RFC)2502

35. Shen X, Hage R, Georganas N (1999) Agent-aided collabora-tive virtual environments over HLA/RTI. In: Proceedings ofthe IEEE/ACM 3rd international workshop on distributedinteractive simulation and real time applications, pp 128–136

36. Nakamura N, Nemoto K, Shinohara K (1994) Distributedvirtual reality system for collaborative work. NEC Res Dev35(4):403–409

15

37. Anupam V, Bajai C, Schikore D, Schikore M (1994) Distrib-uted and collaborative visulization. Computer 27(7):37–43

38. Wongwirat O, Sathitwiriyawong C, Ohara S (2000) Optimisticsynchronization mechanism for distributed simulation appli-cations in shared virtual environment. In: Proceeding of the2000 Asia-Pacific symposium on broadcasting and communi-cations, pp 302–306

39. Wongwirat O, Sathitwiriyawong C, Ohara S (2001) Delay effectsimulation of multiple-lock checking algorithm for distributedshared virtual environment. In: Proceedings of EUROIMAGEinternational conference on augmented, virtual environments,and 3D imaging, pp 101–104

40. Wongwirat O, Sathitwiriyawong C, Ohara S (2001) Perfor-mance evaluation of traffic congestion for multiple-lockchecking algorithm in distributed share virtual environmentapplications. In: Proceedings of IEEE Region10 internationalconference on electrical and electronic technology, pp 129–132

41. Bondavalli A, Gregori E (1989) Concurrency control in OSItransactional environments. In: Network information process-ing systems. Elsevier Science, North-Holland

42. Effect of propagation delays on communication quality.International Telecommunications Union, RecommendationITU SG12, delayed contribution 44, 1990

16