A Case for Mutual Notification

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

2. MMOGs in the wild • All use a client/server architecture • Almost all use sharding A Case for Mutual Notification

3. 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? A Case for Mutual Notification

4. 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

5. 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

6. 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 A Case for Mutual Notification

7. 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

8. 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

9. 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

10. VAST • Voronoi-based Adaptive Scaleable Transfer • Each player computes Voronoi diagram of all known neighbors • Neighbor types • Enclosing neighbors • Boundary neighbors • Movement: A Case for Mutual Notification

11. Simulation • 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 A Case for Mutual Notification

12. 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

13. 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

14. Results: Delay (10,000*10,000) A Case for Mutual Notification

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

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

17. Summary: Delay • SimMUD: • 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

18. Results: Bandwidth (10,000*10,000) A Case for Mutual Notification

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

20. Results: Bandwidth (1,000*1,000) A Case for Mutual Notification

21. Summary: Bandwidth • SimMUD: • 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

22. 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 A Case for Mutual Notification