A Case for Mutual Notification A Survey of P2P Protocols for Massively Multiplayer Online Games

All use a client/server architecture Almost all use sharding MMOGs in the wild All use a client/server architecture Almost all use sharding Why do we want to get rid of sharding? A Case for Mutual Notification

Use the power of P2P to overcome scalability issues P2P-MMOG Use the power of P2P to overcome scalability issues Research topic for quite some time Plethora of protocols Which architecture is the best? Protocols: ring/dht, tree, central server, distributed A Case for Mutual Notification

Too many protocols to look at all of them Classification Too many protocols to look at all of them Focus on protocols for MMO(RP)Gs Identify classes of protocols Looking at Division of game space Exchanging movement messages Resulting classes ALM-based Protocols Supernode-based Protocols Mutual Notification Protocols A Case for Mutual Notification

Divide game space into subspaces ALM Divide game space into subspaces Usually: fixed size, fixed ID Create a multicast group for each subspace Players have a certain Area of Interest (AoI) Subscribe to all subspaces inside their AoI Max 4 rectangular subspaces Unsubscribe if player moves away from subspace A Case for Mutual Notification

Finding rendezvous points SimMUD Based upon SCRIBE ALM protocol on top of a DHT Best for SCRIBE: Pastry Forming of groups recursively on JOIN No additional messaging overhead Finding rendezvous points Group ID is the hash of the subspace ID Root of ALM tree: Node closest to the group ID Root can be cached Failure resistance Children detect failure of parents Simple reJOINing the group repairs the tree 1.: some words about DHT, O(logN) 2.: rendevous point=root can also store additional informations if needed A Case for Mutual Notification

Subspace concept similar to ALM-based Supernode Subspace concept similar to ALM-based AoI/subscription-/unsubscription rules apply Subspaces can be static or dynamic Supernode responsible for each subspace With dynamic subspaces: If too many players in subspace, divide it With static subspaces: Additional load balancing mechanism needed A Case for Mutual Notification

Central lobby server for resource allocation Supernode Backup node PubSubMMOG Static subspaces Central lobby server for resource allocation Assigns roles Supernode stores all information for the subspace Backup node If supernode fails, backup node takes over Load balancing tree Timeslots Supernode aggregates messages from a timeslot Problem: limits maximum latency A Case for Mutual Notification

Players exchange messages directly Connection to all players in AoI Mutual Notification No fixed subspaces Players exchange messages directly Guarantees good latency overhead Connection to all players in AoI Players must know all their neighbors Neighbors help discovering moving players Neighbor discovery must be reliable A Case for Mutual Notification

Voronoi-based Adaptive Scaleable Transfer VAST Voronoi-based Adaptive Scaleable Transfer Each player computes Voronoi diagram of all known neighbors Neighbor types Enclosing neighbors Boundary neighbors Movement: Enclosing: neighboring voronoi region Boundary: AoI intersects voronoi region A neighbor can be both New neighbor checks: boundary->enclosing A Case for Mutual Notification

OverSim as simulation framework Easy simulation of overlay and P2P networks Realistic models for user behavior Churn model: Pareto distributed lifetimes Mean lifetime 100 minutes On average 500 nodes Delay Real internet data Using measurements from CAIDA’s skitter project Simulated time: 2 hours Churn: heavy taoled session times suggested by empirical data Delay: place nodes to virtual coordinates, delay = distance+access net A Case for Mutual Notification

Player behavior modeled by simple game client In-game movement model Simulation Player behavior modeled by simple game client In-game movement model Random waypoint Speed: 5m/s Players can form groups, flocking AoI: 40m 10*10 subspaces 5 movement updates/sec PubSubMMOG 2/sec due to latency limitations A Case for Mutual Notification

Most important factor: player density “Global” density: Scenarios Most important factor: player density “Global” density: Number of players/game area Playground sizes 1,000*1,000, 5,000*5,000, 10,000*10,000 “Local” density: Local clustering of players Modeled with groups Group sizes: 1,5,15,25,40 A Case for Mutual Notification

Results: Delay (10,000*10,000) PubSub: Some of the delay is caused by Timeslots A Case for Mutual Notification

Results: Delay (5,000*5,000) A Case for Mutual Notification

Results: Delay (1,000*1,000) A Case for Mutual Notification

Summary: Delay SimMUD: PubSubMMOG: VAST: Robust to local density Problems with global density PubSubMMOG: Robust to global density Logarithmic increase with local density VAST: Robust to both global and local density A Case for Mutual Notification

Results: Bandwidth (10,000*10,000) Pubsub: multiply by 2.5! A Case for Mutual Notification

Results: Bandwidth (5,000*5,000) A Case for Mutual Notification

Results: Bandwidth (1,000*1,000) Vast: Consistency A Case for Mutual Notification

Summary: Bandwidth SimMUD: PubSubMMOG VAST Robust to local density Problems with global density PubSubMMOG Affected by both global and local density Traffic can get rather high VAST In most cases, unaffected to both global and local density Only increases in really crowded settings A Case for Mutual Notification

Mutual notification: great performance Conclusions Best delay: VAST Can be generalized to all mutual notification protocols Best bandwidth: Low player densities: PubSubMMOG or SimMUD High player densities: VAST Mutual notification: great performance Stability can be an issue ALM: rock solid, but high delays Supernode: stable, good delays, but high bandwidth Timeslots unsuitable for globally distributed players Bandwidth: Perhaps not quit generalizeable BUT: All protocols in reasonable boundaries A Case for Mutual Notification