Greetings:
I would like to provide a brief overview of the GNUWorld project.
Specifically, I would like to describe the two different client
modules, as well as the server core, and bring everyone on the list
up to date on the current status of the project.
As gnuworld has been adopted as the server architecture for the
channel services bot by the Undernet, I believe here on c-c is an
appropriate place to discuss any features, bugs, suggestions,
internal workings of gnuworld or any of its clients. It is my
intention that gnuworld be as open and public as possible, and the
more people who can participate in its development will only make it
a better product.
Now, on to the current summary reports for each of the key gnuworld systems.
GNUWorld Server Design Overview
------------------------
I have seen that many developers are not completely in sync with the
overall design of the gnuworld server core. Of course, this is very
important :) So here it is.
Start with a single class, called xServer. This is the gnuworld core
server. It is responsible for connecting to the network, and
handling all server command messages (NICK,JOIN,KICK,etc). In doing
so, the xServer class also maintains many of the system data
structures (such as glines).
The xServer class also is responsible for the majority of the system
decision making. This was done deliberately and persistently
throughout the 4 year development process to reduce system coupling
(the strength of dependencies between classes). As a result, the
entire gnuworld server system and all of its modules (some 42k lines
of code, including comments) have exactly two (2) global
variables...and one of these variables is a convenience variable, an
output stream used for logging purposes.
The xServer is also responsible for each of the client modules.
Client modules can be loaded dynamically from shared modules (and
now, even from static archives). Each client module is represented
by a pointer to a base class called xClient. The xServer maintains
an internal data structure of xClient objects, each representing a
services client that is loaded and visible to the rest of the network.
The xClient base class provides the functionality that would be
expected of a client, or bot. Such methods as Join, Part, Wallops,
Op, Deop, Kick, are all provided by this base class.
The xServer communicates with xClient via an event posting system.
When an event occurs on the network, the xClient is notified (if it
wants to be) by having one of its methods called, such as OnWhois()
when someone performs a /whois on that services client, or OnInvite()
when someone invites the services client to a channel. In addition,
the xServer provides event registration and distribution systems for
channels and system events, such as a client or server joining the
network, a gline being removed, etc. There is also a timer system
available to client developers.
To build a new services client, a developer needs only to subclass
xClient. The xClient base class handles all of the xServer<->xClient
interaction, such as reading the client config file, getting a proper
numeric, and registering the xClient with the server. This allows a
client module developer to simply subclass xClient with a class of
his/her own, and add that class to the server config file to be
loaded. I created a completely new (although it didn't do anything)
services client for gnuworld in 11 minutes.
Server TODO List
------------
The configuration system needs some work, and has been receiving
quite a bit of attention from users and developers alike. The system
now uses libltdl, which allows loading of client modules from static
archives, on some systems. This is still in development.
The code that handles the unloading of clients is incomplete. A
design is in place, but the work remains to be implemented.
A few other systems, such as Jupe and Gline need a bit of updating
with the changes made in recent versions of ircu.
---------------------------------------------------------------
Here is some info from the developers of the two largest client
modules, ccontrol and cservice. First is the ccontrol module info,
written by module lead developer Tomer Cohen (|MrBean|).
Project : ccontrol, network operator services
--------------------------------
About a year ago Dan Karrels (Aka ripper) started wroking on the
project, at first the project was writted to satisfy users who wanted
a uworld client for gnuworld framework. About four month ago I
(|MrBean|) joined the developers team of gnuworld and took the
project upon myself,
with the help of isomer who helped me out with suggestions and
undernet policy , and ripper who helped me with the coding and core
addons.
Status :
-----
Ccontrol is being tested on three different networks , although they
are small (one of them is the testnet for undernet) it look stable.
The great advantage of ccontrol is that it uses an ACL system, each
oper can have his own set of commands he's allowed to do as decided
by admins. It uses postgresql as its backend database , every
command which is issued is logged to the database and sent once every
24 hours to a certain email which is decided by the admins.
Developing Team
------------
|MrBean| (Tomer Cohen) - <mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]
Ripper (Dan Kerrels) - <mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]
Contributers
---------
Isomer - (Perry Lorier) <mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]
All bunch of users who helped in the bug tracing / reporting
TODO
----
* Workout the gline policy of undernet regarding hosts / max time for
gline and forcegline,
right nowi implented the things i got from isomer, but still need to
have the official ones from the admins.
* Add an option to gline an entire channel / mark channel as a bad
chan (gline #chan)
* Fix some minor bugs and code cleanup
* Come up with a better name than "ccontrol" =P
Long terms plan
-----------
* Add a dynamic configuration option for certain settings needed to
be set from the shell now
* Add a website access for users to see why they were glined , and
for opers to change varius account options
---------------------------------------------------------------
Here is the info on the cmaster project, whose client module name is
actually cservice. The main lead developer is Greg Sikorski (Gte-).
CMaster Channel Services Module (channels.undernet.org)
A Brief History of Time
~~~~~~~~~~~~~~~~
Starting January 2000, a team of CService Admins and Coder-Com
Developers began looking for a suitable platform to implement the
newly designed channel services schema. GNUWorld had recently
undergone a number of testlinks to the Undernet and had proved
itself to be stable and provided the neccessary API level for the
development of a channel services Bot.
CMaster (mod.cservice) was the first purpose-built module for
GNUWorld, and also uses the PostgreSQL database API to access a
backend database server.
Using the original service's layout as a template to make the
transition for users easier, work began on developing and testing the
new bot.
All in all, it took around 3 months to develop up to the point where
it was fit for a live trial. During the 3 months the bot was tested
extensively by CService Admins and Representatives, with suggestions
and bug reports coming in at around 5 per day.
Current Status
~~~~~~~~~~
CMaster has been linked to the undernet and running well for the last
3 months, with patches being applied and updated rougly every 2 weeks
after testing is complete. The longest uptime so far before a manual
restart is 17 days. Currently, it is up to "Release 1.0pl5"
Some vaugely interesting stats for those who want them:
* On average, after 4 days uptime with no cache-expiration, CMaster
uses ~2% CPU on a PIII-800 and ~120mb RAM. There are around 40,000
access level records cached and rougly
20,000 bans at any one time.
* There are on average 20-30 SQL queries/commands made to the
Database per second, even after
several days caching and updating.
* X <-> Postgres Database traffic averages at around 44 kbits/sec
in/out, and around 300 kbits/sec within the first hour of being
reconnected to the network.
* The entire database with indexes currently uses 265 meg of diskspace.
Client Development Team
~~~~~~~~~~~~~~~~~~
Lead Developer:
Gte - Greg Sikorski <[EMAIL PROTECTED]>
Developers:
ripper_ - Dan Karrels <[EMAIL PROTECTED]>
Isomer - Perry Lorier <[EMAIL PROTECTED]>
Contributers:
Plexus - David Henriksen <[EMAIL PROTECTED]>
Vampire - Alex Badea <[EMAIL PROTECTED]>
Remaining Work
~~~~~~~~~~~~
Although up and running fine at the moment, there are still quite a
few things that have not yet been implemented. A few items from the
current TODO list are:
* Finish deletion transaction system, to keep multiple bot's cache's
up-to-date with records deleted from the database.
* Lots more testing/work to do with ensuring multiple bot's
co-operate with each other.
* Finish commit() method of sqlPendingChannel class.
* Test 'Pending Registration' channel notification system.
* Extensively test all supplied language definitions (Vampire working
on this) before SET LANG is re-enabled.
* Rethink purge/register schema.
* Implement FLOODPRO (However, the only thing you can still flood
with in ircu is TOPIC, JOIN/PART/NICK, etc are all rate-limited now).
* Implement cache-expiration of channel Level records not accessed
within a time period (80% there).
* ^__ Same for Bans.
* Plenty more!
Longer Term:
* Abstract the database interface.
* Suggestions..
---------------------------------------------------------------
Well, if you've made it this far you are doing well :)
Cheers,
Dan
ripper_@IRC
