Development/XLine
From Inspire IRCd (InspIRCd)
| | This page has been marked as Development Material. Information posted here may be subject to change and/or only available in unstable versions of InspIRCd. |
Contents |
XLine Redesign
Introduction
The XLine subsystem in the IRCd handles all forms of bans, such as G, K, Q and C lines/bans.
Currently, the system is largely designed as a rigid blob, making it difficult to extend, impossible to hotpatch, and in some cases inefficient. This document will outline a new proposal for how XLine is to work in 1.2.
Current Design
XLineManager class loosely controls everything from adding of lines to application. The application of lines results in the rechecking of all lines of a given type.
New Design
Core
At the center of the XLine system, a "Manager" is needed to control the various types of bans and to remove code duplication. Line types are derived from XLine and inserted into a central map of maps.
Implementors
Outside the core, the individual lines are implemented by deriving a class from XLine and inserting them into the system in the same way as other lines derived from XLine such as GLine and QLine.
An example may be:
OnUserConnect( ..)
{
if (!u->MatchesExempt && ServerInstance->XLineManager->MatchesLine("G", u)
{
userrec::QuitUser(ServerInstance, u, "G-Lined");
return 1;
}
}
A boolean is stored in each user for elines, so that MatchesLine may be skipped for a user where User::MatchesExempt is set.
- userrec::exempt should be kept up to date at ALL times. This means processing each E:Line as it is set (or removed).. dangerous, but better (perhaps) than checking exempt status for each user as a gline is matched?
There is no longer a queue of active lines.
Expiry of lines occurs on positive hit, there is no timer for line expiry. Upon a positive hit for an expired line, the line is removed at that point and NULL returned from MatchesLine, so it appears as if that line just didnt exist. This majorly increases efficiency of the system.

















