MERCURY: A Scalable PublishSubscribe System for Internet Games

1
MERCURY A Scalable Publish-Subscribe System for
Internet Games

• Ashwin R. Bharambe
• To appear in NetGames02

2
My outline

• Whats wrong with current games ?
• Strongly emphasized
• Centralized
• Use broadcast
• Bottleneck for scaling
• Quotes to show companies WANT to support more
  players, arch. Does not allow
  
• Bandwidth wastage as well
• Cheating
• Also
• Games are e.g. of distrib-apps
• Aim build generic blocks for distrib-apps
• What are the ideals ?
• Minimize BW wastage
• Prevent Hot spots
• Robustness
• Outline

• Game requirements
• Player should receive only visible or audible
  events
  
• Minimize useless traffic
• Prevent cheating
• In general, receive only what u WANT
• Big Idea This is just publish-subscribe with a
  twist
  
• What the heck is pub-sub
• What is twist ( game state )
• Objectives of a good pub-sub
• Very brief review
• what centralized / broadcast architectures do
• Design of Mercury
• Why cant we use consistent hashing
• Hubs, routing, etc with EXAMPLES
• Design of Quake using Mercury
• Evaluation using synthetic workload

3
Game architectures

• Last generation (DOOM)
• Broadcast each update to every participant
• Game proceeds in locksteps
• Current generation (Quake)
• Client-server
• Server maintains authoritative game state
• Sends relevant updates to clients
• Generation-X
• Mercury!! ?

Big Boss
4
Whats wrong with them ?

• Very bad scaling properties
• Central server
• Bottleneck for computation bandwidth
• Single point of failure
• Broadcast
• Ridiculous on an Internet scale!
• Players receive unneeded updates and cheat
• Scaling and robustness are not plain research
  curiosities
  
• IDC expects the online-gaming market to be worth
  2.3 billion by 2005
  
• Today's gaming servers are expensive to maintain,
  inflexible, and prone to crash.
  
• Most online games get stuck at about 6,000
  players per server, and players on one server
  can't talk to those on another, reducing the
  appeal of an online-gaming community.

http//www.redherring.com/insider/2002/0117/724.ht
ml
5
More motivations for distributed game
architectures

• Building blocks for generic distributed systems
• Multiplayer game is a complex distributed
  application
  
• Communication patterns between game components
  are similar in spirit to many other applications
  
• Instant messengers, Chat rooms
• Service discovery, Stock tickers
• Distributed auction systems
• MERCURY architecture will be applicable to these
  distributed applications
  
• You get to play games!!! ?

6
The ProblemBuild a Distributed Game which -

• Prevents swamping at any cost
• No Hot-Spots in the system
• Minimizes wastage of bandwidth
• Avoid flooding at all costs
• Is robust
• Nodes leaving or joining the system should have
  minimal impact on other nodes
  

7
Outline

• Publish-subscribe systems
• How games can be modeled as a
  publish-subscribe system
  
• Architecture of MERCURY
• Distributed publish-subscribe system
• Simulation results
• Future work

8
Game requirements

• Information needed by a player
• Visible and audible events happening in his
  arena
  
• Satellite game information
• e.g., enemies, teammates, other terrain, etc.
• Downloading textures etc. relevant to the level
  in which he is playing
  
• Big Idea
• These interactions can be modeled as a
  publish-subscribe system
  
• With a slight difference!

9
What is Publish-Subscribe ?
Intelligent Network
I am available!
Publications
Subscription
Wanted a guy!
I am too!

• Publishers produce events or publications
• Subscribers register their interests via
  subscriptions
  
• Network routes content
• publications meet subscriptions

10
ExampleFirst-person shooting game
Publication
(50,250)
(100,200)
Player
(150,150)
Virtual World
Subscription
11
The Slight Difference

• Traditional pub-sub filter
• No notion of an underlying persistent state
• State is very important for a game
• Every publication
• Is matched against subscriptions and routed
• Acts as a write event on the underlying database

12
Requirements of a pub-sub system for games

• Expressive subscription language
• Different games - varied interactions
• Scalability of the routing mechanism
• Scaling with respect to number of subscriptions
  and publications
  
• Network Efficiency
• Avoid flooding of subscriptions or publications
• Minimize latency important for real-time games
• Previous pub-sub systems (SIENA, Elvin, Gryphon)
• Centralized OR --
• Use broadcast in one way or other

13
MERCURY Subscription Language

• SQLish
• Type, attribute name, operator, value
• Example int x
• Types int, float, bool, string
• Operators
• Numeric , , !,
• String suffix, prefix,

14
MERCURY Routing protocol

• Each node responsible for range of attribute
  values
  
• Similar to B-tree distributed!
• Division of responsibility
• Simple for numeric types
• have bounded ranges
• String types
• Based on first or last few characters e.g. a-c
  or aa-cz, etc.
  
• Can support prefix, suffix
• Supporting substring efficiently is difficult
• For each attribute, nodes logically arranged into
  circle call this overlay as Attribute Hub

15
Routing Illustrated

• Send subscription to any one attribute hub
• Send publications to all attribute hubs
• Each node compares value in message to his range
  and routes along the circle

Subscription
Publication
16
Routing Challenges

• Cannot use hashing
• Want to support range queries
• Routing hops
• O(n) worst case!
• Can be brought down to O(log n) using
  exponentially spaced finger pointers ( similar to
  Chord )
  
• Load balance sensitive to distribution of data
  values

17
Simulation Results

• Workload FPS-game
• Virtual world square
• Player movements use mobility models from NS

Without finger pointers!

• Delay between pub. send and recv by subscriber
• Load Number of publications routed by a node

18
Promising Aspects

• Expressive subscription language
• Completely decentralized architecture
• Scalability
• Avoids flooding of subscriptions and publications
  reduces network traffic considerably
  
• Distributes publications and subscriptions
  throughout the network can reduce swamping
  effectively
  
• Problem depends on distribution of data values
• Performance
• Simulation shows Publication delivery delay
  scales linearly
  

19
Currently working on

• Realistic workloads
• Introduce BOTs into Quake collect traces!
• Building a Quake-II prototype which uses MERCURY
  
  
• Study packets between client-server to figure out
  subscription model
  
• Distribute the server state among different
  nodes
  
• Diffusive load balancing
• Shed off load to neighbours gradually

20
Questions, Comments, Suggestions, Criticisms