[messages] [Developers] Re: client-server architecture for VASSAL 4

Joel Uckelman uckelman at nomic.net
Thu Nov 24 15:07:34 MST 2011


Thus spake Brent Easton:
> 
> > G2. Let clients send data to each other as much as possible in V4.
> 
> 
> I don't believe the bandwidth used when playing games is particularly
> significant and running all Commands through a central server has the
> advantage of single threading the command stream and enforcing a fixed
> order of commands. 

There are some known ways of handling event ordering. One way is what
real-time strategy games do, another quite different one is what first-
person shooters do. It was long enough ago that I read about how these
are done that I can't summon the details at the moment, but I can tell
you that it's not necessary to have this stuff go through our server.
(On the other hand, it might not matter much in practice, as you say.)
 
> One aspect that does use a fair slice of bandwidth is Synchonizing with
> a game in progress. This could be handled by direct client to client
> communication, though sychonizing happens relatively rarely in general
> play. 
> 
> The model I had in mind that addresses both P1 and P2, is that every
> client has the capability of becoming the server for a game. Like the
> online play of shooters, anyone can start up a server on their PC and
> this notifies a central 'tracker' server that lists all available game
> servers, what module is running, is it open/closed/password protected
> etc. If the Server goes down during a session, the other attached
> clients 'talk' among themselves and 'elect' one of them to become the
> new Server. The current central VASSAL server would no longer host
> games, but take over the centralised 'tracker' role.

This is about the same as what I came up with myself:

A client creates a room on our server. Other clients can join that room.
Our server knows the IP addresses of the clients in a room, and notifies
each client of the IP addresses of the others. Each client tries to
connect to each other client (perhaps using a NAT traversal library). If
any client receives connections from all the others, it's capable of
being the game server. (I believe it should be the case that if any other
client is able to connect to a particular client, then all of them will
be able to, but I suppose it's safer to have them all try.) The clients
can elect an eligible client to be the game server, which they would
repeat in the event that the client hosting the game disconnects. If no
client is able to recieve connections from all others, then our server
can act as the game server.

The one problem I see here is that this doesn't actually solve P1, since
clients still have to talk to our server to find other clients. We need
more than one tracker, and then some way for each tracker to inform the
others about who is in what rooms. I can think of a few ways this could
be done---use a distributed database as a backend, have each tracker
notify others when an event occurs. Now, this pushes P1 back a bit
further, but still doesn't completely solve it---how does a client find
out the names of the trackers? We could hard-code them into VASSAL, but
that's a crap solution. My initial thought is to say that trackers will
have domain names like n.tracker.vassalengine.org, where n = 0 for our
tracker, and n > 0 for other ones. With that setup, we could even do
things like create DNS records on the fly to temporarily promote clients
to be trackers (which I understand is something like what Skype does for
routing traffic).

-- 
J.


More information about the messages mailing list