Hi Stephen,
From: "Stephen Waits said:
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
