1 euroimsa 2007 chamonix, march 14-26 th 2007 a publish subscribe support for networked multiplayer...
TRANSCRIPT
EuroIMSA 2007 Chamonix, March 14-26 th 2007 1
A PUBLISH SUBSCRIBE SUPPORTFOR NETWORKED MULTIPLAYER GAMES
IASTED European Conference on INTERNET AND MULTIMEDIA SYSTEMS
AND APPLICATIONS
Fabrizio Baiardi, Antonio Bonotti, Luca Genovali, Laura RicciDipartimento di InformaticaUniversità degli Studi di Pisa
ricci @di.unipi.it
EuroIMSA 2007 Chamonix, March 14-26 th 2007 2
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
EuroIMSA 2007 Chamonix, March 14-26 th 2007 3
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
EuroIMSA 2007 Chamonix, March 14-26 th 2007 4
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
EuroIMSA 2007 Chamonix, March 14-26 th 2007 5
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
EuroIMSA 2007 Chamonix, March 14-26 th 2007 6
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
EuroIMSA 2007 Chamonix, March 14-26 th 2007 7
PUBLISH SUBSCRIBE SUPPORT: FILTER BASED ROUTING
example: the subscribed filter defines the area of interest of a
player
B1
B3
B4
B2
P1
F1 P110<x<2020<y<30
.
.
F2 P230<x<5025<y<45. .
F1
F2
F1 B1
F2 B3
F1 B2
F2 B4
….Area of Interest
Routing table
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
EuroIMSA 2007 Chamonix, March 14-26 th 2007 8
DIGAS: OVERALL ARCHITECTURE
//Multiplayer Game Code
//Initialization phaseClient_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 p
laye
rsE
ven
t N
otii
fcat
ion
Eve
nt
pro
pag
atio
n
init
iali
zati
onel
abor
atio
nte
rmin
atio
n
EuroIMSA 2007 Chamonix, March 14-26 th 2007 9
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.
EuroIMSA 2007 Chamonix, March 14-26 th 2007 10
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
EuroIMSA 2007 Chamonix, March 14-26 th 2007 11
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
EuroIMSA 2007 Chamonix, March 14-26 th 2007 12
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
PP1
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
EuroIMSA 2007 Chamonix, March 14-26 th 2007 13
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
EuroIMSA 2007 Chamonix, March 14-26 th 2007 14
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
B3 X
B3 X
……
………
…
……
…
…
P1
t
P3
P2
EuroIMSA 2007 Chamonix, March 14-26 th 2007 15
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
EuroIMSA 2007 Chamonix, March 14-26 th 2007 16
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
B3 X
B3 X
……
………
…
……
…
…
• PNA(P4) PAI(P1) =
• B3 does not forward PAI(P1) to B4
EuroIMSA 2007 Chamonix, March 14-26 th 2007 17
MERGING FILTERS
P2P1
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
EuroIMSA 2007 Chamonix, March 14-26 th 2007 18
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 Bnew joining the network:
– opens a new connection to MB and requires the list L of the
current brokers
– chooses a broker Bi from L by considering
•number of connectins opened by Bi with other brokers/players
• Ping time to Bi
• Bnew establishes a connection with a single broker: this guarantees
that the resulting network is acyclic
EuroIMSA 2007 Chamonix, March 14-26 th 2007 19
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 Bnew connects to a broker B it asks B for its parent
broker Bback
• Bback becomes the backup broker of Bnew
• 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
EuroIMSA 2007 Chamonix, March 14-26 th 2007 20
ROUTING COMPARISON
simple fusion cell-based advert.0
100200300400500600700800900
1000
2RPG2 Racer4 RPG4 Racer
rem
ore
tra
ffic
(k
byt
es)
EuroIMSA 2007 Chamonix, March 14-26 th 2007 21
ROUTING COMPARISON
2 Racer 2 RPG 4 Racer 4 RPG0
100200300400500600700800900
1000
simplefusioncell-basedadvert.
rmo
te t
raff
ic (
k b
ytes
)
EuroIMSA 2007 Chamonix, March 14-26 th 2007 22
EXPERIMENTAL RESULTS: ROUTING TABLES
0
10
20
30
40
simple merged cell-
based
advert.
Routing Tables Size
EuroIMSA 2007 Chamonix, March 14-26 th 2007 23
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.