Re: CF: Telnet-interface for 0.95.1

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

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

> > Hm... how about this: the server gets a list of metaservers (or just
> > one?). When it starts up it sends a "startup" packet to the
> > metaservers, and a "stop" packet when it is shut down. The start
> > packet contains the version number of the server (since this is
> > something you probably want to display in any case). Players can get
> > additional information via the telnet interface (all of this can be
> > hidden via webpages, of course).
> 
>  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 :-)

> > Maybe I should implement an "info" command to return more information
> > about the server than the "version" command:
> >   version
> >   maintainer
> >   (some) compile options
> >   list of additional maps
> >   general info
> 
>  some of this isn't not easily determined at compile time.  However, perhaps
> adding a 'info' file (or just using the motd) would work.  The server could
> send that along when it first connects to the metaserver.

No, I would be using an info file. Using the motd file is not a good
idea --- motd should be "human readable", whereas the info stuff
should be easily parseable, so you can turn it into html.

> > The metaservers, on the other hand, send "test" packets to registered
> > servers every five minutes (roughly --- no need for a strict timing),
> > to see if they are still alive (a server might have crashed and not
> > been restarted. It's probably enough to just connect to my 13326 port
> > and send a "quit".
> 
>  Probably don't want to do this.  Easier to have the servers send
> periodic packets to the metaserver, and the metaserver can then
> report the last time it got a packet from some particular server.
> Just as accurate, and potentially more reliable (for servers with
> some firewall protection, some ports may not be available, so the
> metaserver will never be able to connect.

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?

On the other hand, implementing your scheme shouldn't be to difficult
either --- after all, it's about the same thing as the current watchdog
mechanism.

> on line for example.).  So the metaserver could report something like:
> 
>  whitestar, 6 players, last report jan 18 1998 14:22

Hm... looks good :-)

> > A player command "meta" would give a list of metaservers that it has
> > registered with.
> 
>  Makes sense.

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.

> > The metaserver protocol would be much simpler: currently I only see
> > the need for a "servers" command, to return the list of currently
> > registered servers. Additional software would use that command
> 
>  The metaserver probably needs a few commands:
> 
>  servers (returns list) - used by client/players to see what is out there.

Fine. Includes the information provided in the "update".

>  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.  There were three reasons why I implemented
the telnet interface:
a) so I can make webpages showing information about the server without
   having to write a special client
b) so I can run my usual telnet session and talk to players without having
   to write a special client
c) to simplify "mr_log" and be able to make kill logs without having to
   write a special client (Steve's mr_log currently uses some ugly hacks
   to figure out whether a monster or player has been killed, and it
   requires setting up a player with a golden unicorn horn)

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.

>  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?

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.

> > Note that there are no provisions to prevent bad guys from setting up
> > fake servers. Preventing that would require a maintainer --- a person
> > who decides whether a server is real or not. Only servers that are
> > known to be real would be accepted by the metaservers.
> 
>  But this then reduces the usefulness of the metaserver some - a definate
> delay of some amount of time is then added between someone setting up a server
> and it going to the metaserver.

That's why I don't want to implement it.

> > Maybe we even want two sorts of dm: the "standard" dm which can do
> > things like summoning players, kicking and banning them, and the
> > "master" dm which can do anything a dm can currently do. This would be
> > interesting for servers with a lot of players, since some players
> > could get standard dm privileges without the really bad things.
> 
>  That may make sense.  something like a 'wiz' and then something like a 'dm'.
> The wiz has some additional commands available, and the dm then has the full
> set (wiz commands + other commands).




> 
> 
> -- 
> 
> -- 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]

-- 
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]