Re: [glob2-devel] Net Rewrite

[Martin Voelkle]

> 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

I would go for SDL as long as it works. Boost could be a good idea.
But an unknown lib like GNE or ASIO could be a bad one.

> 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.

A few observations with this:
- secure public/private key generation can take lots of time (like >
10 seconds) there is no point in doing this every time. It can be done
just once for each installation.
- if you plan on generating on the fly, you can't do any valid key
fingerprint checks, so man-in-the-middle attacks will be easy
(compared to SSL/TLS m-i-t-m attacks).
- don't forget that there is no network protocol in wide use that
crypts all its communication using public/private encryption (too cpu
consuming). It is usually done only during the handshaking, to
securely agree on a symmetric key.
- there is a standard [1], called DTLS (Datagramm Transport Layer
Security), which is quite new (and unimplemented by most SSL/TLS
libs). This could be implemented  (unless it's too complicated).

[1] http://tools.ietf.org/html/rfc4347