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

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?

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

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

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

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

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

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

10
VAST

• Voronoi-based Adaptive Scaleable Transfer
• Each player computes Voronoi diagram of all known
  neighbors
• Neighbor types
• Enclosing neighbors
• Boundary neighbors
• Movement

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 CAIDAs skitter project
• Simulated time 2 hours

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
• 1010 subspaces
• 5 movement updates/sec
• PubSubMMOG 2/sec due to latency limitations

13
Scenarios

• Most important factor player density
• Global density
• Number of players/game area
• Playground sizes
• 1,0001,000, 5,0005,000, 10,00010,000
• Local density
• Local clustering of players
• Modeled with groups
• Group sizes
• 1,5,15,25,40

14
Results Delay (10,00010,000)
15
Results Delay (5,0005,000)
16
Results Delay (1,0001,000)
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

18
Results Bandwidth (10,00010,000)
19
Results Bandwidth (5,0005,000)
20
Results Bandwidth (1,0001,000)
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

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