NetEffect: A Network Architecture for
Large-scale Multi-user Virtual Worlds
Tabas IS. Das, Gurminder Singh, Alex Mitchell, P Senthil Kumar, Kevin McGee
Institute of SystemsScience
National University of Singapore
Kent Ridge, Singapore 119597
Email: [email protected]
http://www.iss.nus.sg/RNDWHistoryCity
Abstract
server depending on the user’s choice on community. When a
user wants’ to change community, he is connectedto the new
server handling that community and disconnectedfrom the old
server. At any point of time, all users of a community are
connectedto the same server. Therefore users’ interaction with
the virtual world do not generate any inter-server network
We describe NetEffect, a highly-scalable architecture for
developing, supporting and managing large, media-rich, 3D
virtual worlds used by several thousand geographically
dispersed users using low-end computers (PCs) and modems.
NetEffect partitions a whole virtual world into communities,
allocates these communities among a set of servers, and
migrates clients from one server to another as clients move
through the communities. It devotes special attention to
minimizing the network traffic, in particular, the traftic that
must go through servers. HistoryCity, a virtual world for
children, has beendevelopedon NetEffect and is currently being
beta-testedfor deployment in Singapore.
tlilflk.
1.2 Need-to-Know Updating
NetEffect allows us to create a proper place-hierarchy for a
community. When users are outside a building, they do not need
to know about any update of objects inside the building. When
usersenter the building, they get object updatesfrom the server.
We call this technique need-to-know updating, since it defines
the scope of a user within a smaller area (building or room)
within a community. A server sends updates to a user only for
those objects in the place where the user is located. Thus needr&now updating can reducenetwork traffic significantly.
Key Words: Networked Virtual Reality, Client-Server Model,
Group Dead Reckoning, Distributed Interactive Simulation.
1. Introduction
1.3 Group Dead-Reckoning
We use the group deud-reckoning technique [Singh & Das,
19961in updating the movement and position information of all
available users in the same community. It doesn’t involve any
inter-server communication, which reduces network traffic
tremendously.
Handling a large number of simultaneous users is one of the
biggest challenges in current researchin the area of Networked
Virtual Reality. There are two major reasonsfor this: limitations
of network bandwidth and computational resourcesof network
entity. As a result, there are currently few systemswhich can
support large numbersof users with satisfactoryperformanceof
the network and associatedvirtual worlds.
The NetEffect architecture is designed to address these
limitations of network bandwidth and computational resources
by reducing inter-server communication and by making the
architecture scalable. This paper highlights six key techniques
which allow us to achieve our goal of supporting several
hundred simultaneoususers.
1.4 Point-to-point Connection
/
HistoryCity supports point-to-point ‘voice chat. The voice
data does not go through the servers as this is achieved by
opening a direct connection between two users. This point-topoint connectionminimizes load on the server.
1.5 Extensibility
This architecture is very extensible due to the fact that servers
are very loosely-coupled. We can extend our virtual world by
adding more and more communities with new servers without
affecting existing worlds. Moreover servers can be programmed
to provide application specific support. This extensible
architecture provides flexibility in increasing a system’s
computationalresources.
1.1 Partitioning and Client Migration
We partition the virtual world into many communities which are
distributed over multiple servers. A server can handle one or
more communities. A user can establish a connection to any
Permission to make digital/hard copies of all or part of this material for
personal or classroom use is granted without fee provided that the copies
;LTenot made or distributes for profit or commercial advantage, the COPYr$bt notice, the title ofthe publication and its date appear. ‘andnotice is
&a that copyright is by permission ofthe ACM, Inc. To copy otherwise,
to republish, to post on servers or to redistribute to lists, requires specific
permission andlor fee
ACM
1.6 Dynamic Load Balancing
NetEffect provides a load balancing technique which creates a
uniform distribution of user density over the servers.If there are
E%YT‘97 Lausanne Switzerland
Copyri&t 1997 ACM 0-89791-953+/97/9..$3.50
157
II. .:*;-....‘.._\“,Lg:,,.~..;.
i.’ I.. ., ,.__..L<_
,...._. . I
___..
-----
too many communities for available servers, it is possible for
one server to handle multiple communities. In that case, the
systemperiodically checks ddnsity of users at all communities
and at all servers. To balance load among all the servers, the
system dynamically transfers some communities from heavily
loaded servers to ones with less load. Dynamic load balancing
optimizes the performance of a network of computational
resources.
The rest of this paper describes the major features of
HistoryCity, a distributed environment developed using the
NetEffect architecture, highlights the merits and demerits of
NetEffect, and compares it with other systems. Finally it
discussesfnture work and enhancements.
2. A Sample Application - HistoryCity
We have developed HistoryCity, a virtual community for
children ages 7 11, as a collaborative, distributed
environment that can support 500 simultaneous users. It is
implemented largely in Java and is intended for existing
communications hardware (28k m&em) using currently
available consumertechnology (Pentium 90 MHz PC or better).
The servers can run on Sun Ultra-Spare workstations, or
Pentium Pro workstations running WindowsNT, communicating
with clients using TCPLIPover Internet.
elements are animated objects with associated sound-effects.
Small groups of users can interact in each personal room,
dynamically modifying these elements by adding, removing,
rearranging, or activating them. Participants can interact with
each other using point-to-point speechor traditional text-chat.
HistoryCity also contains several different types of agents:
story-tellers, reporters, poets, jokers, writers, pawn-brokers,
messengers,and a governor.The story-teller allows usersto read
stories, many of which are basedon the history, legends, fables,
and folk tales of Singapore.Similarly, the poet tells poems,the
reporter-providesHistoryCity news (a mix of historical and usercreated), and the joker presents jokes. Users submit stories,
poems,jokes, and news items of their own through the writer.
These are collected each day, added to the appropriate
databases,and made available as part of the agents’ repertoires
the folIowing day.
Pawn-brokersallow players to trade objects with the system.
Messengers allow users to locate each other; by sending a
messenger to locate another user, individuals can determine
where their friends are, whether they are online, or even
whether they are citizens of HistoryCity. The governor provides
users with a set of guidelines for appropriate behavior in
HistoryCity.
The agents in HistoryCity are static models. In the
community description obtained from server, agentsarc defined
as a special type of object. When a user interacts with an agent,
the client knows from the object type that the selectedobject is a
joker, story-teller, or other type of agent. Accordingly the client
requestsarticles from the server for that agent.
HistoryCity is designed to function as a historically-based
virtual community. In the following section we describe the
NetEffect architecture, and discuss how it was used to develop
HistoryCity.
3. HistoryCity
Figure 1: A sample screen from Commercial Square
community where
environment.
users
can see one another
in
the
Residents of HistoryCity explore, and live in, a virtual
Singaporeof 1870, completewith historical buildings, costumes,
’ and objects.At present there are 24 communities in HistoryCity,
each of them have several clubhouses. When users firs1 join
HistoryCity, they select avatars as their representations. and
these become the “bodies” that other users see. Currently
HistoryCity provides around 200 different avatars. A sample
screen of one of the communities is shown in Figure 1. When
usersbecomeclub members,they are given a PersonaIPageand
a Personal Room (with a Personal Theatre). Users can collect
objects from the environment and from other users, and create
interactive theatre pieces in their personal rooms. Theatrc
158
Architecture:
NetEffect
HistoryCity has been developedusing the NetEffect architecture.
NetEffect is a highly scalable client-server architecture where a
master server (MS) and n peer servers (PS) form the network
[see figure 21.Each server maintains a complete graph topology,
which allows the serversto communicatewithout going through
intermediary servers.A client is connectedto only one server at
any time. but can dynamically migrate from one server to
another. AI1 network entities (MS, PS and client) communicntc
with one anotherusing the TCP/IP connection oriented protocol.
The entire virtual world is divided into several communities
which are managedby peer servers. A peer server maintains
the database for its communities and handles its clients’
requests.A peer server also communicateswith other servers,if
necessary, but the inter-server communication has been
minimized in this architecture in order to reduce network traffic.
There is a bottleneck on how many users can be supported by
one such peer server for reasonableperformance.However, the
system can have many such peer servers,so the total number of
supportedusers can be large. HistoryCity has a total of 25 peer
servers,1 for eachcommunity and 1 news server.
,
Figure 2. Overview of N&Effect architecture. One master
server M and 3 peer servers SI, S2 and S3 are taking care of
their clients. SI manages Coml, SZ manages Corn2 and S3
manages Com3. All servers know which community is
handled by which server.
When a peer server starts up, it first connectsto the master
server which assignsan identity to the peer server. The master
server also takes care of initial connection and distribution of
clients, and maintains each user’s personal database. &I
HistoryCity, the personal database includes the user’s log-in
information, avatar description and inventory. When a user
leaves HistoryCity, their personal database is saved at the
masterserver through their peer server. At next log-in, the client
getspersonalinformation from the masterserver.
When usersjoin the world, their clients are connectedto the
master server first. The master server decides the starting
community for the client and instructs the client to connect to
that community-server. This decision about which community
the client is connected to may vary from application to
application depending on game logic. In HistoryCity, this
decision is made on the basis of the user’s location when they
last exited. However, if the master server finds that the desired
community-server is overcrowded, it locates the user at the
nearest community that is not overloaded, where nearest is
defmedin termsof the geographyof the virtual world.
After connecting to a community server, a client gets a
community description from a peer server, and constructsthe 3D
world. Users can then start navigating and can use portals to go
to other communities.
3.1 Network Connec&ity and Addressing
In this section, we explain the network connectivity and the
addressingmechanism for the communities and users. Before
the master server (MS) starts up, an initial setup is created by
the network operator, indicating how many peer servers (PS)
need to be started and which peer server will handle which
community. For example, S1 handles Corn], S2 handles Corn2
etc. When the master server is started up, it reads this initial
setup and creates a community allocation table. When a peer
server is started it connectsto the master server, which assigns
an identity to that PS (e.g. S1,S2)and sendsthe identity and the
community allocation table to the peer server. On the basis of
159
this community allocation table, the peer server initializes its
community database. Subsequently if any community is
migrated from one server to another, the master server updates
all the peer servers, which update their community databases
[for details, refer @Dynamic Load Balancing below].
The master server listens to two ports: one to accept
connections from peer servers and the other to accept
connections from users. The host addressof the master server
and the port number which acceptspeer servers are specified in
the peer server configuration file. When a peer server is started,
it readsthe configuration file, gets the master server addressand
connectsto the masterserver at the specified port.
Each peer server also listens to two different ports: one to
accept connections from other peer servers and the other to
acceptconnectionsfrom users. When a peer server is started it
connects to the master server, which broadcasts information
about the new peer server to all existing peer servers. The
existing peer servers connect to this new peer server. Thus a
complete network is achieved among the master and peer
servers.
After connecting to the master server, the peer server sends
the MS the host addressand the two port numbers at which the
peer server is listening. Thus the master server knows all the
port numbers and host addressesof all the peer servers. When
the masterserver informs other existing peer serversthat a new
peer server has joined, the master server sends new server’s
identity, host address,and the two port numbers at which the
peer server is listening. Thus the existing peer serversknow the
addressof any new peer server joining the network. When an
existing peer server connectsto a new peer server, the existing
PS sends its own host name and two port numbers. Thus the
new peer server knows all existing peer servers’ host address
and port information.
pi user only needs to know. the master server’s host address
and the port number. This information is stored in the client’s
configuration file. When a client connectsto the master server,
the MS decidesthe starting community and peer server. The MS
sendsback the host addressand port number of the peer server
to the client. Then the client closes the connection with the MS
and opens a new connection to the peer server at the specified
host and port. To migrate to another peer server, the client gets
the host addressand port number of the new PS from its current
peer server [For details, refer to Partitioning and Client
Migration below].
3.2 Partitioning and Client Migration
All servers have basic knowledge of the entire network
configuration. A server knows which community is managedby
which server. When users want to change communities, their
clients need to migrate to the peer server which handles the new
community. Consider a situation where a user wants to go from
CoJnJ t0 cOtn2.
The
&eIIt
first
sendsa rqUeSt
t0 itS peer server
SI to change wmmunity. Peer server S1 checks the load
condition of peer server S2 who is handling Com2. Load is
calculated basedon the number of clients connectedto the peer
server. If acceptable,peer server SI sends the Ip addressa3d
port information of SZ to the client with the reconnect
permission message.The client first connectsto server 5%.and
then closes the connection to SI. Subsequently SZhandles the
client’s requests. Figure 3 shows the steps for changing server
by a client.
If peer server SI finds that SZis overcrowded, or SZis not
available in the network, it informs the client with the
appropriatemessage.
r
(5)EstablishcormtoS2
(6)Clae connection
toS1
In this method, when a user moves from one plncc to
another, the client gets object updates from the server for the
new place. Tbe server broadcastsupdates of an object only to
those clients that are currently located in that particular plnce.
When the world contains many buildings, rooms, indoor and
outdoor scenes, this technique can reduce network traffic
significantly.
In the need-to-know upduring technique, the place hierarchy
is predetermined. It is input explicit by the environment
designerwhen the community is modelled.
(4)SendIP i”)for new
Reqforobjeds
community
3.4 Group Dead-Reckoning
technique was described in our
earlier paper [Singh & Das, 1996]. Here “group” refers to the
list of usersconnectedto a peer server. This technique is used to
eliminate sending messageseach time a user moves. Users send
their positions to their server at regular intervals. Instead of
broadcastingthe position of each individual user to the whole
group, the peer server accumulatesposition updates from each
player and broadcastsone big packet at regular intervals to the
whole group [seefigure 51.
The group dead-reckoning
Loadstatussending(3)
Figure 3. Steps involved when a client changes communities.
After reconnectingto the new peer server, the client requests
the community description from the peer server. Once it receives
the community description, it loads the scene.The entire process
of getting the description and loading the scenemay take several
secondsto a minute. But we have observed that this waiting
time is mostly due to loading of the scene at the client’s local
machine.The waiting time varies from community to community
depending on the complexity of the scene.However, getting the
community description from the server is almost immediate,
even though the servermay be supporting many users.
3.3 Need-to-Know Updating
A peer Ferver maintains the database for one or more
communities.When a user enters a community, the client needs
to get the community description from the server. If the entire
community databaseis sent at one time, the network packet size
could potentially make processing of those objects
computationally expensive. Moreover, all updates must be
broadcastto all userspresent in the community, which generates
a lot of network traffic.
To solve this problem, we have adopteda technique we call
need-to-know updating. A community can have a proper place
hierarchy. For example, a community has building 1 & 7-, and
building 1 has a room inside [see figure 41. When the user is
outside any building, he doesnot need any updatesfor the inside
of the buildings. Similarly when a user is inside the room, he
does not need to have any knowledge of the outside world and
people.
community
Building1
PositionOrientation Velocity
Figure 5. Format of Group Dead-Reckoning updatepacket.
This packet contains each user’s current position and
velocity vector. On receiving this packet, a user updntcs the
position of its group members.From then on, the client uses the
velocity vector to predict the position of individual players, until
the next packet is received. Group dead-reckoning used in this
environment has two main effects:
l
l
it reducesthe number of updatessent by a user
it reducesfurther number of updatessent by the server to its
group.
In the NetEffect architecture, there are two ways of forming
a group. In the first method, all users available in a community
can be included in the group dead-reckoning packet. This
involves less computation for peer server, but the client needsto
process all users’ position information which involves more
computation.In the secondmethod, peer server can include only
those users located in the same building or room as the user.
This involves more computationby the peer server.
In HistoryCity we use the first method, which involves less
computation by the peer server, becausewe want to reduce its
load so that it can handle a large number of simultaneous users.
This doesnot have a significant impact on the client since nccdto-know upduting has already filtered out extra object
information. It is also useful for the client to have position
information about all users to let the system provide fentures
such as an overview map with live position updates.
3.5 Point-to-Point Connection
Vuice communication plays a very important role in n
collaborative virtual environment. However, the problem with
Figure 4: Example of place hierarchy in a community.
160
1
1
I
I
voice ammunication is that it generatesa lot of network traffic.
The most effective way of exchanging voice data packets
betweentwo users is to open a direct connection between them.
since this technique does not cause any additional load on the
server. When a user wants to talk to another user, he sends an
audiorequest to his peer server, which locates the oihcr
user first and tells him to accept the audioChat request. The
sourceuser gets back the IP addressand port information of the
target user. Then the sourceuser opens a socket and connectsto
the target user. The target user acts as a server, whereas the
sourceuser acts as a client in audiochaf.
the load on a particular server exceedsa certain lit,
serverinitiates load balancing.
(3) com, reallocated
@a)Databue transfer
complete
(1)
Migrate
(3)
corn,to sz
r_I
MasterServer
Sl
a
I
‘, (5a) Opennew
(2)
Transfer. *
Corn,database:
s
UL,
P-
Locateuser tl
the master
connedion
.
(4) Rmnn- to St Clientsof copn,
(5) Closeconnedionto Sl
Ip etc.info
(3) UserCZ’scommunity,
Figure 7. Community
&rver S1 to SZ.
(7)Connectlo C,
Figure 6. Client Cl at St is connecting to client C2 at SZ for
audio chat. If Cl and C2 are both at the same server Sl, steps
(2), (3), (4) are not necessary.
Jn HistoryCity, we use the GSM compressiontechnique to
compress audio data in order to reduce the bandwidth
requirement. The initial connectionprocedureis shown in figure
6.
3.6 Extensibility
The architeciure is very extensible due to the fact that servers
are very loosely-coupled. When we extend our virtual world by
adding communities, starting up new servers has minimal
impact on the existing world.
Depending on the game play, peer servers can also be
programmedto provide g&e specific support..In Histoflity,
one of the peer serversis configured as.anews server. The news
server does not have any users; it collects all articles submitted
by all usersfrom all communities. Articles from usersare sent to
each user’s peer server, which then passesthe articles to the
news server. The news server compiles articles at midnight, and
after an administrator has determined suitability for posting,
published newspapersare dishibuted to all peer servers.
In a similar way, peer servers can be programmedto act as
chat servers, media servers etc. Thus our architecture can be
extendedto include serverswith various types of functionality.
3.7 Dynamic Load Balancing
When servers manage more than one community, there is a
possibility that some servers will becomeoverloadedwhile other
servers may be idle. To balance load among the servers.
NetEffect dynamically transfers communities from heavily
loaded servers to ones with less load. The master server
periodically checksclient density at each community, and when
Corn1 is being migrated
from peer
For example, community Coml needs to be migrated from
server SI to S2. The major stepsinvolved in this processare [see
figure 71:
1. Master server (M) sendsa messageto SI to transfer
community Corn1to S2
2. Peerserver S1sendscommunity Corn1databasetom
s2
3. Master server informs all peer serversabout reallocation of community CornI.
4. Peerserver S1broadcaststo all clients of Corn1to
. reconnectto SZ
5. Clients of community Corn1close their connection
with SI and open new connection to SZ
Thus communities are transferred dynamically fi-om one
server to another. There is a limitation in this community
migration process.While the migration is in progress,users are
prevented from modifying the world. Moreover, the time taken
to transfer the databaseis important. If the community database
is huge, it may take severalsecondson a slow network.
In HistoryCity, we determine the load on a server by
computing the total number of usersconnectedto it. However, it
may be possible that an environment where there are a large
number of static users generatesless load than an environment
with a smaller number of active users. In ‘this sense, the load
computation may not always be very accurate.It is possibly to
improve the load computation to take this inaccuracy into
account.
4. Related Work
Most existing networked virtual world systemscan support only
a handful of simultaneous users. SIMNJZT[Calvin et al., 19931,
NPSNET [Macedonia et al., 1995a&b] and RING punkhouser,
19M] are clearly in a different class when it comesto supporting
n%ber of users. SIMNET and its descendent,DIS (IEEE), can
support a few hundred users, whereasNPSNET is gearing up to
support more &an 1000 users. Instead of covering all important
networked virtual worlds, we will cover only SlMNET, DJS,
NPSNET, RING and Spline. Information on other interesting
networked virtual world systems can be found in VR-DECK
[Codella et al., 19931,DIVE [Carlsson & Hagsand, 1993a, &b],
EM [Wang, Green & Shaw, 199.551.
In SIMNET, all the virtual worlds consist of the sameset of
objects. The network model is object and event based, i.e.
objectsin the virtual world interact with eachother through a set
of defined events. Objects are autonomousin nature, i.e. any
changein any object is broadcastto all other worlds, regardless
whether they need the update or not. In order to reduce network
traffic, objects send information only about changes in their
statesor behavior. This reducesthe transmission(and reception)
of redundant information. Moreover, SlMNET supports the
dead-reckoning technique.
SIMNET has set a DIS standardwhich has been acceptedby
IEEE as the 1278 standard for distributed simulations. In the
DIS standard, the computers communicate via a network
protocol that consistsof a set of agreed-uponprotocol data units
(PDUs) and a set of rules for the exchangeof thesePDUs.
Unfortunately SIMNET, which was developedfor small unit
simulation, and its descendant,DIS, are currently not suitable
for large-scalemulti-player VES, This is becauseSIMNET and
DIS use broadcast for communication among virtual worlds,
which can quickly bog down virtual worlds with too many
network messages.
In order to solve this problem of scaling very large
distributed simulations, NPSNET [Macedonia et al., 1995b]
reduces network traffic by logically partitioning virtual
environments, associating spatial, temporal, and functionality
related entity classeswith network multicast groups.This solves
some of the problems with the existing DIS protocol, e.g.,
updating an entity, handing of static objects,distribute object on
demand.This exploits the actual characteristicsof the real-world
large-scale environments that are simulated by restricting any
entity’s processingand network resourcesto its area of interest
via a local Area of Interest Manager (AOIM). NetEffect follows
a similar approach. One of the major differences is that
NPSNET uses multicast protocol whereas NetEffect uses a
distributed server approach.NetEffect can filter out, or group,
network messages,which is not possible in NPSNET. Moreover
NetEffect includes the group deaLreckoning and need-to-know
updating techniques which can reduce network traffic
significantly.
SIMNET and NPSNET are designed for simulation
purposes.The contents of all their virtual worlds are the same.
This is not desirable for most applications as they may riced to
have differ&t objects for different worlds with sharedobjects.
RING [Funkhouser, 19951 supports interaction between a
large number of users in virtual environments with dense
occlusion (buildings, cities etc.). In RING, a state changein any
object is sent only to the small subset of worlds to which the
update is relevant. The state change is sent only to hosts
containing entities that can possibly perceive the change.Object
space visibility algorithms are used to compute the region of
influence for each state change. This reduces the number of
messagessignificantly if the virtual environments are deusely
occluded.Line-of-sight visibility is used to determine the region
of influence for each update. We can use the RING concept of
visibility within a community to improve the performance of
NetEffect further. The key problem is that each world needs to
162
calculate whether other worlds need this update or not, In order
to do this computation, RING uses a separate workstation
attachedwith eachclient.
WorldNet, the networking part of BrickNet [Singh et al,,
19941, uses a distributed server approach to reduce overall
network bandwidth. This is achievedby first identifying a group
whose updatesaffect one another and migrating these clients to
a commongroup server. This identification of a common group
may not always be easyor efficient. In the NetEffect architecture
there is no such problem, as users of a community are dwnys
connectedto the sameserver.
Spline [Mitsubishi Research]usesa centralized world model
to maintain the world database.It breaks the world mcxlel into
chunks called locales and communicatesinformation about n
locale only to thoseuserswho are interested in it. Spline servers
cache the current state of each locale, so that Spline processes
can obtain new locale information very quickly. This
architecture becomesa bottleneck when multiple users of all
locules modify their worlds, becausea huge amount of interserver network traffic is generated. In contrast, NetEffect
attemptsto minimize inter-server network traffic.
5. Conclusion
We have presentedNetEffect, a highly scalable architecture for
networked virtual worlds. There are several ideas behind this
architecture. The key idea is to partition the virtual world
geographically into communities and to distribute communities
over multiple peer servers. Users migrate to different peer
servers based on their community. Group dead-reckoning and
need-to-know upduhg further reducenetwork traffic.
The NetEffect architecture is highly effective for the class of
applications where the virtual world CM be partitioned into
smaller communities. Since these communities are distributed
over multiple Peer servers, and users are prevented from
gathering at a specific community, user-density is evenly
distributed. Thus supporting a large number of simultaneous
usersdependsmainly on the number of available peer servers.
The NetEffect architecture is not suitable for those
applications where the virtual world cannot be partitioned into
smaller communities. But this is a very rare case.
We have developed HistoryCity based on the NetEffcct
architecture. Our user environment is Pentium PCS,28.8 Kbps
modem and Internet. The HistoryCity virtual environments are
significantly large and complicated. Currently there are 24
communities. A client sends its position packet every 1 second
interval if it is not static, and server broadcastsgroup deadreckoning packetevery 1.5 secondinterval.
HistoryCity has been designed for 500 simultaneous users,
and is in the processof beta-testing. We believe the NetEffect
archifccture will scale up to support more than 500 users if we
add more communities and start more servers.
6. Future Work
The current version of NetEffect architecture has one master
server which maintains users’ personal dotabases.If the total
number of usersbecomesextremely large, the masterserver may
slow down a lot as the look-up time for the databaseincreases
significantly. This problem does not directly affect a user’s
world, because the user only communicates directly to the
master server at log-in. However, overall performance of the
masterserverwill degradeunder such circumstances.
A way to solve this problem is to repiicate the masterserver.
The user-databasecan be.divided under multiple masterservers,
which makes the architecture completely scalable. We plan to
implement this conceptin the next version of NetEffect.
7. Acknowledgment
Many people contributed in many ways to develop the NetEffect
architecture and HistoryCity. lhye Chean, Song Chuan, Murray,
Sizhen were fully involved in the technical implementation.
HistoryCity content was provided by Sonali, Karen, Patanjali,
Rosbe,Dmyar, PhuiLing, and many others.
8. References
[Calvin et al., 19931
Calvin, J., Dicken, A., Gaines, B., Metxger, P., Miller D.,
and Owen, D. (1993). The SJMNET Virtual World
Architecture. Proc. IEEE Virtual Reality Annual
International Symposium (VRAJS’93), Sept. 18-22.1993,
Seattle,Washington, USA, pp: 450455.
[Carlsson & Hagsand,1993a]
Carlsson, Christer, and Hagsand, Olof. (1993). DlVE - a
Multi-User Virtual Reality System. Proc. IEEE Virtual
Reality Annual International Symposium (VRAIS’93). Sept.
18-22,1993, Seattle,Washington, USA, pp: 394400.
[Carlsson& Hagsand,1993b]
Carlsson, Christer, and Hagsand, Olof. DIVE - A platform
for multi-user virtual environments. PergamonPress Ltd.,
Great Britain 1993,pp: 663-669.
[Codella et al., 19931
Codella, Christopher F., Jalili, Reza, Koved, Lawrence, and
Lewis, J. Bryan. A Toolkit for Developing Multi-user
Distributed Virtual Environments. IEEE Virtual Reality
Annual International Symposium (VRAIS’93), Sept 18-22,
1993,Seattle,Washington, USA, pp: 401-407.
~unkhouser, 19951
Funkhouser, Thomas A. RING: A Client-Server System for
Multi-user Virtual Environments. Symposiumon Interactive
3D Graphics,April 1995,Monterey, CA USA.
[Macedonia et al., 1995a]
Macedonia, Michael R., Zyda, Michael J., Pratt, David R.,
Barham, Paul T., and Zeswitz, Steven (1995). NPSNLT A
Network Software Architecture for Large Scale Virtual
Environments. Presence: Teleoperators and Virtual
Environments, MIT Press,Boston, 3(4).
macedontd et al., 1995bJ
Macedonia, Michael R., Zyda, Michael J., Pratt, David R..
163
--‘-r-
0..
F?RI
.A? .-..
L.
. . ..-
~--
Brutzman, Donald P., and Barham, Paul T. (1995).
Exploiting Reality with Multicast Groups: A Network
Architecture for Large scale Virtual Environments. IEEE
Virtual
Reality Annual International Symposium
(VRAIS’95). North Carolina, USA, Marcg 11-15, 1995,
pp:19-15.
[Mitsubishi Research]
Environment for learning, work and play (Research
Threads). A Mitsubishi Electric Research Laboratory.
http://www.merl.com.
FIorrison, 19951
Morrison, John. The VRLink
Networked Viial
Environment Software Infrastructure. Presence:Vol. 4, No.
2, Spring 1995, pp: 194-208. Massachusetts Institute of
Technology.
[Pratt et al.]
Pratt, David R., Locke, John, Macedonia, Michael, Zeswitz,
Steven R., Young, Roy David, and Zyda, Mike. NPSNETz
Ensuring world consistency in a shared Networked Virtual
Environment. Department of Computer Science, Naval
PostgraduateSchool.
[Shaw et al., 19931
Shaw, Chris, Green, Mark, Liang, Jiandong, and Sun,
Yunqi. Decoupled Simulation in Virtual Reality with The
MR Toolkit, ACM Transactions on Information Systems11,
3 (July 1993).
[Shaw &Green, 19931
Shaw, Chris, and Green, Mark. (1993). The MR Toolkit
PeersPackageand Experiment. Proc. IEEE Virtual Reality
Annual International Symposium (VRAXS’93), Sept 18-22,
1993, Seattle,Washington, USA, pp: 463-469.
[Singh et al., 19941
Singh, Gurminder, Serra, Luis, Png, Willie, and Ng, Hem.
(1994). BrickNet: A Software Toolkit for Networks-Based
Virtual Worlds. Presence: Teleoperators and Virtual
Environments,MIT Press,Boston, 3(l), pp: 19-34.
[Singh & Das, 19961
Singh, Gunuinder, and Das, Tapas K (1996). Large Scale
Multi-User Virtual Worlds. Proc. JFIP’96 14* World
Computer Congress,2-6 Sept. 1996, Canberra,Australia.
[Wang, Green & Shaw, 19951
Wang, Qunjie, Green, Mark, and Shaw, Chris. (1995). EM
- An Environment Manager for Building Networked Virtual
Environments. IEEE Virtual Reality Annual International
Symposium (VRAIS’95), North Carolina, USA, March ll15.1995. pp: 11-18.
[Zyda, 19951
Zyda, Michael J. Networked Virtual Environments. IEEE
Virtual
Reality Aniiual Intermational Symposium
(VRAJS’95), North Carolina, USA, March 11-15, 1995, pp:
230-231.