a case for mutual notification
DESCRIPTION
A Case for Mutual Notification. A Survey of P2P Protocols for Massively Multiplayer Online Games. MMOGs in the wild. All use a client/server architecture Almost all use sharding. P2P-MMOG. Use the power of P2P to overcome scalability issues Research topic for quite some time - PowerPoint PPT PresentationTRANSCRIPT
Stephan KrauseInstitut für Telematik
A Case for Mutual Notification
A Survey of P2P Protocols for Massively Multiplayer Online Games
Stephan Krause Institut für TelematikUniversität Karlsruhe (TH)
www.tm.uka.de
2
A Case for Mutual Notification
MMOGs in the wild
All use a client/server architectureAlmost all use sharding
Stephan Krause Institut für TelematikUniversität Karlsruhe (TH)
www.tm.uka.de
3
A Case for Mutual Notification
P2P-MMOG
Use the power of P2P to overcome scalability issuesResearch topic for quite some timePlethora of protocolsWhich architecture is the best?
Stephan Krause Institut für TelematikUniversität Karlsruhe (TH)
www.tm.uka.de
4
A Case for Mutual Notification
Classification
Too many protocols to look at all of themFocus on protocols for MMO(RP)GsIdentify classes of protocols
Looking at Division of game spaceExchanging movement messages
Resulting classesALM-based ProtocolsSupernode-based ProtocolsMutual Notification Protocols
Stephan Krause Institut für TelematikUniversität Karlsruhe (TH)
www.tm.uka.de
5
A Case for Mutual Notification
ALM
Divide game space into subspacesUsually: fixed size, fixed ID
Create a multicast group for each subspacePlayers have a certain Area of Interest (AoI)
Subscribe to all subspaces inside their AoIMax 4 rectangular subspaces
Unsubscribe if player moves away from subspace
Stephan Krause Institut für TelematikUniversität Karlsruhe (TH)
www.tm.uka.de
6
A Case for Mutual Notification
SimMUD
Based upon SCRIBEALM protocol on top of a DHTBest for SCRIBE: PastryForming of groups recursively on JOIN
No additional messaging overhead
Finding rendezvous pointsGroup ID is the hash of the subspace IDRoot of ALM tree: Node closest to the group IDRoot can be cached
Failure resistanceChildren detect failure of parentsSimple reJOINing the group repairs the tree
Stephan Krause Institut für TelematikUniversität Karlsruhe (TH)
www.tm.uka.de
7
A Case for Mutual Notification
Supernode
Subspace concept similar to ALM-basedAoI/subscription-/unsubscription rules applySubspaces can be static or dynamic
Supernode responsible for each subspaceWith dynamic subspaces:
If too many players in subspace, divide it
With static subspaces:Additional load balancing mechanism needed
Stephan Krause Institut für TelematikUniversität Karlsruhe (TH)
www.tm.uka.de
8
A Case for Mutual Notification
PubSubMMOG
Static subspacesCentral lobby server for resource allocation
Assigns roles
Supernodestores all information for the subspace
Backup nodeIf supernode fails, backup node takes over
Load balancing treeTimeslots
Supernode aggregates messages from a timeslotProblem: limits maximum latency
Stephan Krause Institut für TelematikUniversität Karlsruhe (TH)
www.tm.uka.de
9
A Case for Mutual Notification
Mutual Notification
No fixed subspacesPlayers exchange messages directly
Guarantees good latency overhead
Connection to all players in AoIPlayers must know all their neighbors
Neighbors help discovering moving playersNeighbor discovery must be reliable
Stephan Krause Institut für TelematikUniversität Karlsruhe (TH)
www.tm.uka.de
10
A Case for Mutual Notification
VAST
Voronoi-based Adaptive Scaleable TransferEach player computes Voronoi diagram of all known neighbors
Neighbor typesEnclosing neighborsBoundary neighbors
Movement:
Stephan Krause Institut für TelematikUniversität Karlsruhe (TH)
www.tm.uka.de
11
A Case for Mutual Notification
Simulation
OverSim as simulation frameworkEasy simulation of overlay and P2P networksRealistic models for user behavior
Churn model:Pareto distributed lifetimes
Mean lifetime 100 minutes
On average 500 nodes
DelayReal internet dataUsing measurements from CAIDA’s skitter project
Simulated time: 2 hours
Stephan Krause Institut für TelematikUniversität Karlsruhe (TH)
www.tm.uka.de
12
A Case for Mutual Notification
Simulation
Player behavior modeled by simple game clientIn-game movement model
Random waypointSpeed: 5m/sPlayers can form groups, flocking
AoI: 40m10*10 subspaces5 movement updates/sec
PubSubMMOG 2/sec due to latency limitations
Stephan Krause Institut für TelematikUniversität Karlsruhe (TH)
www.tm.uka.de
13
A Case for Mutual Notification
Scenarios
Most important factor: player density“Global” density:
Number of players/game areaPlayground sizes
1,000*1,000, 5,000*5,000, 10,000*10,000
“Local” density:Local clustering of playersModeled with groupsGroup sizes:
1,5,15,25,40
Stephan Krause Institut für TelematikUniversität Karlsruhe (TH)
www.tm.uka.de
14
A Case for Mutual Notification
Results: Delay (10,000*10,000)
0.1
0.15
0.2
0.25
0.3
0.35
0.4
0.45
0.5
0 5 10 15 20 25 30 35 40
De
lay
(s)
Group size
PubSubMMOGSimMUD
Vast
Stephan Krause Institut für TelematikUniversität Karlsruhe (TH)
www.tm.uka.de
15
A Case for Mutual Notification
Results: Delay (5,000*5,000)
0.1
0.15
0.2
0.25
0.3
0.35
0.4
0.45
0.5
0.55
0 5 10 15 20 25 30 35 40
De
lay
(s)
Group size
PubSubMMOGSimMUD
Vast
Stephan Krause Institut für TelematikUniversität Karlsruhe (TH)
www.tm.uka.de
16
A Case for Mutual Notification
Results: Delay (1,000*1,000)
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0 5 10 15 20 25 30 35 40
De
lay
(s)
Group size
PubSubMMOGSimMUD
Vast
Stephan Krause Institut für TelematikUniversität Karlsruhe (TH)
www.tm.uka.de
17
A Case for Mutual Notification
Summary: Delay
SimMUD:Robust to local densityProblems with global density
PubSubMMOG:Robust to global densityLogarithmic increase with local density
VAST:Robust to both global and local density
Stephan Krause Institut für TelematikUniversität Karlsruhe (TH)
www.tm.uka.de
18
A Case for Mutual Notification
Results: Bandwidth (10,000*10,000)
200
300
400
500
600
700
800
900
1000
1100
1200
0 5 10 15 20 25 30 35 40
Ba
nd
wid
th (
Byt
es/
s)
Group size
PubSubMMOGSimMUD
Vast
Stephan Krause Institut für TelematikUniversität Karlsruhe (TH)
www.tm.uka.de
19
A Case for Mutual Notification
Results: Bandwidth (5,000*5,000)
300
400
500
600
700
800
900
1000
1100
1200
1300
0 5 10 15 20 25 30 35 40
Ba
nd
wid
th (
Byt
es/
s)
Group size
PubSubMMOGSimMUD
Vast
Stephan Krause Institut für TelematikUniversität Karlsruhe (TH)
www.tm.uka.de
20
A Case for Mutual Notification
Results: Bandwidth (1,000*1,000)
500
1000
1500
2000
2500
3000
3500
4000
0 5 10 15 20 25 30 35 40
Ba
nd
wid
th (
Byt
es/
s)
Group size
PubSubMMOGSimMUD
Vast
Stephan Krause Institut für TelematikUniversität Karlsruhe (TH)
www.tm.uka.de
21
A Case for Mutual Notification
Summary: Bandwidth
SimMUD:Robust to local densityProblems with global density
PubSubMMOGAffected by both global and local density
Traffic can get rather high
VASTIn most cases, unaffected to both global and local densityOnly increases in really crowded settings
Stephan Krause Institut für TelematikUniversität Karlsruhe (TH)
www.tm.uka.de
22
A Case for Mutual Notification
Conclusions
Best delay: VASTCan be generalized to all mutual notification protocols
Best bandwidth:Low player densities: PubSubMMOG or SimMUDHigh player densities: VAST
Mutual notification: great performanceStability can be an issue
ALM: rock solid, but high delaysSupernode: stable, good delays, but high bandwidthTimeslots unsuitable for globally distributed players