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 http://mmondor.pulsar-zone.net/