[glob2-devel] Net Rewrite

[Bradley Arsenault]

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.