1. 1 EuroIMSA 2007 Chamonix, March 14-26 th 2007 A PUBLISH SUBSCRIBE SUPPORT FOR NETWORKED MULTIPLAYER GAMES IASTED European Conference on INTERNET AND MULTIMEDIA SYSTEMS AND APPLICATIONS Fabrizio Baiardi, Antonio Bonotti, Luca Genovali, Laura Ricci Dipartimento di Informatica Università degli Studi di Pisa ricci @di.unipi.it

2. 2 EuroIMSA 2007 Chamonix, March 14-26 th 2007 PRESENTATION OUTLINE Distributed Virtual Environments: design choices DiGAS (Distributed Game Support): overall architecture DiGAS communication supports: cell based vs. entity based routing Routing optimizations Experiments and Conclusions

3. 3 EuroIMSA 2007 Chamonix, March 14-26 th 2007 DISTRIBUTED VIRTUAL ENVIRONMENTS (DVE) Real-Time Distributed Virtual Environments : provide to geographically distributed end-users the illusion of being immersed in a unique shared virtual world real time interactions among users and/or among users and computer controlled entities Examples: distributed multiplayer games, military simulations Architectural models: central server, P2P, hybrid Multiplayer Games: a set of entities (avatars, monsters, tanks,…) populate a virtual world each entity communicates its state (change of position, colour), or virtual world modifications to other partecipants

4. 4 EuroIMSA 2007 Chamonix, March 14-26 th 2007 DVE: DESIGN CHALLANGES DVE applications raise many challanges mechanisms to guarantee the consistency of the virtual world synchronization, state replication real time requirements: the action performed by an entity must be visible to other entities within a bounded time scalability – consistency requires the exchange of a huge amount of information among end users – high bindwidth, CPU load – optimization required to minimize the exchanged information

5. 5 EuroIMSA 2007 Chamonix, March 14-26 th 2007 DVE: INTEREST MANAGEMENT Interest Management: reduce DVEs communication requirements. Area of Interest (IA) of an entity E = portion of the virtual world including entities that may interact with E – example: a player interacts with entities (players, monsters) located in its surrondings, e.g. in the same room. The definition of the IA of E depends upon the semantics of the application, e.g. the sight capability of E E is interested in receiving information from entities in its IA only Implementation: – Multicast groups – Publish-subscribe systems

6. 6 EuroIMSA 2007 Chamonix, March 14-26 th 2007 PUBLISH SUBSCRIBE SUPPORTS Support group communications Entities of the virtual world – deliver and publish events by notifications – express their interests in (pattern of) events by subscriptions (filters) Matching of subscriptions and notifications is implemented by a set of application level routers = brokers Broker Network = defines the broker interconnection structure Design choices – broker network topology – application level routing algorithms

7. 7 EuroIMSA 2007 Chamonix, March 14-26 th 2007 PUBLISH SUBSCRIBE SUPPORT: FILTER BASED ROUTING example: the subscribed filter defines the area of interest of a player B1 B3 B4 B2 P1 F1 P1 10<x<20 20<y<30.... F2 P2 30<x<50 25<y<45. F1 F2 F1 B1 F2 B3 F1 B2 F2 B4 …. Area of Interest Routing table each subscription is flooded in the broker network notifications routing is guided by the subscriptions stored in the routing table P2 P1 P2

8. 8 EuroIMSA 2007 Chamonix, March 14-26 th 2007 DIGAS: OVERALL ARCHITECTURE //Multiplayer Game Code / /Initialization phase Client_Initialization(...) // Initial Positioning Client_Initial_Position(...) // Waiting for N players Client_Global_Synchronization(N) While (playing) { // sending events generated by the local player Client_Send(...) Lista_events = Client_Receive_Event(...) while (Lista_events  null) { // player state update } // game logic elaboration: rendering, AI,.... } Client_Termination(...) Events Support blocking Entering the game Event support (orderi ng, local lag....) Exiting the game Broker Network N players Event Notiifcation Event propagation initialization elaboration termination

9. 9 EuroIMSA 2007 Chamonix, March 14-26 th 2007 DiGAS: OVERALL ARCHITECTURE DiGAS communication support is based on a publish-subscribe model DiGAS overlay network =Acyclic P2P network of brokers – each player is connected to a single broker = terminal broker – internal brokers are connected to other brokers DiGAS bootstrap: – a bootstrap broker MB can be located at a static IP address – MB manages a list L of the brokers currently available in the network – each broker/player B entering a DiGAS network connects to MB and receives L chooses a single broker BP in L and connects to BP. BP becomes the parent broker of BB.

10. 10 EuroIMSA 2007 Chamonix, March 14-26 th 2007 DiGAS: ROUTING STRATEGIES DiVES defines several routing algorithms Cell Based Routing – Coarse grain partition of the virtual world into a set af areas (cells) – Each area of interest is approximated by a set of cells Entity Based Routing – Finer grain area of interests: each filter corresponds to the area of interest of a player – generates a huge amount of filters. Several optimizations have been defined to reduce network traffic Approximated Area of Interest Advertisements Filter merging

11. 11 EuroIMSA 2007 Chamonix, March 14-26 th 2007 CELL BASED DIGAS P the virtual world is partitioned into a set of cells Hpotheisis: each area of interest is included in a cell Filter = cell where P is located + surronding cells Filter Routing : P subscribes a filter when it enters a cell the filter is not modified as long as P moves within the same cell

12. 12 EuroIMSA 2007 Chamonix, March 14-26 th 2007 ENTITY BASED DIGAS Filter = Area of interest of a player P each player notifies its position PO to the broker network the notification is delivered to each player whose area of interest includes PO P P1 P2 P3 P belongs to the areas of interests of P1,P2,P3 the movements of P are notified to P1,P2,P3 P1,P2,P3 do not belong to the area of interest of P

13. 13 EuroIMSA 2007 Chamonix, March 14-26 th 2007 ENTITY BASED DiGAS: OPTIMIZATIONS Optimizations Goal: reduction of the network traffic due to filter propagation Predicted Notification Area (PNA) = Set of positions that can be reached by P in a time interval  t – starting from its current position – travelling along a straight line with a constant speed v Predicted Area of Interest (PAI) = Subspace of the virtual world including the area of interest corresponding to any point in the PNA Entity based routing optimization: – each player subscribes its PAI, rather than its exact area of interest Filter traffic can be tuned by defining a proper value of  t

14. 14 EuroIMSA 2007 Chamonix, March 14-26 th 2007 PREDICTED AREA OF INTEREST Y =Area of Interest Z = Predicted Notification Area (PNA) X = Predicted Area of Interest (PAI) P4 PNA B1 P1 B2 B3 B4 B5 … … P1 Y X B1 X B3 X … … … … … … … … … … P1 tt P3 P2

15. 15 EuroIMSA 2007 Chamonix, March 14-26 th 2007 ADVERTISEMENT BASED FILTER ROUTING Advertisement based routing each host periodically delivers a filter describing the set of notifications it is going to publish in the next future advertisements are flooded into the network each broker stores an advertisement table when a broker receives a filter F, it forwards F to the brokers including at least an advertisement intersecting F DiVES Advertisement based routing optimization advertisement = Predicted Notification Areas

16. 16 EuroIMSA 2007 Chamonix, March 14-26 th 2007 ADVERTISEMENT BASED ROUTING Y =Area of Interest P1 Z = Predicted Notification Area X = Predicted Area of Interest P4 PNA B1 P1 B2 B3 B4 B5 … … P1 Y X B1 X B3 X … … … … … … … … … … PNA(P4)  PAI(P1) =  B3 does not forward PAI(P1) to B4

17. 17 EuroIMSA 2007 Chamonix, March 14-26 th 2007 MERGING FILTERS P2 P1 P2 A broker can merge filters delivered from different players Example F = F1 U F2 Merging filters introduces another level of approximation DiVES merging based routing: Two filters are merged iff the resulting region does not exceed a given threshold F1 F2 F

18. 18 EuroIMSA 2007 Chamonix, March 14-26 th 2007 JOINING THE BROKER NETWORK Broker Network : acyclic peer to peer network of brokers Master Broker MB : – Defines a bootstrap service for players and brokers willing to join the broker network – Monitors the system by polling the status of the brokers Bootstrap procedure. A new broker B new joining the network: – opens a new connection to MB and requires the list L of the current brokers – chooses a broker B i from L by considering number of connectins opened by B i with other brokers/players Ping time to B i B new establishes a connection with a single broker: this guarantees that the resulting network is acyclic

19. 19 EuroIMSA 2007 Chamonix, March 14-26 th 2007 RECOVERING BY A CRASH each broker defines a backup broker the first broker connecting to the network sets its backup broker reference to an undefined value when a new broker B new connects to a broker B it asks B for its parent broker B back B back becomes the backup broker of B new when a broker detects the crash of its parent broker, it tries to connect to its backup broker, if it exists if the first broker fails its sons: – do not reference a backup broker – send to the master server MS their candidature for becoming the new root – MS elects the new root

20. 20 EuroIMSA 2007 Chamonix, March 14-26 th 2007 ROUTING COMPARISON

21. 21 EuroIMSA 2007 Chamonix, March 14-26 th 2007 ROUTING COMPARISON

22. 22 EuroIMSA 2007 Chamonix, March 14-26 th 2007 EXPERIMENTAL RESULTS: ROUTING TABLES

23. 23 EuroIMSA 2007 Chamonix, March 14-26 th 2007 CONCLUSIONS DIGAS: exploits the publish-subscribe model Entity Based routing with predicted area of interest produces the minimum amount of remote traffic Best compromise between amount of remote traffic and routing tables size obtained in advertisement based routing Future work: – definition of cheating detection tools – refinement of consistency mechanisms – JXTA implementation of the broker network.