Networking Design Goals

After some good discussion with myndzi, we're closing in on a final specification for the NullpoMino protocol. I'm probably going to drop the dual-protocol idea I'd originally had purely because, as myndzi pointed out, it causes extra points of failure and this hybrid sort of protocol we developed should be able to take care of everything both of my old protocols would have.

The protocol is going to be a lot more generalized this time around, because we're going to have to support things that aren't the game (remember, the plugins are going to use the network communicator to connect to the server as well). We're looking at a protocol that is loosely designed around IRC's protocol, obviously expanded to allow for greater functionality since we're playing  puzzle games and not just chatting.

Some of the things we want out of this protocol are:

1. Decoupling of server and client based on version. Potentially, you can play over lower server versions. myndzi also had the idea of public key cryptography allowing us to update the server based on clients, but we're not sure if this is just wishful thinking.
2. Some sort of ascii/binary stuff. This is helpful because it allows us to transfer files without much of a hitch, but it also allows us to pack bits for the game protocol and save tons of bandwidth.
3. On a higher level, we want to have better rooms. A while back, myndzi came up with a great idea where we can have channels, where players are in as many as they want to be, and the channels have flags, one of which means that it is a game channel. Rooms will be able to have owners and can be permanent, invite-only, or a number of other things. People will be able to have clan channels, now.
4. We want the ability to either send data right away (live data) or wait until we don't have to worry about bandwidth in order to send something large, which could potentially block the socket (bulk data). Before, I'd thought about running a messaging protocol connection for the former and a transfer protocol connection for the latter, but now the server can treat them the same way. The network communicator also doesn't need to use two sockets if it doesn't want to, although it can.

There's more coming soon, which I'll be putting up as soon as we finalize the details.