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

Applications implement this interface and pass a reference to an instance of the implementing classwhen calling contactPeer(). The implemented class may carry any context information that is necessaryfor the application. Depending on the outcome of the contact operation, either onContact() oronContactFail() are invoked.4.6.3 Convenience Helper ClassesCUSP only provides unidirectional streams. So applications requiring a TCP-like bidirectional connectionhave to set up one stream for each direction. The typical approach is the following. The client (i.e., thenode that initialates the connection) creates an outgoing stream to the server (which is listening at acommonly known service). Additionally, the client starts listening and sends the corresponding serviceID to the server via the stream. The server receives the service ID and creates a stream to the client. Sincethis is a common pattern, the helper class BiDiConn implements the client side functionality, providingan easy-to-use bidirectional connection interface.Another common pattern is the single request-response cycle as typically appearing with an RPC call.For that purpose the two classes SingleCycleConn (client side) and SingleCycleServer (server side)were implemented. SingleCycleConn basically just provides the request functionality that takes therequest message as a string and returns the server’s response as a string. There are a few variants ofthat functionality for both synchronous (blocking) and asynchronous invocation. SingleCycleServerexpects an application callback that handles incoming requests and returns the response message (bothpassed as strings).Two additional helper classes are BufferedOutStream and AbortableContactHandler. The formeris similar to a normal OutStream but allows to write data in any state. It buffers all written datauntil the encapsulated OutStream is ready to write. The downside of using BufferedOutStream isthat the application does not have any information about how much of the data is already written.AbortableContactHandler performs an EndPoint::contact() call that is abortable, i.e., after callingits abort() method, the handler’s onContact() will not be invoked anymore.4.6.4 DiscussionThe mapping of the Standard ML’s API signatures/structures to C++ classes using IdBucket, handles,and C++ wrapper classes is surprisingly effective and problem-free after the basic patterns have becomeclear. Still, a lot of glue code is necessary for each new structure-to-class mapping, but always applyingthe same pattern, most of the work can be done by copying existing code.In contrast to that, the translation of the callback mechanisms has not shown to be satisfactory. TheJava-like way of passing callbacks suffers from the lack of anonymous classes in C++. Thus keepingtrack of the context still needs much extra code. A better alternative solution may be to use a C++signal framework like libsigc++ 10 or Boost signals 11 . These frameworks at least offer more flexibility tothe application developer, not requiring to implement a new class for each callback use. But still, thesedo not offer the convenience of closures.The development of the CUSP networking code for Planet π4 has shown that the development forsuch a heavily callback-driven API quickly becomes tricky as it is likely to produce bugs that are hardto discover. A main reason is that callbacks that are passed to a function are usually called later inthe event loop (e.g., after data as been received), but the callback may also be called immediately fromwithin the function, if certain conditions apply. One example is the write() method of OutStream. Whilein normal operation its callback is invoked later when all (or most of) the data has been transmitted, the10 http://libsigc.sourceforge.net/11 http://www.boost.org/doc/libs/1_40_0/doc/html/signals.html4 Implementation 69