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

More documents

Recommendations

Info

Table 5.4: Computation time and memory requirements of a 32-player peer-to-peer game simulation withplayer clustering# Clusters Players/cluster Runtime 30s (s) Memory (MB)1 32 225 5582 16 133 5104 8 99 4788 4 57 457Figure 5.10: Screenshot of a simulation run with a high player density (spaceship textures disabled)small space. As each player can see all others, everyone needs to process information about everyoneelse, resulting in the quadratic consumption. This is the same effect that also appears in the trafficmeasurements. And like there, it has to be mentioned that the growth will be much lower if the averagenumber of nodes in the vision range stays constant. Similarly to the peer traffic, the simulation time isreduced if the players are separated into multiple clusters. Table 5.4 shows the significant impact of theplayer distribution on the simulation.The simulation measurement are made with transport encryption turned on, thus all data sent over thesimulated network is AES-encrypted and each connection attempt requires complex public key encryptionoperations. Encryption in the simulator is obviously superfluous. A later version of CUSP allows toeasily turn off encryption through the API, resulting in a speedup of the simulation. Also, the simulatortested here is a 64 bit build which did not yet have an optimized cryptographic suite. The now availableoptimized version is much faster. Still, all these optimizations will not change the trends shown in themeasurements above.80 5.2 Performance Measurements
5.3 CUSPThis section briefly discusses the experience of using CUSP. First off, the reliability and correctness of theprotocol implementation itself has been very satisfying from the beginning. There were only a few minorbugs to fix that appeared in use cases that had not been tested before, but this is negligible.However, the correct usage of CUSP’s asynchronous API with C++ has shown to be challenging.Obviously, the API is more complex than the Berkeley sockets API. Asynchronous I/O using callbackfunctions is generally inconvenient in C++. The callback handlers passed to the I/O function usuallyrequire some state for futher processing of the results. In C++ there is no other way of passing thatstate than explicitly creating an object and passing it to the function. Languages supporting closures(like Standard ML, for instance) allow executing the callback functions in the context of the callingfunction, not requiring the explicit state encoding. C++ programs using CUSP are thus significantlylonger than a comparable Standard ML program or a C++ program only using synchronous I/O.Besides the inconveniences, the asynchronous I/O has certain pitfalls that may cause bugs resultingin sporadic crashes of the program. Callback functions that are passed to an I/O function may eitherbe invoked later from the main event loop (e.g., when data has been received) or they may be calleddirectly from the I/O function (e.g., when a connection has been reset and it is clear that no moredata can be received). While debugging the game, one case appeared very typical for that problem: Tomulticast a message to list list of known players, that list is iterated and the corresponding send functionis called in each iteration. If one of the connections has been reset from the remote end, the sendfunction may immediately call the reset handler, which in case of the buggy implementation removedthe corresponding player from the list of known players. As that list is being iterated, it is not allowedto simply remove elements from the list as the loop may then overrun the end of the list, eventuallycausing a segmentation fault in most cases. Such problem can only be solved by explicitly taking care ofthe situation, e.g., by creating a copy of the list before iterating.Still, the asynchronous API seems to be a good choice. CUSP is designed for holding a large numberof connections which is inefficient using synchronous I/O. A general pattern avoiding many problemscaused by preemptive callbacks is to always call the asynchronous I/O function at the and of the currentfunction, preventing side effects with code after the I/O function call. Concluding, CUSP is a reliablyworking protocol with an API that initially requires some time and experience of the programmer tobecome aware of all consequences, but supports efficient networking applications.5 Evaluation 81
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 18 and 19:
ArchitectureCensus operates in epoc
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 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?