Re: CF: Telnet-interface for 0.95.1

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

On Jan 18,  3:13pm, Christian Stieber wrote:
> Subject: Re: CF: Telnet-interface for 0.95.1
> Anthony Thyssen (anthony@cit.gu.edu.au) wrote:
>
> > | So I took the 0.95.1 server and hacked around a little bit -- the result
> > | of that can be found at
> > |    http://www.informatik.tu-muenchen.de/~stieber/crossfire/Socket.tar.gz
> > | There is also a small documentation file.
> > |
> > Two things I think you should think about
> >   Documentation
>
> I don't think we need docs via an telnet interface?

 I don't think so either.  Most docs aren't formatted in text anymore either,
so sending them via the telnet doesn't do much good.  If this is really
desirable, it would be better for the metaserver to print the ftp/web sites
where the docs could be found.


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

 When the server starts up, it can do a lookup on that name (since we only do
the lookup once at startup, any timeout there isn't that bad).  The server then
sends some information to the metaserver(s), and also sends a udp packet to all
the servers periodically.  If the name resolves to one ip address, only sends
to one host - if resolves to multiple, send to multiple hosts.

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



>
> 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.  For example, I am
not sure if port 13326 is currently allowed through the firewall to whitestar)
also, this periodic packet could include other useful information (players
on line for example.).  So the metaserver could report something like:

 whitestar, 6 players, last report jan 18 1998 14:22


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

 Makes sense.

>
> 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
> to create webpages (it would get the serverlist from a metaserver,
> and information about an individual server from the server itself).

 The metaserver probably needs a few commands:

 servers (returns list) - used by client/players to see what is out there.
 info (server name) - return information (motd/info file) that the server sent
	to the metaserver when it first connected.
 iamserver (name,info) - server informs metaserver that it exists, and some
information about it.
 update (name, players, ...) - server updates metaserver about itself.


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

 Note that contacting the metaserver must be an option in the server code.  I
could see someone playing at home/work/someplace not wanting to advertise they
have a server up.

>
> Denial-of-service attacks might be possible by setting up a lot of
> connections to the metaserver, or flooding it with fake servers.

 Flooding with fake but real looking servers would be the most effective way.
You then might have a list of 1000 servers, of which 10 are real.  Packet
floods can always be done, whether or not a server exists.

 Fake server flooding can be minimized by watching ip addresses.  So to flood
the server with 1000 fake servers, 1000 ip address must be availabe to the user
(if the metaserver sees a connection from an ip address it already has a record
for, it just replaces the old one - this is needed in any case for when a
server is restarted).


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