Implementation of a Peer-to-Peer Multiplayer Game with ... - DVS

More documents

Recommendations

Info

ArchitectureCensus operates in epochs, which are fixed-length time intervals (30s is a typical length). Each epochhas a fixed and consistent membership view which only changes on epoch transitions. Also, each epochhas one member that acts as the leader, multicasting an item informing about membership changes atthe end of the epoch. Within each epoch, application data can be multicast according to the groupmemberships. Multicast trees are built based on a network coordinate system like Vivaldi [9]. Theauthors present three versions of the algorithm, starting with a simplified single-region setup (scalingto more than 10,000 nodes), then introducing the multi-region system and finally adding the partialknowledge extension for particularly large or dynamic systems.In the first version, there is a single leader processing all membership events. A joining node identifiesitself to the leader and provides its network coordinates (for network proximity management) and anoptional identity certificate. The leader informs the joining node about the current epoch number and afew members from whose the latter obtains the current membership information. When leaving, a nodesends a departure request; failed nodes are detected by others. Nodes report major changes of theirnetwork location, enabling relocations for continuous network proximity.For larger deployments, the system is divided into multiple regions based on network proximity. Eachregion has a region leader which is responsible for membership activities within the region. Towards theend of an epoch, each region leader sends a report for its region to the global leader who then createsthe item for the next epoch. When a node’s network coordinates change, it may move to another regionby sending a move request to the region leader. The number of regions is not fixed. Instead, the systemstarts with one region, and whenever a region size has reached a certain threshold, it is split. If a regionshrinks below a certain threshold, it merges with a neighboring region.Even with multiple regions, each node still has the full membership view. This effects a high bandwidthrequirement for all participating nodes particularly in very large and/or dynamic (i.e., membershipschange frequently) systems. To solve this problem, there is a partial knowledge deployment option inwhich participants only have a full membership view for their own region but only summary informationabout the other regions. The summary includes the region leader, the region’s size and centroid, andsome region members.MulticastMulticast is is based on multiple distribution trees which are built deterministically and on-the-fly usingthe consistent membership view. Thus, each node computes where to forward messages to, usinga deterministic algorithm. Doing so, the tree is rebuilt every epoch, independent from the previousone. Multiple trees allow for redundancy using m-of-n erasure-coded fragments, i.e., there are n trees(typically 4 to 16) and a message can be reconstructed if at least m fragments have been received. Ifmore than n − m fragments are missing, a node requests missing fragments from random nodes of hismembership view.The trees within each region are interior-node-disjoint, i.e., each node is an interior node of at most onetree. This ensures that failed nodes cannot break more than one distribution tree. Trees are recursivelybuilt based on node locality. In each step, the current sub-region is split through the centroid across thelongest edge, choosing one node on each side as a child. Before building the trees, all nodes are colored(round robin), and one tree is built per color, using only nodes with that color as interior nodes. Withmultiple regions, inter-region trees are built the same way, just containing only one representative ofeach color in each region.Bandwidth requirement is minimized by letting only one parent send the membership update fora particular child, and only m parents send a fragment. Latency is optimized using the membershipknowledge. A fragment is only sent if it is on one of the m fastest paths to the child.16 2.2 Application Layer Multicast
DiscussionCensus’ most important feature is the consistent membership view of all members. But this feature causesa rather high bandwidth and memory consumption on all members. Although peer-to-peer MMOGsdo not necessarily have several 10,000 players, they are though highly dynamic. Players continuouslymove in the game world and thus group memberships tend to change frequently. Also, Census exploitsnetwork proximity which allows for low latency distribution. Systems specifically designed for games(see next section) rather concentrate on game world proximity because the highest traffic is usuallybetween nearby nodes in the game world. Finally, membership operations in Census take a whole epoch(typically 30s) to complete. This is by far too slow at least for fast-paced games.2.3 Peer-to-Peer GamingThis section provides an overview of the recent research publications in the topic Peer-to-Peer gaming.Here, the different approaches are described separately, while the next section tries to combine themdefining a generic design space for Peer-to-Peer MMOGs.Peer-to-peer games in general are not particularly new. Since the early days of networking, there havebeen networked multiplayer games. But these games always were very limited in the number of players;some recent games support up to 32 or even 64 players. Basically, there are two alternate ‘simple’approaches that can be taken in these multiplayer games:Single master. One machine is chosen to be the game master. This is typically done explicitly by theplayers; the one who creates the game acts as the master, everyone else connects as a slave. Thisapproach relates to client-server, where the server (master) quickly becomes the bottleneck, eitherbecause of a lack of processing power or network bandwidth.Full replication. Every machine executes the whole game logic and only the actions of each player areexchanged. Although this distributes the load very well, it may be hard to efficiently synchronizethe game mechanics on all machines and avoid ‘alternate realities’, i.e., inconsistent views of thegame world. And the game world (including game mechanics calculations) can only be as complexas supported by the weakest machine in the network.Both techniques obviously do not scale with limited bandwidth and/or processing capabilities. Theapproaches presented in the following try to overcome these limitations by exploiting special propertiesof games like locality of interest (effected by limited vision ranges).2.3.1 SimMudIn 2004, Knutsson et al. published a paper [20] presenting an architecture for Peer-to-Peer massivelymultiplayer games based on a DHT. For evaluation purposes they implemented the prototype gameSimMud.The authors point out three main challenges that need to be considered when developing Peer-to-Peergames: 1. Performance. There is the need for frequent and low latency updates with a low networkcapacity. 2. Availability. Leaving and failing nodes must be compensated. 3. Security. Prevent cheatingand account thefts. As for most of the papers related to this work, the topic of security is identified as aseparate issue and not discussed any further.The main concept introduced by the paper is the distribution of the transient game state among allparticipating players while the persistent state like account information and character experience is kepton a central server. This allows distributing the workload but still being able to keep control of the2 Related Work 17
Page 1 and 2: Implementation of aPeer-to-Peer Mul
Page 3: AbstractMassively multiplayer onlin
Page 7 and 8: Contents1 Introduction 71.1 Planet
Page 9 and 10: 1 IntroductionIn the recent years,
Page 11 and 12: Figure 1.2: Screenshot of the origi
Page 13: Avatar is the virtual representatio
Page 16 and 17: scenarios with millions of users, t
Page 20 and 21: administrative data. For short gami
Page 22 and 23: 2.3.2 HydraHydra [5] is a peer-to-p
Page 24 and 25: DHT’s key space. A comparison of
Page 26 and 27: the sender). Interest sets limit th
Page 28 and 29: EvaluationVON is evaluated in a sim
Page 30 and 31: 2.4.1 Low-Latency Information Disse
Page 32 and 33: 2.4.3 Object Synchronization and Ga
Page 34 and 35: API IntroductionThis section briefl
Page 36 and 37: The EndPoint class provides two mai
Page 39 and 40: 3 ConceptThis work’s implementati
Page 41 and 42: A solution could be using a mix of
Page 43 and 44: closing connections immediately is
Page 45: game instance. startNode() takes a
Page 48 and 49: Figure 4.1: Game Component Dependen
Page 50 and 51: Figure 4.2: In-game status message
Page 52 and 53: lock other tasks, resulting in a fa
Page 54 and 55: AvatarAn abstract representation of
Page 56 and 57: Figure 4.4: The network engine’s
Page 58 and 59: Figure 4.6: AI motion prediction wi
Page 60 and 61: MessageTable 4.1: Message types use
Page 62 and 63: Table 4.2: Message types used by th
Page 64 and 65: }// init gamegame ->init(device , t
Page 66 and 67: Irrlicht for Linux requires a few a
Page 68 and 69:
ExamplesRunning the program without
Page 70 and 71:
4.6.2 Implementation ConcernsUnlike
Page 72 and 73:
eset callback may be called synchro
Page 74 and 75:
Table 5.1: Client-server traffic de
Page 76 and 77:
700006000050000Traffic (bytes/s)400
Page 78 and 79:
1000000900000800000700000Traffic (b
Page 80 and 81:
Table 5.3: Computation time and mem
Page 82 and 83:
Table 5.4: Computation time and mem
Page 85 and 86:
6 ConclusionThe core task of this w
Page 87:
New game features and improvements
Page 90 and 91:
AIprintf("Init AI...\n");ctx ->ai->
Page 93 and 94:
Bibliography[1] E. J. Berglund and
Page 95:
[32] Ion Stoica, Robert Morris, Dav
show all

Implementation of a Peer-to-Peer Multiplayer Game with ... - DVS

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?