[crossfire] new metaserver

[Brendan Lally]

On Friday 10 June 2005 06:27, Mark Wedel wrote:
>
     
        A few more notes/thoughts:
     
     >
     
     
     >
     
        For the server, switching to tcp is perhaps a good thing.  What I'd
     
     >
     
      actually think is the best thing is there to be a small helper program that
     
     >
     
      the server executes, and then talks to that helper program then a named
     
     >
     
      socket (or perhaps just a pipe).  The server could send the helper program
     
     >
     
      things like number of players and any other dynamic data (for the static
     
     >
     
      date, the helper program could just read the settings file).
     
     
This seems like a nice idea, it has the added benefit of making it possibile 
to send data about servers that are down, (assuming that it keeps running, 
and new servers speak to it...) as well as those that are up. (if the server 
isn't updating data to the subproccess, then it could notify the metaserver 
that the server is unresponsive, which is probably more useful than having a 
server suddenly disappear from the list.

>
     
        But the fact is that if you want to make persistent connections, you
     
     >
     
      can't do that to a web server script I don't believe.  OTOH, I'm not sure
     
     >
     
      how quickly web servers will time out connections.  But it also just seems
     
     >
     
      inefficient to have to execute an entire script for each update - having a
     
     >
     
      persistent program is much more efficient in all its processing.  IT just
     
     >
     
      means you can't run such a program on any web server.
     
     
For a well configured web server, something like mod_php or zend or similar 
will be running anyway, the scripts will be acting like compiled code in many 
respects. It will still be slower than a well written independent program, 
but then that is the price that is paid for having a web server handle all of 
the availability stuff.

>
     
        Just one other note - having something done first does not mean that is
     
     >
     
      the way to go.  
     
     >
     
      'xyz has done this so you should use it' holds no weight to me. 
     
     
Which is why I didn't do it first, what I have done is mostly just a couple of 
php and perl scripts, which use libraries to deal with the connection issues, 
should they end up doing something vaguely similar to their current function, 
the changes are mostly changing port numbers, and maybe a couple of lines of 
function calls.

>
     
        As said, this doesn't reflect on the code in the patch - I haven't looked
     
     >
     
      over that closely enough to make any comment on it.  But I will make the
     
     >
     
      comment that it seems to be missing the server -> metaserver notification
     
     >
     
      piece, and IMO that is really the core piece, because that is the one where
     
     >
     
      the most problems can arise 
     
     
This was the reason that I hadn't done that before starting this thread, as 
you say, that is the core piece, and also the one that is likely to be very 
specific to the actually form of the implementation. So I was going to leave 
it until last.

By comparison, however the final system is implemented, the client /will/ 
connect to a server and parse some information recieved from it. However that 
server is configured, libcurl can pretty much cope, so writing a fairly 
generic parser attached to libcurl is a nice base to begin from, should 
libcurl be disliked as a dependancy, then it is simply a matter of adding the 
appropriate socket code later.

>
     
      (eg, you can't cause the server to block, you 
     
     >
     
      don't want a slow update time, but you still want to provide dynamic data. 
     
     >
     
      The small helper program I mention above is probably the way to fix that,
     
     >
     
      and actually should be pretty easy to do).
     
     
[notwithstanding the paragraphs before this one.]

It seems to have been mostly done already.... 

watchdog when it is compiled in has the server send UDP packets to a local 
socket. AFAICT it doesn't really matter to much /what/ it sends, so it might 
as well send the data that the metaserver will use, in that case then the 
program you describe would end up looking similar to 
crossfire/utils/crossfire-loop.c (though maybe in perl?)

The only problem I can really see is that such an approach would probably fail 
on a windows system.