Re: CF: Telnet-interface for 0.95.1

["Mark Wedel" <mark@icp.siemens.com>]

On Jan 19,  3:13pm, Christian Stieber wrote:
> Subject: Re: CF: Telnet-interface for 0.95.1
> Mark Wedel (mark@icp.siemens.com) wrote:

> >  There should ideally be a known metaserver name.  that name may resolve to
> > multipe ip addresses.
>
> Yep, but the problem with that is: can anyone install this? My idea was
> to just have a file (crossfire/lib/metaservers) with a list of metaserver
> names. Of course this doesn't conflict with having one known name, since
> that known name can be part of the list :-)

 The person who is controlling the 'main' metaserver controls this.  For
example, if the metaserver is metaserver.pyrsonal.org, then it would be up to
me to update the DNS records for pyrsonal.org so that metaserver resolves to
multiple IP address.

 Note that the number of metaservers, and how often they change, should be a
lot less frequent than the number of crossfire servers.  Metaservers should
also be more reliable, as they are much simpler programs.


>
> Hm... I never cared about this :-) If somebody can open up port 13327,
> why shouldn't he be able to open up port 13326 as well?

 Depends on the firewall configuration.  Most firewalls limit what
ports/packets can come in, but allow anything out.  So letting another port
come in requires a change in the firewall configuration, where as sending
packets out requires no change.

 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.


>
> Well, I don't really know _why_ it makes sense :-) I just like to have
> commands that tell me who is hooked up to the server and (constantly)
> receiving information, to avoid "anonymous watchers". The 'logs
> command (to give a list of kill-loggers) makes more sense to players
> --- and it should prevent people from running their own loggers just
> because they don't know whether there are already some available.

 In most cases, there isn't a problem with the server reporting information it
already has.  For example, there are commands that show the memory usage - may
not make sense from  a player perspective, but the data is there and we let a
command show information about it.

>

> >  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
> servers, but doesn't need to know much about them), instead of going
> through the metaserver.

 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.

 Also, I can't see that info file being more than a few K.  So even if the
metaserver is watching 1000 servers, that is still only a few megs of ram.



>
> I just like to keep things simple --- since the server already provides
> that information, I don't want to make a complicated metaserver that has
> to provide the same information as well.

 As I see it, the metaserver has a struct something like this for each server
it is watching:

 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.

>
> >  iamserver (name,info) - server informs metaserver that it exists, and some
> > information about it.
> >  update (name, players, ...) - server updates metaserver about itself.
>
> That's the server-metaserver interface, which is different from the
> metaserver-'human" interface?

 Yes.  Up to you whether the server->metaserver should use a different port
than the player->metaserver interface.

>
> I would prefer a different approach here. The "servers" command should
> be available via telnet (i.e. a TCP stream), and work the same way my
> "stage 1" commands work: it returns the list of known servers, the
> information it knows, and closes the connection. The "update" command
> is an UDP packet --- if an "update" is received for a server that is
> not known yet, it is added to the list. If no "update" is received for
> 15 minutes or so, the server is considered dead and removed from the
> 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.   Since the
metaserver can display the last time it heard from the server, I think it
can be a bit more generous (a few hours), and the player can decide if it wants
to take a chance on some server.


-- 

-- Mark Wedel
mark@pyramid.com
-
[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]