On Wed, 06 Dec 2006 10:54:55 -0500
akb+lists.netrek-dev at mirror.to (Andrew K. Bressen) wrote:

> One other question: if your server is a bot server, would it make sense
> to have it also be a base-practice server? IE, could you drop the minimum
> rank for a base to Ensign, and cut down the base recycle time? 

I just set SBRANK=2 (lt. commander, default was 3 == Commander), and
SBPLANETS=3 (default 5, which was the number of planets required to take
out an SB).

As for the recycle time I didn't see a keyword for it in the
configuration file, and would have to check the code to find out if
there's one.  There's also BASEPRACTICE which is currently disabled (0)
but I also would have to look at the code to know what it actually
does...  From a quick grep I suspect that hardcoded BUILD_SB_TIME in
defs.h might be the SB recycle time (and teams[me->p_team].s_turns) but
I didn't look more into it yet.

> > As for my server, if the metaserver comment field really worked, then I
> > think that my server could probably remain listed at all times and be
> > marked "practice borg server", as it's all it really is.  
> How hard would this be to make work? Is it a client issue, 
> metaserver, or both? The metaserver rewrite stuff sounds great
> in principle, but this one change sounds like it would have
> a notable benefit.

It probably would require minimal changes to client, server and
metaserver.  However, to keep compatibility for old clients what could
be done is add a new metaserver port to serve the new enhanced report
and leave the old port serve the old/current format, and have new
clients query that new port.

It would be possible (although considerably more work) to have the new
port require an HTTP 1.0+ request so that it could also serve for future
formats, the chosen version report and format sent could be based on
requested path, User-Agent, or some new custom field like
Metaserver-Version...  This would even allow to send an HTML report to a
browser.  Similarily, servers could send more information fields, and if
necessary the same new metaserver port could be used and support
multiple versions, using POST...

Actually, such a system would be easy to implement as a CGI on an
existing HTTP server as well.  SYSV shm would allow the CGI to
query/access the metaserver in-memory table.  Would it however be
reasonable to assume that a metaserver also runs an HTTP server?  Would
the CGI be considered slow because of the extra-forking, in which case a
FastCGI module would also be necessary, or some other kind of module?

New metaserver code could also be written from scratch in a high-level
language available as a module for apache (i.e. mod_php, mod_perl).
Alternatively, many high level languages also support HTTPd connector
modules, transforming easily a program into an HTTPd.  Would the
necessary requirements of using a higher level language (and the
associated higher overhead) be acceptable to metaserver admins?

If a minimal C HTTPd was to be embedded with future versions of the
metaserver code, it would need to cope properly with concurrent
bi-directional requests, possibly using non-blocking I/O in a single
process to minimize overhead rather than multiple threads or
processes...  It also would need basic flood protection (concurrent
requests allowed total and per address, requests frequency per address
and per request class).  And possibly support for blacklists.  But then
again this requires time to write and debug, which someone who cares
enough would have to put in...

Just a few ideas thrown in for inspiration.

Matthew Mondor