[crossfire] new metaserver

[Mark Wedel]

Brendan Lally wrote:
>
     
      since the previous metaserver has shown itself to be unable to deal with an
     
     >
     
      attack, and since having a metaserver is a nice thing, I have over the last
     
     >
     
      few days been writing a distributed HTTP-based replacement. following a
     
     >
     
      design described on IRC by TechII and Tchize (among others).
     
     >
     
     
     >
     
      This system comprises of a series of metaservers and a metametaserver.
     
     >
     
     
     >
     
      The metaservers collect server information, and propagate it to the
     
     >
     
      metametaserver, and the metametaserver collates this and makes it available
     
     >
     
      to all the metaservers.
     
     
  A few questions on this:

  IS the idea to have DNS records for metaserver.crossfire.org (or whatever) 
point to all those possible/trusted meta servers?

  This of course doesn't really eliminate DOS attacks - it just means that 
someone has to attack 6 hosts instead of 1.  Which is an improvement, but may 
not eliminate the problem.  And while it runs on any web server is certainly 
convenient, it only does good if other people know about it of course (running 
it on mine does no good if no one knows about it, and if the main metaserver 
doesn't trust it)

  It seems to me that it would also be a better idea not to have a 
'metametaserver' at all - just go peer to peer, with the active metaservers 
periodically sending the data to one of the other metaservers (once a minute or 
something, it could connect to another, the two exchange information, merging 
any duplicates/keeping the later).  This removes the single point of failure if 
the metametaserver fails for some reason, at the expense of the data being not 
quite up to date.

  One other question I have is how the server sends its data to the active 
metaserver.  Does it still use UDP?  If not, and it uses TCP, be aware that 
you'll have to modify the server to fork, otherwise the servers can (and will) 
hang if the remote server is down or something.  Udp doesn't have that problem 
of course.

  In terms of data to provide:

IP address is a must.  Much easier for the client to already know the IP address 
instead of having to do DNS looks.  Hostname is then another field.

  As for the data:

  Version should be included in the top line, not the comment line, as it is now 
(one reason is that it is a compiled in value, so if you update your server, the 
version number reported will reflect this without having to go to your settings 
file and manually updating it.)  The protocol versions, IMO, are of limited 
value to most people (no user is really going to know what 1027 vs 1029 gives 
them, where they may know that 1.7.0 is the latest).  Plus, the protocol 
versions have been stable for a very long time.  Including it does no harm, just 
doesn't really add anything.

  Note you should look at the current metaserver for what data it sends.  For 
example, it also sends along the number of input and output bytes it has sent 
(useful for some scripts that collect that stuff) as well as how long the server 
has been up.