[crossfire] new metaserver

[Mark Wedel]

  As asked, here is my thought on this.

  To make typing this easier, CMS = chief (core) metaserver. SMS = slave metaserver

  There is one CMS.  All crossfire servers that want to be listed in metaserver 
output send there data to this server (exactly how - udp/tcp, and what to send 
is an open issue.  My thought is that the server should send most every bit of 
data the might be useful - after all, it's only sending an update packet once a 
minute or something, so the amount of bandwidth for that is trivial).  My 
thought is also that this should be an actual daemon like program - I think 
having it be up holds some advantages.  One being that the connections from the 
servers to it can be persistent (presuming tcp here) - that makes things a lot 
easier on the server side, and also replication side.  The only sites that can 
request data from the CMS are trusted SMSs.  The CMS serves the data in a 
relative raw format.  The CMS would also provide information on the SMS's, just 
like the server (haven't got any requests from this SMS for a while, etc).  The 
new CMS would need to be a bit more robust than what is there now.

  There are numerous SMS's.  The clients talk to one of the various SMSs.  These 
SMS's talk to the CMS to get their data.  The ideal case, IMO, would be for the 
SMSs to also be persistent program, and thus could just have a tcp connection to 
the CMS.  However, probably not any reason that the CMS couldn't just to a 
connection to SMS, get data, close connection.  Thus a php script could be 
written to get this data.  Probably a reasonable idea for the SMS to at least 
potentially be web based.  Depending on the web server and access a person has 
to it, the way it gets data could vary.

  For example, a php based one would just contact the CMS periodically (not 
necessarily every time it gets a requests - presumable it should have a cache 
file it uses - if the cache file is too old, then it gets new data from the server).

  For other people, that can actually run scripts on the web server, they can 
perhaps have a persistent script that is in contact with the CMS, and just gets 
the data and stores it as static pages.

  The client would ship with a file that lists the current SMS's as web 
addresses (given different people host them, you can't just have a URL like 
     
     http://myhost/cfservers
     
      - people may need to do things like 
     
     http://myhost/~username/cfservers
     
      or whatever).

  The SMS would have two bits of data from the CMS - the list of all the servers 
and their stats, which has obvious usefulness.  However, it would also have a 
list of the other SMSs, so that the client can update its lists of what SMS's 
are out there.  Thus, as long as a client can find one SMS, it can talk to it, 
and now get an updated list of all the new SMS.  Thus, as SMSs come and go, the 
client will automatically keep up to date and not have to rely on some other 
external site.

  If the CMS is down, the SMS's just serve the last data they have.  This data 
will eventually become stale, but with very limited traffic going to the CMS, I 
think DOS attacks against the CMS are much less likely.

A few other notes:

An agreement/usage policy for people that want to be SMSs is probably in order. 
  Probably the main bit of that policy is that it won't abuse the CMS (eg, 
behave correctly), but also that it has to serve the data it gets from the CMS 
in basically an unaltered state (can't drop servers it doesn't like, can't 
add/fake servers it does like, etc).

  Also, relative to the client getting the data, it should be served up in a raw 
form (eg, not html, but something easy to parse).  That said, the CMS can also 
make html output if it so desires, but that would be for human readable format, 
not for the clients.

  I think this takes various bits people have discussed but with some changes.