1. M ERCURY : A Scalable Publish-Subscribe System for Internet Games Ashwin R. Bharambe To appear in NetGames’02

2. My outline What’s 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 can’t 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. What’s 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.html

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 M ERCURY architecture will be applicable to these distributed applications You get to play games!!!

6. The Problem: Build 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 M ERCURY 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 ? Publishers produce events or publications Subscribers register their interests via subscriptions Network routes content publications “meet” subscriptions Wanted: a guy! Subscription I am available! I am too! Publications Intelligent Network

10. Example: First-person shooting game Player int x >= 50 int x <= 150 int y >= 150 int y <= 250 Subscription int x 100 int y 200 Publication (100,200) Virtual World (150,150) (50,250)

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. M ERCURY : Subscription Language SQLish Type, attribute name, operator, value Example: int x <= 200 Types: int, float, bool, string Operators: Numeric:, >=, !=, = String: suffix, prefix, *

14. M ERCURY : 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 HxHx [240, 320) [0, 80) [80, 160) [160, 240) HyHy [0, 105) [105, 210) [210, 320) int x >= 50 int x <= 150 int y >= 150 int y <= 250 int x 100 int y 200 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 Delay between pub. send and recv by subscriber Load: Number of publications routed by a node Without finger pointers!

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 M ERCURY 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 …