1 / 22

Enhancing Scalability in MMOGs: A Case for Mutual Notification Protocols

This paper surveys the effectiveness of various P2P protocols for massively multiplayer online games (MMOGs), focusing on mutual notification systems to address scalability issues. We examine architectures such as ALM-based protocols, supernode-based solutions, and PubSubMMOGs. By analyzing classes of protocols and their performance in diverse game environments, we identify optimal strategies for player interaction and message exchange. The study reveals the strengths of each approach, particularly under differing density conditions, providing insights into improving user experience in online gaming.

ricky
Télécharger la présentation

Enhancing Scalability in MMOGs: A Case for Mutual Notification Protocols

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related