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

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

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

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

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

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

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

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

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

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

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

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

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

14. Results: Delay (10,000*10,000)
PubSub: Some of the delay is caused by Timeslots
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: 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

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

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

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

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

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