1 EuroIMSA 2007 Chamonix, March 14-26 th 2007 A PUBLISH SUBSCRIBE SUPPORT FOR NETWORKED MULTIPLAYER GAMES IASTED European Conference on INTERNET AND MULTIMEDIA

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


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


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


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


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


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


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


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


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.


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


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


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


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


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


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


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


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


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


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


ROUTING COMPARISON

simple fusion cell-based advert.0

100200300400500600700800900

1000

2RPG2 Racer4 RPG4 Racer

rem

ore

tra

ffic

(k

byt

es)


ROUTING COMPARISON

2 Racer 2 RPG 4 Racer 4 RPG0

100200300400500600700800900

1000

simplefusioncell-basedadvert.

rmo

te t

raff

ic (

k b

ytes

)


EXPERIMENTAL RESULTS: ROUTING TABLES

0

10

20

30

40

simple merged cell-

based

advert.

Routing Tables Size


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.

Documents

1 EuroIMSA 2007 Chamonix, March 14-26 th 2007 A PUBLISH SUBSCRIBE SUPPORT FOR NETWORKED MULTIPLAYER GAMES IASTED European Conference on INTERNET AND MULTIMEDIA