Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Save to My Library
Look up keyword
Like this
1Activity
0 of .
Results for:
No results containing your search query
P. 1
S-CAN: Spatial Content Addressable Network for Networked Virtual Environments

S-CAN: Spatial Content Addressable Network for Networked Virtual Environments

Ratings: (0)|Views: 38 |Likes:
Published by ijcsis
Networked Virtual Environments (NVE) combines 3D graphics with networking to provide simulated environment for people across the globe. The availability of high speed networks and computer graphics hardware enables enormous number of users to connect and interact with each other. In NVE each node (user or avatar) should be aware of the existence and modification of all its neighbors. Therefore, neighborhood consistency that is defined as ratio between node’s known and actual neighbors is a fundamental problem of NVE and should be attained as high as possible. In this paper, we address the neighborhood consistency by introducing S-CAN, a spatial Peer-to-Peer (P2P) overlay that dynamically organizes nodes in NVE to preserve spatial locality of users in NVE. Consequently, node’s neighborhood will always maintain node’s direct neighbors and hence node will be aware of other users and events within its visibility that is called node’s Area-of-Interest.
Networked Virtual Environments (NVE) combines 3D graphics with networking to provide simulated environment for people across the globe. The availability of high speed networks and computer graphics hardware enables enormous number of users to connect and interact with each other. In NVE each node (user or avatar) should be aware of the existence and modification of all its neighbors. Therefore, neighborhood consistency that is defined as ratio between node’s known and actual neighbors is a fundamental problem of NVE and should be attained as high as possible. In this paper, we address the neighborhood consistency by introducing S-CAN, a spatial Peer-to-Peer (P2P) overlay that dynamically organizes nodes in NVE to preserve spatial locality of users in NVE. Consequently, node’s neighborhood will always maintain node’s direct neighbors and hence node will be aware of other users and events within its visibility that is called node’s Area-of-Interest.

More info:

Published by: ijcsis on Nov 02, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

11/02/2010

pdf

text

original

 
(IJCSIS) International Journal of Computer Science and Information Security,Vol. 8, No. 7, October 2010
S-CAN: Spatial Content Addressable Network forNetworked Virtual Environments
Amira Soliman, Walaa M. Sheta
Informatics Research InstituteMubarak City for Scientific Research and Technology ApplicationsAlexandria, Egypt.{a.soliman, wsheta}@mucsat.sci.eg
 
 Abstract
Networked Virtual Environments (NVE) combines 3Dgraphics with networking to provide simulated environment forpeople across the globe. The availability of high speed networksand computer graphics hardware enables enormous number of users to connect and interact with each other. In NVE each node(user or avatar) should be aware of the existence andmodification of all its neighbors. Therefore, neighborhoodconsistency that is defined as ratio between node’s known andactual neighbors is a fundamental problem of NVE and should beattained as high as possible. In this paper, we address theneighborhood consistency by introducing S-CAN, a spatial Peer-to-Peer (P2P) overlay that dynamically organizes nodes in NVEto preserve spatial locality of users in NVE. Consequently, node’sneighborhood will always maintain node’s direct neighbors andhence node will be aware of other users and events within itsvisibility that is called node’s Area-of-Interest.
 Keywords:
Networked Virtual Environments; Peer-to-PeerSystems; Interest Management.
I.
 
INTRODUCTIONNetworked virtual environment (NVE) [1, 2], also known asdistributed virtual environment, is an emerging discipline thatcombines the fields of computer graphics and computernetworks to allow many geographically distributed usersinteract simultaneously in a shared virtual environment. NVEsare synthetic worlds where each user assumes a virtual identity(called avatar) to interact with other human or computerplayers. Users may perform different actions such as movingto new locations, looking around at the surroundings, usingitems, or engaging in conversations and trades. Applications of NVE have evolved from military training simulation in the80’s to the massively multiplayer online games (MMOG) inthe 90’s [3, 4].In NVEs each user is interested in only a portion of the virtualworld called area-of-interest (AOI). All nodes in a node’s AOIare said to be its neighbors. AOI is a fundamental NVEconcept, as even though many users and events may exist inthe system, each user, as in the real world, is only affected bynearby users or events. AOI thus specifies a scope forinformation which the system should provide to each user. It isthus essential to manage communications between users topermit receiving of relevant messages (generated by otherusers) within their AOI as they move around [5, 6].As NVEs are shared environments, it is important that eachparticipant perceives the same states and events. Consistencyin NVEs usually refers to consistent object states and eventorderings [1], which are maintained through the transmissionof event messages. In this paper, we focus on neighborhoodconsistency or topology consistency, which can be defined asthe percentage of correctly known AOI neighbors. Forexample, a node that is aware of four out of five AOIneighbors, topology consistency is 80 percent [7]. Inclient/server NVE architectures, keeping high neighborhoodconsistency is trivial as all the user states are maintained by acentralized server. While, in P2P NVE, achievingneighborhood consistency is much harder as states aremaintained by participating nodes [6].Therefore, it is essential to dynamically organize P2P overlaynetwork with respect to users’ current positions in the virtualworld by having each user connected to the geographicallyclosest neighbors (users within AOI) [8]. In this paper weintroduce the architecture of Spatial Content AddressableNetwork (S-CAN) for NVE. Our design is based on Content-Addressable Network (CAN) [9] for constructing P2P overlay.CAN design centers around a virtual
-dimensional Cartesiancoordinate space. CAN coordinate space is completely logicaland has no relation to any physical coordinate system.However, in our P2P overlay we associate physical coordinatesystem with CAN coordinate space. So, physical location of users and objects in virtual environments determines theircorrespondent location in CAN coordinate space. Theobjective of this mapping relation between physical and CANcoordinates is to preserve the spatial locality among users andobjects in NVE and hence attain user awareness.The rest of this paper is organized as follows. Section 2 givesbackground overview of related work and CAN network overlay. Section 3 introduces the adaptations proposed in S-CAN. Experiments are presented in Section 4 with metrics andscenarios. Results are presented and discussed in Section 5.Conclusion and future work are given in Section 6.II.
 
BACKGROUND
 A.
 
 Related Work 
Various techniques have been proposed to address interestmanagement in NVE. The earliest approached utilize multicastchannels, where Virtual Environment (VE) is divided intoregions and assign each region a multicast channel fornotification messages propagation. Each avatar can subscribeto the channels of the regions overlapped with its AOI.
32http://sites.google.com/site/ijcsis/ISSN 1947-5500
 
(IJCSIS) International Journal of Computer Science and Information Security,Vol. 8, No. 7, October 2010
NPSNET [10], VELVET [11] and SimMUD [12] areexamples of multicast NVE. However, this approach faces theinherent difficulty of determining the right region size. Since,too large regions deliver excessive messages to each avatar.While, small regions require many subscription requests andthus generate message overhead.Approaches with spatial multicast messages have beendeveloped to address the inadequacy of channel-basedmulticast. These approaches use Trees and Distributed HashTables (DHT) to store spatial relations among avatar andobjects in NVE. Examples include N-trees [13], Solipsis [14]and VON [6]. However, these approaches maintain anotherdata structure and protocol dedicated for interest managementrather than the protocol used to develop the network overlay.
 B.
 
Content-Addressable Network (CAN)
CAN introduces a novel approach for creating a scalableindexing mechanism in P2P environments. It creates a logical
d-
dimensional cartesian coordinate space divided into zones,where zones are partitioned or merged as result of node joining and departure. The entire coordinate space isdynamically partitioned among all the nodes in the systemsuch that every node “owns” its individual, distinct zonewithin the overall space. Fig. 1 shows a
2
-dimensionalcoordinate space partitioned between 5 nodes.
[ ] [ ]
1,01,0
×
This virtual coordinate space is used to store (key, value) pairsas follows: to store a pair (K
1
, V
1
), key K
1
is deterministicallymapped onto a point P in the coordinate space using a uniformhash function. The corresponding (K
1
, V
1
) pair is then storedat the node that owns the zone within which the point P lies.To retrieve an entry corresponding to key K
1
, any node canapply the same deterministic hash function to map K
1
ontopoint P and then retrieve the corresponding value from thepoint P. If the point P is not owned by the requesting node orits immediate neighbors, the request must be routed throughthe CAN infrastructure until it reaches the node in whose zoneP lies.
0.00.01.0
Figure 1.
2-d 
space with 5 nodes illustrating node’s virtual coordinate zone.
1) Node Join
:
 
The entire space is divided amongst the nodescurrently in the system. To allow the CAN to growallocated its own portion of the coordinate space. This is doneby an existing node splitting its allocated zone in half,retaining half and handing the other half to the new node. Theprocess takes four steps:1.
 
The new node
n
incrementally, a new node that joins the system must bemust find a node already in S-CAN2.
 
ing procedure, the join3.
 
hbors of the split zone must be notified4.
 
esponsibility for all the keys and
2) Routing
:
 
CAN nodes operate without global knowledge of pathand send join request to it.Next, using the S-CAN routrequest is forwarded to the nearest node whose zonewill be split.Then, the neigwith new node.Finally, move robjects data files that are positioned in zone handedto
n
.the plane. Each node maintains a routing table consists of theIP addresses and logical zones areas of its immediateneighbors. In a
-dimensional coordinate space, two nodes areneighbors if their coordinate spans overlap along
d–1
 dimensions and abut along one dimension. For example, in fig.1, node A is a neighbor of node B because its coordinate zoneoverlaps with A’s along the Y axis and abuts along the X-axis.On the other hand, node D is not a neighbor of node A becausetheir coordinate zones abut along both the X and Y axes.Routing in CAN works by following the straight linethrough the cartesian space from source to destinationcoordinates. Using its neighbor coordinate set, a node routes amessage towards its destination by simple forwarding to theneighbor with coordinates closest to the destinationcoordinates. As shown in [9], the average routing path lengthis (4
)(
n
1
) hops and individual nodes maintain
×
2neigrs., the number of nodes (and hence zones) inetwork can grow without an increasing per-node-state, whilethe path length grows with
O(
hbo Thusn the
n
1
).3) Node Departure:
 
When nodes leave CAN, the zones theyAs previesign ooccupy must be taken over by the remaining nodes. Thenormal procedure for node leaving is to explicitly hand overits zone and associated (key, value) database to one of itsneighbors. If the zone of one of the neighbors can be mergingwith the departing node’s zone to produce a valid single zone,then this is done. The produced zone must have a regularshape that permits further splitting in two equal parts. If mergefails, the zone is handed to the neighbor whose current zone isthe smallest, and that node will temporarily handle both zones.
 
III.
 
THE PROPOSED OVERLAY S-CANously mentioned, our work leverages the dCAN to support user awareness in NVEs. CAN constructs apure logical coordinate plane to uniformly distribute dataobjects. In S-CAN, we use this characteristic to extend thelogical plane with physical spatial meaning for distributingdata objects based on spatial information. Furthermore,because user’s AOI is often based on geographic proximity,we dynamically reorganize the network overlay with respect to
C
(0.0-0.5, 0.5-1.0)
A
(0.0-0.5, 0.0-0.5)
B
(0.5-1.0, 0.0-0.5)
D E
(0.5-0.75, 0.5-1.0)(0.75-1.0, 0.5-1.0)
1.0
33http://sites.google.com/site/ijcsis/ISSN 1947-5500
 
(IJCSIS) International Journal of Computer Science and Information Security,Vol. 8, No. 7, October 2010
users’ current positions in the VE. Therefore, as users moveinside VE, the coordinates of their assigned zones andneighborhood map will be changed to reflect their currentpositions. In section (A) we illustrate the overlay adaptationprocess. Next, in section (B) we present the stabilizationprocedure.
 A.
 
Overlay Construction
te space into zones according toata
{Direction ,eID , ZoneBoundary [ ] [ ]}}
DirectioNorth,two types of gorithm (1)movement processing and trying to hand over its zone.S-CAN divides the coordinanumber of nodes and their locations. Moreover, each nodemaintains a routing table (called neighbor map) that storesadjacent neighbors with their associated zones. Node’s avatarmoves freely as long as it is still located within nodeassociated zone. In case of any movement outside zonecoordinates, node has to change its location in network overlay(which means that node moves within network overlay). Thisnode movement will be done by performing node departurethen rejoin according to avatar new location. Therefore, whennode changes its location, its associated zone will be changedand new AOI neighbors will be stored in its routing table.Each node maintains a neighbor map of the following dstructure:
 HashMap HashMap {Nod 
n takes a single value from {“East”, “West”, ““South”}. Where, ZoneBoundary is a
2-d 
array storing valuesof start and end in x and y direction respectively.In our proposed overlay, we differentiate betweenneighborhood based on number of neighbors sharing the sameborder line. In the first type, there is only one neighbor sharingall border line, where, in type two there are more than oneneighbor. In order to determine neighborhood type, there aretwo methods developed to calculate overlap direction betweenzones. The first method is overlapAllBoundary that returnsdirection where zones share from start to end for example as infig. 1, calling overlapAllBoundary between zones of nodes Aand B returns “East” as node B is in east direction of node A.If we call the method with modes reversed (that is B then A),it will return direction “West”. While, the second methodoverlapPartBoundary returns the direction where two zoneshare a part from it. In fig. 1, there is overlapPartBoundarybetween nodes B and D in “North” direction.After avatar’s movement, node performs almentioned below. First, it compares avatar new position withthe boundary of the current associated zone. If the newposition is out of zone boundary (line 3), it searches within itsneighbors to find a neighbor with a valid zone to merge (lines4:11). We use overlapAllBoundary method (line 5) in order toverify generating a regular zone shape at the end of mergeprocess. When finding a matched neighbor, a merge requestwill be sent to it and node freezes till a response is received.The received merge response indicates whether merge processsucceeds or fails. Neighbor rejects merge request as it iscurrently executing a process that is going to change itsassociated zone like splitting for new joined node, or in
Algorithm1.
Avatar movement process(posX, posY)1: /*psoX is the new user’s X coordinate*/ 2: /*psoY is the new user’s Y coordinate*/ 3:
if 
not inMyZone(posX, posY)
then
4:
for
each neighbor N
myNeighbors
do
 ne)
do
ed()
do
UnallocatedZone(zone)5:
if 
overlapAllBoundary(zone, N.zo6: sendMerge(zone, N)7:
if 
mergeSucced()
do
e8:
break
9:
end if 
10:
end if 
 11:
end for
12:
if not
mergeSucce13:
 
sendAdd14:
end if 
15: join(posX, posY)16:
end if 
 
Srge took place, the node sends a joinrone of its oldest neighbors existing in its moverocess performed in case of mergeensure that theirare taken by the remaining nodes.rged with one of the old zones inthe coordinates of one of theubsequently, after meequest todirection (line 15). Then, a join request will be forwarded tillreaching the node that will accept and split its zone with therequesting node. Furthermore, the node that performs mergewill be responsible for notifying overlapped neighbors withthe change happened. So that, it will forward two messages tooverlapped neighbors, the first indicates its new zonecoordinates, while the second message notifies neighbors todelete the departed node.However, not all merge requests succeed, so in the nextsection we illustrate the pfailure and coordinate stabilization process.B.
 
Stabilization
 
When nodes move in S-CAN, we need toassociated zonesNevertheless, the merge process succeeds only when the zoneof one of the neighbors can be merged with the moved node’szone to produce a valid single zone. If not, the zone is declaredas an unallocated zone and handed to a specific node that isresponsible for managing unallocated zones. This node isknown as Rendezvous node. Rendezvous node serves as abootstrap node in its region. It is a static node and is launchedwith the system start. This node maintains two lists, one forstoring the unallocated zones and the other for listing theavatars located in its region.When a new unallocated zone is received, Rendezvous nodeverifies if this zone can be meorder to minimize scattering in the coordinate space. It iterateson the existing zones and uses the overlapAllBoundaryfunction to check if there is any overlap as shown in algorithm(2). If merge can be made, it removes the old zone and addsthe new merged one to the unallocatedZones list (lines 3:10).Otherwise, add the zone will be added to the list of unallocatedZones (lines 11:13).When Rendezvous node receives a join request, it first verifiesif requesting node position lies inunallocated zones. If so, it sends the reply with the unallocatedzone coordinates. Then, in order to let the new joined node
34http://sites.google.com/site/ijcsis/ISSN 1947-5500

You're Reading a Free Preview

Download
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->