[crossfire] new metaserver

[Mark Wedel]

tchize wrote:
>
     
      Le Jeudi 2 Juin 2005 09:20, Mark Wedel a écrit :
     
     
>>
     
     1) Has someone agreed to run the metametaserver?  What about the slave
     
     >>
     
     metaservers?  While all this looks nice, if you don't have people willing
     
     >>
     
     to run it/take care of it, it is all pretty pointless.  For the
     
     >>
     
     metametaserver, I'm thinking more of the Tanner's, since they currently
     
     >>
     
     hold the main crossfire home page, but of course, the metametaserver could
     
     >>
     
     move someplace else (not as sure how many people have as stable and ip
     
     >>
     
     address and network connection that they do).
     
     >
     
     
     >
     
     
     >
     
      That's were a static list on various website is usefull, easy to place 
     
     >
     
      (crossfire.sourceforge.net could be a place to hold the list)
     
     
  Yes, but a static list != metaserver.  That is a seperate issue.  Certainly, 
having static lists isn't a bad backup plan, but isn't really the same thing.

>
     
     
     >
     
     
     >>
     
     2) having the clients connect to the various servers to get stats like
     
     >>
     
     current number of active players is IMO an extra level of complication that
     
     >>
     
     can be done without.  If we have a dozen active servers (which was actually
     
     >>
     
     low if I recall), you probably don't want to do it sequentially - that
     
     >>
     
     means it coudl take a significant amount of time to go through them all. 
     
     >>
     
     Especially if one is down or unresponsive.  this means you need to do it in
     
     >>
     
     parallel, and writing that threaded code is a bit more complicated.  Add to
     
     >>
     
     the fact that the client would then have to send some commands and parses
     
     >>
     
     the responses from the server. I just don't see any reason that dynamic
     
     >>
     
     info shouldn't be included.
     
     >
     
     
     >
     
     
     >
     
      could be done in udp (send a packet to each server than wait 2 second for any 
     
     >
     
      response)
     
     
  udp is probably not a good option.  Most peoples private firewalls will 
probably not work in that setup without changing the configuration (they'd need 
to be modified to let the return udp packet through the firewall).  So from a 
client perspective, we really want to just stick to tcp.