Enhancing Neighborship Consistency for Peer-to-Peer Distributed Virtual Environments

  • Published on
    01-Jan-2016

  • View
    31

  • Download
    3

DESCRIPTION

Enhancing Neighborship Consistency for Peer-to-Peer Distributed Virtual Environments. Jehn-Ruey Jiang, Jiun-Shiang Chiou and Shun-Yun Hu Department of Computer Science and Information Engineering National Central University. Outline. Introduction Background P2P DVEs - PowerPoint PPT Presentation

Transcript

  • Enhancing Neighborship Consistency for Peer-to-PeerDistributed Virtual EnvironmentsJehn-Ruey Jiang, Jiun-Shiang Chiou and Shun-Yun HuDepartment of Computer Science and Information EngineeringNational Central University

  • OutlineIntroductionBackgroundP2P DVEsFactors affecting Neighborship ConsistencyProposed SolutionsSimulation ResultsConclusion

  • OutlineIntroductionBackgroundP2P DVEsFactors affecting Neighborship ConsistencyProposed SolutionsSimulation ResultsConclusion

  • DVE (1)Distributed Virtual Environments (DVEs) are computer-generated virtual world where multiple geographically distributed users can assume virtual representatives (or avatars) to concurrently interact with each other A.K.A. Networked Virtual Environments (NVEs)

  • DVE (2)Examples of DVEs include early DARPA SIMNET and DIS systems, as well as currently booming Massively Multiplayer Online Games (MMOGs).

  • Adaptive Computing and Networking Lab, CSIE, NCUMassively Multiplayer Online GamesMMOGs are growing quickly 8 million registered users for World of WarcraftOver 100,000 concurrent playersBillion-dollar business

  • Adaptive Computing and Networking Lab, CSIE, NCU

  • Adaptive Computing and Networking Lab, CSIE, NCU

  • Adaptive Computing and Networking Lab, CSIE, NCU

  • DVE (3)3D virtual world with People (avatar)ObjectsTerrainAgentsEach avatar can do a lot of operations MoveChatUsing items

  • Issues for DVEScalabilityTo accommodate as many as participantsConsistencyAll participants have the same view of object statesPersistencyAll contents (object states) in DVE need to exist persistentlyReliabilityNeed to tolerate H.W and S.W. failuresSecurityTo prevent cheating and to keep user information and game state confidentially.

  • Adaptive Computing and Networking Lab, CSIE, NCUThe Scalability Problem (1)Client-server: has inherent resource limitResource limit[Funkhouser95]

  • Adaptive Computing and Networking Lab, CSIE, NCUThe Scalability Problem (2)Peer-to-Peer: Use the clients resources Resource limit [Keller & Simon 2003]

  • Adaptive Computing and Networking Lab, CSIE, NCUYou only need to know some participants

    : self: neighborsArea of Interest (AOI)

  • Neighborship Consistency (1)

    Definition # current AOI neighbors observed # current AOI neighbors

  • Neighborship Consistency (2)An example :is observed neighborNeighborship Consistency= 4 / 5= 80% :is actual neighbor

  • OutlineIntroductionBackgroundP2P DVEsFactors affecting Neighborship ConsistencyProposed SolutionsSimulation ResultsConclusion

  • Related Work (1):DHT-based: SimMUDB. Knutsson, H. Lu, W. Xu and B. Hopkins, Peer-to-peer Support for Massively Multiplayer Games, in Proceedings of INFOCOM 2004. Authors are from Department of Computer and Information Science, University of Pennsylvania

  • Related Work (1):DHT-based: SimMUD[Knutsson et al. 2004] (UPenn)

    Pastry (DHT mapping) + Scribe (Multicast)

    Fixed-Sized Regions

    Coordinators

  • SimMUD -- IntroductionProposes use of P2P overlays to support Massively multiplayer games (MMG)

    Primary contribution of paper:Architectural (P2P for MMG)Evaluative

  • SimMUD -- IntroductionPASTRY(P2P overlay)SCRIBE(Multicast support)MMG GAME

  • SimMUD -- IntroductionPlayers contribute memory, CPU cycles and bandwidth for shared game statePersistent user state is centralizedExample: payment information, characterAllows central server to delegate to peers the dissemination and the process of intensive game states

  • Distributed Game DesignGAME STATES

    Game world divided into connected regions

    Regions are controlled by different coordinates

  • Distributed Game Design

  • Distributed Game DesignGame design based on fact that:Players have limited movement speedLimited sensing capabilityHence data shows temporal and spatial localitiesUse Interest ManagementLimit amount of state player has access to

  • Distributed Game DesignPlayers in same region form interest groupState updates relevant to group disseminated only within groupPlayer changes group when going from region to region

  • Distributed Game DesignGAME STATE CONSISTENCYMust be consistent among players in a regionBasic approach: employ coordinators to resolve update conflictsSplit game state management into three classes to handle update conflicts:Player stateObject stateThe Map

  • Distributed Game DesignPlayer stateSingle writer multiple readerPosition change is most common eventUse best effort multicast to players in same regionUse dead reckoning to handle loss or delay

  • Distributed Game DesignObject stateUse coordinator-based mechanism for shared objectsEach object assigned a coordinatorCoordinator resolves conflicting updates and keeps current value

  • Distributed Game DesignMapMaps are considered read-only because they remain unchanged during the game play.They can be created offline and inserted into the system dynamically.Dynamic map elements are handled as objects.

  • Game on P2P overlayMap game states to playersGroup players & objects by regionMap regions to peers using pastry KeyEach region is assigned IDLive Node with closest ID becomes coordinatorRandom Mapping reduces chance of coordinator becoming member of region (reduces cheating)Currently all objects in region coordinated by one NodeCould assign coordinator for each object

  • Game on P2P overlayShared state replicationLightweight primary- backup to handle failuresFailure detected using regular game eventsDynamically replicate coordinator when failure detectedKeep at least one replica at all timesUses property of P2P (route message with key K to node ID, say N , closest to K)

  • Game on P2P overlayShared state replication (contd..)The replica kept at M which is the next closest to key K If new node T added which is closer to K than coordinator NForwards messages to coordinator N until all states of K are transferred from N to TTakes over as coordinator and N becomes a replica

  • Game on P2P overlayCatastrophic failureBoth coordinator and replica deadProblem solved by cached information from nodes interested in the area

  • Experimental ResultsPrototype Implementation of SimMudUsed FreePastry (open source)Maximum simulation size constrained by memory to 4000 virtual nodesPlayers eat and fight every 20 secondsRemain in a region for 40 secondsPosition updates every 150 millisec by multicast

  • Experimental ResultsBase ResultsNo players join or leave300 seconds of game playAverage 10 players per regionLink between nodes have random delay of 3-100 ms to simulate network delay

  • Experimental Results(Base results)

  • Experimental Results(Base results)

  • Experimental Results(Base results)

  • Experimental Results(Base results)1000 to 4000 players with 100 to 400 regionsEach node receives 50 120 messages70 update messages per second10 players * 7 position updatesUnicast and multicast message take around 6 hops (but 50 hops in the worst case)

  • Experimental ResultsBreakdown of type of messages99% messages are position updatesRegion changes take most bandwidthMessage rate of object updates higher than player-player updatesObject updates multicast to regionObject update sent to replicaPlayer player interaction effects only players

  • Experimental ResultsEffect of Population GrowthAs long as average density remains same, population growth does not make differenceEffect of Population DensityRan with 1000 players , 25 regionsPosition updates increases linearly per nodeNon uniform player distribution hurts performance

  • Experimental ResultsThree ways to deal with population density problemAllow max number of players in regionDifferent regions have different sizeSystem dynamically repartitions regions with increasing players

  • Experimental ResultsEffect of message aggregationSince updates are multicast, aggregate them at rootPosition update aggregated from all players before transmitCuts bandwidth requirement by halfNodes receive less messages

  • Experimental Results

  • Experimental Results

  • Experimental ResultsEffect of network dynamicsNodes join and depart at regular intervalsSimulate one random node join and depart per secondPer-node failure rate of 0.06 per minuteAverage session length of 16.7 minutes (close to 18 minutes for a FPS game -- Half Life)Average message rate increased from 24.12 to 24.52

  • Related Work (2):Neighbor-list Exchange[Kawahara et al. 2004] (Univ. of Tokyo)

    Fully-distributedNearest-neighborsList exchange

    High transmissionOverlay partition

  • Related Work (3): Mutual Notification: Solipsis[Keller & Simon 2003] (France Telecomm R&D)

    Links with AOI neighborMutual cooperationInside convex hull

    Potentially slow discoveryInconsistent topology

  • Related Work (4): P2P Hybrid (DHT, super-nodes,neighbor list exchange: MOPARYu, A. and Vuong, S. T., MOPAR: a mobile peer-to-peer overlay architecture for interest management of massively multiplayer online games, In Proceedings of the international Workshop on Network and Operating Systems Support For Digital Audio and Video (Stevenson, Washington, USA, June 13 - 14, 2005). NOSSDAV '05.

  • Related Work (5): Voronoi-based Overlay Network : VONSY Hu, JF Chen, TH Chen, VON: a scalable peer-to-peer network for virtual environments, IEEE Network, 2006

  • Design GoalsObservation: for virtual environment applications, the contents we want are messages from AOI neighborsContent discovery is a neighbor discovery problem

    Solve the Neighbor Discovery Problem in a fully-distributed, message-efficient manner.

    Specific goals:Scalable Limit & minimize message trafficsResponsive Direct connection with AOI neighbors

  • Voronoi Diagram2D Plane partitioned into regions by sites, each region contains all the points closest to its siteNeighborsSiteRegion

  • Design ConceptsEach node constructs a Voronoi of its neighborsIdentify enclosing and boundary neighborsMutual collaboration in neighbor discoveryUse Voronoi to solve the neighbor discovery problem node i and the big circle is its AOI enclosing neighbors boundary neighbors both enclosing and boundary neighbors normal AOI neighbors irrelevant nodes

  • Procedure (JOIN)1)Joining node sends coordinates to any existing nodeJoin request is forwarded to acceptor2)Acceptor sends back its own neighbor listjoining node connects with other nodes on the listAcceptors regionJoining node

  • Procedure (MOVE)1)Positions sent to all neighbors, mark messages to B.N.B.N. checks for overlaps between movers AOI and its E.N.2)Connect to new nodes upon notification by B.N. Boundary neighborsNew neighbors

  • Procedure (LEAVE)1)Simply disconnect2)Others then update their Voronoinew B.N. is discovered via existing B.N.

    Leaving node (also a B.N.)New boundary neighbor

  • OutlineIntroductionBackgroundP2P DVEsFactors affecting Neighborship ConsistencyProposed SolutionsSimulation ResultsConclusion

  • Factors affecting Neighborship ConsistencyMobility Speed AOI-radius

    Node failurePossibly causes overlay partition

  • Mobility

  • Overlay Partition (1/2)Nodes divide into two or more groups

    Each group can not be aware each other

    May destroy neighborship consistency

    In pure P2P DVEMay be impossible to detect and recoverHave to avoid it

  • Overlay Partition (2/2)

  • OutlineIntroductionBackgroundP2P DVEsFactors affecting Neighborship ConsistencyProposed SolutionsSimulation ResultsConclusion

  • Proposed SolutionsAdaptive AOIAOI radius increases with speed increasing

    Detecting critical nodesCritical nodes are the nodes in some regions where the density is lowIt is used to avoid overlay partition

  • Adaptive AOI

  • Critical Nodes (1/4)

  • Critical Nodes (2/4)Periodically detect by node itself # AOI neighbors Neighbor_level = Average # AOI neighbors If a node detects that its neighbor level is lower than a pre-specified threshold, it regards itself as a critical node.A critical node will perform the backup operation to send to all connected neighbors the backup message.

  • Critical Nodes (3/4)A Backup messageSent by critical nodesContains a neighbor list of the critical node

    Stock neighbor listStores nodes from backup messageUses to periodically check

    Check operationCheck all nodes in its stock neighbor list periodicallyTo discovery missed neighbors

  • Critical Nodes (4/4)ABCNeighbor list of node AStock neighbor list of node ANeighbor list of node BBCC

  • OutlineIntroductionBackgroundP2P DVEs Factors affecting Neighborship ConsistencyProposed SolutionsSimulation ResultsConclusion

  • Simulation Parameters1000 nodesin a 1200-unit by 1200-unit planeconstant velocity of 5 units per time-stepAOI radius is 100 units (the number of directly connected neighbors is limited to be 20)Clustered distribution: nodes cluster into three groups in the first 300 steps and can move randomly after 300 steps.Random distribution: nodes can move randomly in all simulation steps.

  • Mobility (1/2)

  • Mobility (2/2)

  • Node Failure (1/8)

  • Node Failure (2/8)

  • Node Failure (3/8)

  • Node Failure (4/8)

  • Node Failure (5/8)

  • Node Failure (6/8)

  • Node Failure (7/8)

  • Node Failure (8/8)

  • OutlineIntroductionBackgroundP2P DVEsFactors affecting Neighborship ConsistencyProposed SolutionsSimulation ResultsConclusion

  • ConclusionAddress two factorsNode mobilityNode failure

    Improve neighborship consistency byAdaptive AOI bufferCritical node detection

  • Q&A

    ****Each node (user or avatar) in a DVE has and area of interest (AOI), which is usually a disk-shaped area centered on the node. All the nodes in a nodes AOI are said to be its neighbors. A node should be aware of the existence and variations of all its neighbors. Therefore, we should keep as high as possible the neighborship consistency, which is defined to be the ratio between known neighbors and actual neighbors. Low neighborship consistency may make a node miss some events within its AOI, which in turn may make the DVE work abnormally.

    a MUD (Multi-User Dungeon, Domain or Dimension) is a multi-player computer game that combines elements of role-playing games, hack and slash style computer games and social chat rooms. a MUD (Multi-User Dungeon, Domain or Dimension) is a multi-player computer game that combines elements of role-playing games, hack and slash style computer games and social chat rooms. Scribe [10] is a scalable application level multicast infrastructurebuilt on top of Pastry. Group member management in Scribe is decentralizedand highly efficient because it leverages the existing Pastryoverlay. Scribe can efficiently support large numbers of groups,arbitrary numbers of group members, and groups with highlydynamic membership.

    PERFORMANCEFrequent game updates,Time constraints,Limited peer bandwidth

    AVAILABILITYReplicate game statesReplica invalid when peer goes offlineHigh update frequency causes performance bottleneck

    SECURITYPrevention of account theftsPrevention of cheatingDistributed games increases cheat opportunity

    1000 and 4000 players with 100 and 400 regions,

    This evaluates to a per-node failure rate of 0.06 per minuteand an average session length of 16.7 minutes. This isclose to the median session length of 18 minutes reportedby Henderson and Bhatti on a set of popular Half Lifeservers [18]. Half Life is a first person shooter (FPS), andwe expect significantly longer sessions in RPGs. Using thisshort session length will, however, allow us to generate ameasurable amount of transfers of coordinators and replicas.

    Node is AOI neighbors are the nodes within is AOI; its enclosing neighbors are nodes whose regions directly surround is region, and boundary neighbors are nodes whose regions overlap with the AOI boundary A node is boundary neighbors will perform neighbor discovery on behalf of i because they connect to i and knows some nodes outside is AOI that are is potential neighbors (those potential neighbors happen to be the enclosing neighbors of the boundary neighbors). Stock neighbor list is different from the normal neighbor list. It keeps some spare nodes which can be used to avoid overlay partition. The capacity of stock neighbor list is bounded. When the stock neighbor list is full, FIFO (first-in-first-out) rule is used to replace nodes in the list. Figure 7. Simulation results for different stock neighbor list sizesFigure 8. Simulation results for different checking periodsFigure 9. Simulation results for different discovery periodsFigure 10. neighborship consistency under different node failure rates for clustered distribution.Figure 11. The number of partitions under different node failure rates for clustered distribution.Figure 12. neighborship consistency under different node failure rates for random distribution.Figure 13. The number of partitions under different node failure rates for random distributionFigure 14. Control overhead with and without the critical node mechanism

Recommended

View more >