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

Brent Easton b.easton at exemail.com.au
Wed Nov 23 21:44:23 MST 2011

> P1. Our server is a single point of failure.

V3.2 does address this point somewhat, but it is still a patch up of the
existing system rather than a redesign. I did several things to help in
this area:

1. Substantially remodelled the user interface to the servers. Add
drop-downs to select server type and an Address Book, Using the P2P
server should be much, much easier now.
2. Finished off Rodney's work on using Jabber Servers as Vassal Servers.
This should work (theoretically), allowing any Jabber (XMPP) Server that
supports Multi-User Chat (MUC) to host a Vassal game. 

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

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

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.

Read this topic online here:

More information about the messages mailing list