While trying to completely convert the code to the new system of headers, I ran into the Network code. The Network code uses the SessionInfo class generously. From what I can determine, BasePlayer (stored in SessionInfo) stores IP addresses and socket information.
This means that pretty much all net code goes through the SessionInfo class, and will its analog, GameHeader. But being that I'm trying to completely switch over the semantics (rather than having a partially complete change), this means that rewriting a good chunk of net code is going to go with it. Being that the Net play engine is the single largest sub system in Glob2 besides the game engine itself, (and because I am not an experienced net programmer), I figured that we should discuss and finalize the design scheme for the net play engine. So, here are the points: 1) Sockets, SDL? Boost? ASIO? Or perhaps GNE? SDL is going to be low level, but like much in SDL, its simplicity is its own reward, things just work. GNE is sort of a mid level API. I had discusses with the GNE developer about making GNE a co-project with Glob2, and Glob2 net classes could instead be done generically in GNE, which would better both worlds. Boost has excellent asymmetric design paradigms (which is what we need), and being Boost, its developed and discussed by allot of people 2) Communication: A while ago I figured that a message system could be done at the highest level. Each message would have its type, and its body. Currently, all messages are implemented in terms of the Order class, but I would rather have Order class under this higher level messaging system. Order classes could then be limited to just glob2 engine stuff, without net code seeping in, and messages like PlayerDropped could be sent through the higher level messaging system, without interrupting the transfer of Orders. 3) YOG - YOG should be its own separate sub system, derived from the message system shown above. YOG handles a few things: 1) Maintaining a list of games and connected users 2) Transferring IRC channel information to the client 3) Providing a server for NAT traversal 4) Provide a gauge for calculating approximate latency 4) State system - This is where things start to get tricky. There are 2 different areas of a Net connection, in the group menu before a game, and inside the game. In each, the following can occur to the player: 1) A Player pings out (120 seconds) 2) A Player disconnects 3) A player sends a message 4) A player connects 5) The host disconnects 6) The host starts the game I've probably missed several, but for all the code I have seen to handle these, these are pretty much the 6 events that occur in a connection. And the entire code can be simplified to one class that manages all of these (maybe two for the host stuff), and one interface class that goes between the GUI and the net code, and one interface class between Player and the net code. I also suggest that we might want to perform encryption. Live public/private key generation (on the spot), both of which are transferred before the game (unsecurely), and further communications can be encrypted. Its very basic, but the fact that there is no permanently stored public/private key pair makes it a bit more difficult to work around. And all code that transfers data for net is going to be optimized to load into as little a packet size as possible. -- Really. I'm not lieing. Bradley Arsenault. _______________________________________________ glob2-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/glob2-devel
