Architecture & Philosophy

Construct's approach is a confluence employing the latest modern technologies while being anchored by traditional techniques. The aim is to arrive at a conservatively intuitive result, while providing rich functionality and allowing for fast-moving features. Choices made for Construct should evoke a reminiscence of network software from a bygone era of hallowed simplicity, but without being stuck in that era and falling victim to its shortcomings and ignoring their modern corrections.

Shared-library

Note: the name libircd is to be rebranded for distribution packages.

libircd.so is the core utility library for the Construct executable. This library includes developer utilities, configuration, statistics, filesystem, networking, cryptography, loadable modules, and support for various serializations, encodings, etc.

It does not include business-logic or specific application support (such as Matrix). It is able to load libircd_matrix.so to provide such support on command. For this reason libircd.so is the only library the executable must explicitly load.

Runs only one server at a time

Keeping with the spirit of simplicity of the original architecture, libircd continues to be a "singleton" object which uses globals and keeps actual server state in the library itself. In other words, only one IRC daemon can exist within a process's address space at a time. Whether or not this was a pitfall of the original design, it has emerged over the decades as a very profitable decision for making IRCd an accessible open source internet project.

Single-threaded✝

The design of libircd is fully-asynchronous, oriented around a single-thread event-loop. No code in the library blocks the process. All operations are conducted on top of a single boost::asio::io_service which must be supplied by the executable linking to libircd. That io_service must be run by the executable at its discretion; typically the embedder's call to ios.run() is the only place the process will block.

The single-threaded approach ensures there is an uninterrupted, uncontended, predictable execution which is easy for developers to reason about intuitively with sequential-consistency. This is ideal for the I/O-bound application being facilitated. If there are periods of execution which are computationally intense like parsing, hashing, cryptography, etc: this is absorbed in lieu of thread synchronization and bus contention.

This system achieves scale through running multiple independent instances which synchronize at the application-logic level through passing the application's own messages.

✝ However, do not assume a truly threadless execution for the entire address space. If there is ever a long-running background computation or a call to a 3rd party library which will block the event loop, we may use an additional std::thread to "offload" such an operation. Thus we do have a threading model, but it is heterogeneous.

Introduces userspace threading

IRCd presents an interface introducing stackful coroutines, a.k.a. userspace context switching, a.k.a. green threads, a.k.a. fibers. The library avoids callbacks as the way to break up execution when waiting for events. Instead, we harken back to the simple old ways of synchronous programming where control flow and data are easy to follow. If there are certain cases where we don't want a stack to linger which may jeopardize the c10k'ness of the daemon the asynchronous pattern is still used (this is a hybrid system).

Consider coroutines like "macro-ops" and asynchronous callbacks like "micro-ops." The pattern tends to use a coroutine to perform a large and complex operation which may involve many micro-ops behind the scenes. This approach relegates the asynchronous callback pattern to simple tasks contained within specific units which require scale, encapsulating the complexity away from the rest of the project.

Formal grammars, RTTI, exceptions

We utilize the boost::spirit system of parsing and printing through compile-time formal grammars, rather than writing our own parsers manually. In addition, we build several tools on top of such formal devices like a type-safe format string library acting as a drop-in for ::sprintf(), but accepting objects like std::string without .c_str() and prevention of outputting unprintable/unwanted characters that may have been injected into the system somewhere prior.