Re: CF: Telnet-interface for 0.95.1

[Christian Stieber <stieber@informatik.tu-muenchen.de>]

Mark Wedel (mark@icp.siemens.com) wrote:

>  But also, if the metaserver is sending packets, it could get frozen (if
> connecting to the telnet port, the metaserver could end up waiting a few
> minutes if that remote host is down).  Now this can be gotten around by
> threading or other ideas, but starts making the metaserver a bit more
> complicated.

Hm... sounds reasonable. Anyway, no problem with UDP, and a good reason
against TCP :-)

> > >  info (server name) - return information (motd/info file) that the server
> sent
> > > 	to the metaserver when it first connected.
> >
> > Why? Well, I guess the question is whether the telnet interfaces makes
> > it into the servers. If it does then there is no need for that, since
> > people can always ask the server (the metaserver just points to the

>  The point being lets make it easy for players to examine some of the basic
> stats about the servers.  For example, it could be argued that there is no
> reason for the metaserver to know the number of players on each server.  But as
> a player, I may want to go to one which has other people, and if I can get that
> information from the metaserver via a simple command instead of having to
> telnet to half a dozen (or potentially a lot more servers down the road) and
> doing the who, that makes things easier for me.

Sounds ok. However, the original idea was that players don't actually
telnet to the servers. Instead a bunch of CGI programs would handle
these things.  I already have a little program that uses my telnet
interface and prints that information to stdout --- which can be used
by CGI scripts to create webpages. So players would, for example, access
http://www.crossfire.org/servers.cgi and get a list of servers. I already
want tp include the current player count in each update packet, so the
player would get a list of servers, the number of players on each server
and the last update time. There could be "hiscore", "who" , "players",
"motd", "info" buttons for each server --- or the list could be a scrolling
list (instead of a table), so players can select a server and press
the button to get the correspoding information. The CGI script on the
webserver would do the telnetting. That's also how the who and hiscore
webpages for my server are created.

>  char	*name;	/* name of server */
>  int	ipaddress;	/* ip address */
>  time_t	last_update;	/* last time we got a packet from this server */
>  int	num_players;	/* number of players reported on this server */
>  char	*info;		/* information the server provided when it connected */
> 
>  Now the info value should be pretty much static (compile options, maps, and
> other stuff as you said), so the server only has to tell the metaserver about
> it once when it connects.  The num_players get sent by the remote server, and
> whever the metaserver gets a packet, it can update last_update on its own.

Sounds fine. :-)

> > list. An "update" is sent by server approximately every 5 minutes
> > (hm... UDP packets should be cheap. Maybe 3 minutes), so a few of them
> > can get lost before the metaserver thinks the server is dead.
> 
>  That makes sense.  However, 15 minutes seems a bit quick.

Quick? Okay, if you say so :-) I just think it's funny how different people
see things differently --- I sort of considered 15 minutes to be ages,
but didn't want to send updates too frequently :-)

On the other hand --- when I'm thinking about it: crossfire is not like
xblast --- it's a long-term server. It doesn't make sense for a
crossfire-server to pop up for 5 minutes or so.

Christian


-- 
Christian Stieber        http://www.informatik.tu-muenchen.de/~stieber
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to crossfire-request@ifi.uio.no]