[crossfire] new metaserver

[Brendan Lally]

>>>
     
     
      mwedel at sonic.net
      
       05/27/05 07:08 AM >>>
     
     >
     
       IS the idea to have DNS records for metaserver.crossfire.org (or whatever) 
     
     >
     
      point to all those possible/trusted meta servers?
     
     
There are two lists, the game server list and the metaserver list.

Each metaserver has a copy of both lists, that they sync with the metametaserver.

when a client connects, they have their own list of metaservers (that will be install with the tarball) and  they pick randomly a metaserver from that list. From that metaserver they get a list of servers, and a list of metaservers. In future they use that new list to pick randomly from.

When a server connects they have the same list of metaservers, and they pick a random 'active' server and send a get request to 
     
     http://metaserver/addme.php?name=server
     
      name&version=server version&comment=whatever they want to appear in the comment line&ip=their hostname[unless they want to use their ip directly, in which case this field is omitted]

they then fetch the list of metaservers, and use that next time.

>
     
       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.  
     
     
This is true, but all that is required for the system to resurrect itself is for one of those servers to return. If that happens, then each client will eventually hit that one, and then they will get the entire new list of servers.

1 server out of 6-12 surviving a DoS attack is quite a reasonable expectation, especially since it is using HTTP which it is possible to make quite well hardened against such things.

>
     
      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)
     
     
Yes, once you have a metaserver running, you would email the metametaserver admin, and say 'hello, I have a new [active/passive] metaserver it can be accessed as [ip adress or hostname] and updates via [ip adress or hostname] (those may or may not be the same.

the list of metaservers would then be appended to include your metaserver, and the ip adress you use for updates would be let through the firewall around the metametaserver.

This assumes that we trust you :)

>
     
      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.
     
     
I considered this, but I couldn't see a nice way to add new metaservers securely (bearing in mind that without some form of checking, a hostile server could crapflood the other servers into uselessness). All methods that were sane to implement would use a central auth server anyway. If that is the case, then you might as well connect to it to send the data too, since it is going to be there anyway.

If there is a way around this that I haven't considered, then let me know.

It also may increase traffic quite substantially compared to a system where each server expects to have ~ (number of hits old metaserver had on average )*2/number of metaservers + some updates sent out to the metametaserver.

should the metametaserver fail, the individual servers will act quite autonomously for a while, they simply need to updated to point to a new metametaserver. It is easier to change a line in a dozen known copies of a perl script than to change a DEFINE in a thousand unknown compiled C programs.

>
     
       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.
     
     
Yeah, it'd use TCP, it has to to connect to a webserver I'm toying with the idea of using libcurl directly to handle most of it, this is fairly quick and easy, compared to implementing HTTP manually, but it does add a new dependancy (albeit a common one). The alternitive is to write directly to the socket. 

But certainly for the server starting up and forking to have the metaserver be contacted should be fine, it would just then travel randomly down the list of metaservers until it finds one that returns a 200.

It should be quite easy to have a lock file setup to ensure that the metaserver requests don't overlap..


>
     
       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.
     
     
This is a fair point. Maybe forcing the use of ip adresses is simpler....

The 'name' field already exists, I guess a check should be made then that if the name field is a valid hostname (as opposed to just a server name) that it resolves to the ip given.

>
     
       As for the data:
     
     
>
     
       Version should be included in the top line, not the comment line, as it is now 
     
     
The point of the bottom line is that it is what the player 'sees', it isn't needed for the client to connect to know what release the server is running. A player however, will want to know which version the server runs, so it will go on the bottom line, as player-known information.

>
     
      (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).
     
     
If the protocol changes, such that it breaks against older or newer clients, then the client will be able to compare the protocol entry and simply not show those that are of the wrong version.

The player will never see it (it is on the first line), but nor would they be forced to update, or know the version numbers that their client will work with.

This information is also acquired by the metaserver, it connects back to the ip and port it was given, and checks that the banner says 'crossfire' in it.

In theory crossfire derivatives could use the same system.

>
     
       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.
     
     
Do any scripts actually collect that? I can't say I've noticed it being used, if it is wanted though, it can be added easily now. (adding it later, is more interesting....)

Uptime is an interesting one, if nothing else it could allow netcraft-style uptime graphs on the metaservers..... (would require archiving the files though, and storage requirements may break that, a ~500byte file every few hours is the sort of thing that makes webservers hit their quotas....)