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

uckelman uckelman at nomic.net
Wed Nov 23 16:01:01 MST 2011

I've been kicking around some ideas about how to address some of the
shortcomings we've found with the current client-server model.

Things lacking presently:

P1. Our server is a single point of failure.
P2. Our server is a communications bottleneck.
P3. No straightforward way for anyone else to run their own server.
P4. Clients without the module can't get it from clients which have it.
P5. Clients can't leave game state "online" for other clients to pick
P6. No public API to let other programs query server status.
P7. No server-client protocol that other clients could be written

Some elaboration on these points:

P1 is something we've had a problem with repeatedly over the years:
There's a bad storm in Arizona which knocks out the power, a telco
junction box fills with water, the router between our host and the world
dies, a hard drive in our server dies, etc. All of these result in V3
being unavailable for online play (leaving aside the P2P mode, which I
take that hardly anybody knows how to use). That's frustrating for our
users. So, a goal:

G1. There should be no single point of failure for online use of V4.

P2 happens because whenever one client needs to send data to another
client, it does that via our server. Presently, the amount of bandwidth
we use for our game server is small in relation to what we use for
module downloads (this is something I want to measure properly sometime
soon, just to be sure, but my guess is that game server traffic is
several orders of magnitude less). Nonetheless, our game server has no
use for this data itself, and clients could just as well send it to each
other (so long as they have some way of connecting to each other).

G2. Let clients send data to each other as much as possible in V4.

P3 is something people have asked us about periodically; I believe the
main motivation for wanting to run one's own game server is to get a
more reliable, less congested connection. There's no reason I can think
of for why we'd want to block such a thing---so long as it doesn't
fragment the communities of people looking for games. So, I'd like to
address P3 with:

G3. It should be possible for others to run V4 servers. V4 servers
should share room information, by default.

P4, that it would be nice to be able to drop in to a room where you
don't yet have the module, is a request I've seen numerous times. With
G2 met, it would be possible for clients to send modules to each other
in most cases, without sending them through the server.

G4. Let clients send modules to other clients.

Regarding P5, it seems that various online game services store game
state and history for their players (and also notify them when it is
their turn). For a thread on this topic, see this thread on BGG, from
here onward[1]. Giving players the ability to store game state online
would eliminate the "send files" step of PBEM. I'm not at all in favor
of forcing people to do this---I still very much want local storage as
well---but I can see the utility of this for some people. How exactly
we'd implement it, I'm not sure. I don't want us to become responsible
for storing everybody's saved games for all eternity. Maybe we could let
the user choose what cloud storage to use as a backend, or maybe I'm
overestimating the size of logs (not as they currently are, but as they
will be for V4). So, there's some tension here between this goal, and
G1, G2:

G5. Let clients store game state online.

Many times we've been asked for a way for third parties to ask the game
server about its state:

G6. Create a public API for querying game server state.

Finally, P7: There's no particular reason why the game server should be
capable of talking only to the official, reference implementation of the
VASSAL client. People have expressed interest in having web-based
versions of VASSAL, for example; if we had a documented server-client
protocol, then anyone who wanted would be free to create such a thing
(or experiment with AI bots, or whatever else people can think up).

G7. Create and document a server-client protocol.

So, I have thoughts on how to accomplish the various goals, but first I
want to hear from people about what I've left out, whether these make
sense, etc.

Also, happy Thanksgiving, everybody.

[1] http://www.boardgamegeek.com/article/7877881#7877881

Read this topic online here:

More information about the messages mailing list