[crossfire] Metaserver info, was Re: Crossfire+/Crossfire2 Versioning and Metaserver

[Mark Wedel]

Alex Schultz wrote:
> mwedel at sonic.net wrote:
>> <snip>
> The proposed fields you mentioned look good to me. One other quick
> thought, is perhaps the "codebase" fields should have a flag or other
> standard way of representing the case of something being mostly of a
> "codebase" but with a minor patch or two.

  codebase, like most fields, would be free form.  So one could be something 
like 'standard + a few custom maps' in for a codebase - pretty clear there.  I 
think the issue here is more what people should put in for codebase.  I'm not 
sure if special flags are needed.

> 
>>  Another question related to this is whether we should re-do the
>> metaserver connection method all together - in shorter term, the servers
>> could use both new and old methods to report data, but then at some
>> point, they only use new method.  There were discussions in the past
>> about this - I bring it up now, because if we add all these new fields,
>> it may make it hard to keep things compatible.
> And another thought, is if it would be worthwhile for a redone
> metaserver connection method to actually be a distributed metaserver as
> was once thought about a long while back. I'm not sure that would be
> good, but if the connection method were to be redone, it would be worth
> thinking about those sorts of things.

  In my ideal case, which I believe borrows a lot from that discussion, would be 
to have metaservers web based (http).  That makes it so that most anyone can set 
them up (everyone probably has a web page, or can get one with cgi-bin, but 
being able to run a persistent server that listens to some port is a lot 
harder).  Also, it being web based takes care of parallelism for us - the web 
server would launch multiple copies.  My initial thought is that a fairly simple 
php script that handles the requests (and can also provide a page) and storing 
the data in a mysql would do this, and both are pretty standard functions. 
mysql may sound like overhead, but has the advantage that it in a sense takes 
care of file locking for us.

  All of that is actually pretty easy to do.  The harder part is the 
synchronization between metaservers - or maybe we don't care.  Simplest thing is 
that on both the client and server, you have a list of of metaservers to try.

  Each server will try to update all the metaservers.  If a metaserver is down, 
it obviously can't update it.  However, a pretty basic method can be used so 
that it tries periodically to send it updates, so when it comes back alive, it 
would start getting updates.  Remember also that the down metaserver will still 
have its old data when it starts up (sitting in that database), so it would 
really just have stale data, not missing data.

  For clients, it would choose one of the metaservers from the list, randomly. 
There could be an override for players that really know what they are doing (eg, 
the routing to metaserver B sucks, so I always want to use A).  If the client is 
unable to connect to a metaserver, it tries the next one, etc.

  Note that the web side doesn't have to be php - it could be perl or most 
anything else, but if it gets too obscure, that sort of eliminates the ability 
for it to be easy for a wide number of users to set up.

  Also, there could be a second database that the metaserver has, which is 
blacklisted hosts.  These would mostly be used for misconfigured servers that 
are sending bad data to the metaserver.  So simple matter to add into that 
table, and server is now blacklisted.

  The most complicated part about all of this is that it is a tcp connection for 
the server - that can time out (the server can not open it at start up and hope 
it stays open forever), so a helper application that runs on the same host that 
the server relays (proxies) through would be used.  This could most simply be 
done via pipe with popen.