IRCd:Main
This portion of the wiki is intended to help document DareNET's ircd, ircd-darenet, which is based on ircu, explaining why things are done the way they are. In addition to documenting the existing server and how it does things, we also hope to equip and inspire new developers.
Documentation is traditionally the weakest part of any ircd project. The developers that have worked on such projects in the past have often omitted comments. The documentation that does exist either documents the API via Doxygen-style documentation comments, or consists of a large number of partially unreleated documents stored in the "doc" subtree of the source code. Further, anytime someone asks for more documentation, those developers traditionally respond, "look at the source."
The intent of this section of the wiki is to try to build a single document -- editable by at least our developers -- that documents the basic architecture, hopefully pulling together the morass of documents and comments into a single, unified whole that is open and accessible to everyone.
In This Guide: |
Introduction to IRC
Internet Relay Chat, also known as IRC, is one of the earliest multi-user real-time chat protocols. As originally designed, it's a fairly simple, straightforward text-based protocol. However, it is complicated by the fact that IRC servers are intended to be networked together. This not only requires securing the link between the servers, it also requires that the information about the network's users and clients, collected into the server's database, be available to all servers. This is done, in IRC, by distributing the database globally.
Now, this design is not without consequence. It causes a severe lack of scalability, not to mention significant problems when servers disconnect or reconnect to a network. To understand how to configure the server, and why the code is written the way it is, it is necessary to really understand the IRC protocol and its consequences.
Introduction to the Server (ircd)
Real-time chat servers can be among the most complex servers, due to their real-time multiplexed requirement. When multiple servers have to be multiplexed together, as in IRC, things can get even more complicated. And, when you are dealing with an old source base, with tons of features having been added over a period of decades, then you're dealing with ircd -- or more specifically in this case, ircd-darenet.
For the most part, building the server is fairly straightforward. With older versions of ircd, most of the features or options were selected at compile-time, but the addition of the "features" system (used in ircd-darenet) enabled many of those to be configured at run time via the configuration file. The server code will compile on most POSIX-compliant systems, but the systems we test with are Linux and FreeBSD.
Configuration of the server can be quite difficult; however, it is a process we continually try to simplify. The current format consists of a number of single lines, each beginning with a single letter; each field in the configuration like is then separated from the others by a colon (:). This has resulted in the terminology of "K-lines," "I-lines," etc. Soon, ircd-darenet will sport a new configuration file format, inspired by modern servers such as BIND, which is much more verbose, but more easily understood. The basic building blocks of the new configuration file will be "blocks," brace-enclosed relations (that is, name=value pairs), separated from each other by semicolons.
Introduction to the Code
In any well-designed software system, the code is broken down into distinct modules, each handling a specific piece of behavior. There are always very clear abstraction boundaries and few, if any, global variables. This is not ircd-darenet.
There are numerous places where abstraction boundaries are violated within ircd-darenet, and there are a ton of global variables accessed all over the place. In addition, many of the modules that do exist are not very well defined. However, this is a situation that has been steadily improved, though there is still quite a ways to go.
Systems List
This section includes a partial systems/modules list for ircd-darenet. It is not intended to be complete or definitive; however, it should begin to provide a taxonomy of the server.
- Database
- Hash tables
- Linked lists
- IPcheck
- Channel
- Client
- G-lines
- Z-lines
- Shuns
- Jupes
- Numeric nicknames
- Configuration
- Lexical analyzer
- Parser
- Classes
- Connection rules ("crules")
- Features
- Message of the Day ("MOTD")
- Network
- Event subsystem
- Sockets
- UNIX Signals
- Timers
- Event engines
- Data buffering
- Basic data buffers
- Message queues
- DNS resolver
- Basic network routines
- Listening sockets
- Packetizer
- Event subsystem
- System
- File IO (needed due to the large number of file descriptors)
- Memory allocation
- MD5 internals
- Random number generator (for sign-on cookies)
- Password hash system
- Logging
- Debug logging
- String processing
- Basic string routines--duplication, comparison, etc.
- Custom snprintf() routine
- Basic pattern matching
- Command parsing
- User commands
- Server commands
- Command processing
- Query commands
- Oper-only commands
- /WHOWAS command
- Initial sign-on support
- IAuth implementation
- Identd query
- Statistics
- Userload
- Message sending routines
- Command send routines
- Command reply routines
- Special message relay routines