From: Bill Kelly <billk@...>
Date: 2005-12-02T15:23:02+09:00
Subject: Re: Quality of Ruby Implementation ?

Hi Stephen,

From: "Stephen Waits" <steve@waits.net>
> 
>> It uses TCP and UDP networking, and keeps a fairly large dynamic
>> in-memory data structure (100 megs or so)... I also dynamically
>> reload code modules without quitting the application on a periodic
>> basis, when adding simple new features or making bug fixes.
> 
> Just wondering if you're able to share more about your application?   
> It sounds interesting.

Thanks - well, technically there's a rubyforge project:
http://rubyforge.org/projects/dorkbuster/
But the documentation is very meager / nonexistent.

Also, I've learned a bit about Ruby since I first wrote it,
so I wouldn't recommend some parts as shining examples of
good idiomatic ruby code; especially the parts using threads
and mutexes.  (Some modules could be simplified quite a bit.)

I'd design some parts of it rather differently if I were to
do it over. . . . Etc.

Pragmatically speaking, though, it works.  :)  Multiple admins
are logged into it at any given time to monitor server activity
and watch out for cheaters.  We've been using it for about three
years now.

A brief overview of what it is/isn't:

  - Allows multiple admins to log in over telnet and monitor
    quake 2 servers, and issue bot scans and rcon commands
    without admins knowing the actual server rcon password.

  - Provides an optional "windowed" interface using ANSI
    telnet scrolling regions, and supports line editing and
    command history.  (No tab-completion, yet.)
    Windows show admin chat, live server status, and raw
    server log data.

  - Keeps a database linking player names to player IP's,
    and shows a sorted list of most recently/frequently
    used names for each player connected.
    The database is currently stored in-memory (checkpointed
    to disk on a periodic basis), and can get quite large.
    I've intended to switch over to a traditional database
    engine (sqlite/mysql/postgresql).

  - Provides hooks for "droids" (like IRC bots) to connect
    to the admin system and provide additional functionality,
    such as bot scans or running player-driven map rotations.
    (The map rotation droid is provided with the project.
    The bot scanners are private, as it's difficult to stay
    ahead of the cheaters.)

  - Currently, no *automatic* cheat-detection scans are 
    performed.  (We use a third-party module on our servers,
    q2admin, to provide some level of cheat auto-detection.)
    Strange as it may sound, the lack of automated scans in
    dorkbuster is somewhat by design.  I think the key reason
    dorkbuster is actually effective is the presence of
    multiple human admins monitoring the servers pretty
    much around the clock.  So db's design has been focused
    on providing a collaborative environment for live admins.
    Some automated scans might be nice - but not if the result
    were to reduce the level of human participation.  So we'll
    proceed carefully. . . .

  - As yet, no way to monitor multiple servers from a single
    telnet window.  This is at the top of the to-do list.


Thanks for your interest.  I'm happy to answer questions either
on or off-list, as appropriate.


Regards,

Bill