The result is that the best platforms for ircds are those that offer efficient mechanisms for handling huge numbers of connections in a single thread. Linux offers this ability in the form of epoll, in kernel series newer than 2.4.x. FreeBSD (since 4.1) offers kqueue. Solaris has had /dev/poll since version 7, and from version 10 onwards has IOCP (I/O Completion Ports). The difference made by these new interfaces can be dramatic. IRCU coders have mentioned increases in the practical capacity per server from 10,000 users to 20,000 users.

The common ports for an IRCd process are 6665 to 6669, with 6667 being the historical default. These ports can be opened by a non-superuser process, and they became widely used.

These attempts have met with mixed success, and large doses of scepticism from the existing IRC development community. With each new IRCd, a slightly different version of the IRC protocol is used, and many IRC clients and bots are forced to compromise on features or vary their implementation based on the server to which they are connected. These are often implemented for the purpose of improving usability, security, separation of powers, or ease of integration with services. Possibly one of the most common and visible differences is the inclusion or exclusion of the half-op channel operator status (which is not a requirement of the RFCs).

In its first incarnations, IRC did not have many features that are taken for granted today, such as named channels and channel operators. Channels were numbered — channel 4 and channel 57, for example — and the channel topic described the kind of conversation that took place in the channel. One holdover of this is that joining channel 0 causes a client to leave all the channels it is presently on: “CHANNEL 0″ being the original command to leave the current channel.

The first major change to IRC, in version 2.5, was to add named channels — “+channels”. “+channels” were later replaced with “#channels” in version 2.7, numeric channels were removed entirely and channel bans (mode +b) were implemented.

Around version 2.7, there was a small but notable dispute, which led to ircu — the Undernet fork of ircd.

irc2.8 added “&channels” (those that exist only on the current server, rather than the entire network) and “!channels” (those that are theoretically safe from suffering from the many ways that a user could exploit a channel by “riding a netsplit”), and is the baseline release from which nearly all current implementations are derived.

Around 2.8 came the concept of nick and channel delay, a system designed to help curb abusive practices such as takeovers and split riding. This was not agreed on by the majority of modern IRC (EFnet, DALnet, Undernet, etc) - and thus, 2.8 was forked into a number of different daemons using an opposing theory known as TS — or time stamping, which stored a unique time stamp with each channel or nickname on the network to decide which was the ‘correct’ one to keep. More information on this may be found at http://www.ircd-hybrid.com/history.html.

Time stamping itself has been revised several times to fix various issues in its design. The latest versions of such protocols are:

* the TS6 protocol, which is used by efnet, and hybrid/ratbox based servers amongst others
* the P10 protocol, which is used by undernet and ircu based servers.

While the client-to-server protocols are at least functionally similar, server-to-server protocols differ widely (TS5, P10, and ND/CD server protocols are incompatible), making it very difficult to “link” two separate implementations of the IRC server. Some “bridge” servers do exist, to allow linking of, for example, 2.10 servers to TS5 servers, but these are often accompanied with restrictions of which parts of each protocol may be used, and are not widely deployed.

Significant releases based on 2.8 included:

* 2.8.21+CS, developed by Comstud
* 2.8+th, Taner’s patchset, which later became
o ircd-hybrid, originally developed by Jon Lusky (Rodder) and Diane Bruce (Dianora) as 2.8/hybrid, later joined by a large development team.
* 2.9, 2.10, 2.11, … continue the development of the original codebase,

The original code base continued to be developed mainly for use on the IRCnet network. New server-to-server protocols were introduced in version 2.10, released in 1998, and in 2.11, first released in 2004, and current as of 2007. This daemon is used by IRCnet and it can be found at ftp://ftp.irc.org/irc/server/ The original ircd is free software, licensed under the GNU General Public License. This development line produced the 4 IRC RFCs released after RFC 1459, which document this server protocol exclusively.

2.8.21+CS and ircd-hybrid continue to be used on EFnet, with ircd-ratbox (an offshoot of ircd-hybrid) as of 2004 being the most popular.

The server listens to connections from IRC clients on a set of TCP ports. When the server is part of an IRC network, it also keeps one or more established connections to other servers/daemons.

The term ircd originally referred to only one single piece of software, but it eventually became a generic reference to any implementation of an IRC daemon. However, the original version is still distributed under the same name, and this article discusses both uses.

The Kline (AutoKill) is a host ban, it will kill (Disconnect) any user matching the given host instantly as they connect. KLines could expire, but in some cases it is permanent.

The Gline (Global K-Line), works exactly as the K-Line, only it is global, and its effect takes place on all of the servers in the network. Glines could expire, but in some cases it is permanent.

On IRCds such as UnrealIRCd, the Zline is a “powerful” ban, it is performed on IP instead of host. Making sure that users from that IP will not join. Zlines could expire, but in some cases it is permanent.

Some IRCds support the Global Z-Line, is exactly as the Zline itself, but it’s global, and network wide. UnrealIRCd has GZline support. The GZline is an effective way of blocking static IP users, and keeping them out.

On other IRCds, such as Charybdis, a ‘Dline’ replaces a Zline. It is called a Dline because it “denies” the IP address from connecting. Charybdis does not have support for a Zline or a GZline. By using its “cluster” configuration feature, Dlines can be synchronized between servers, providing a type of ‘GZline’. This enables for very nice big network support since the administrator of one server may want to allow certain servers they trust to synchronize Dlines and Klines, but not allow others..

The Local Operator (LocOp) is the lowest in Operator access levels. The LocOp has a minimal control on one server out of a network, and usually has the ability to kill (disconnect) people from the server or perform local k:lines (server ban).

The Global Operator (GlobOp) is similar to the LocOp, and has control over the entire network of servers, as opposed to a single server. GlobOps may perform G:lines or Akills (network-wide bans) and Shun (forcibly mute) users over an entire network.

Commonly abbreviated as SA, This admin type has access to almost all commands on an IRC network. Usually, an SA has the ability to use the /sa* commands. The /sa* commands will set channelmodes via both channel services and the server itself, making it impossible for normal users to see who changed the modes.

The Network Administrator (NetAdmin) has the highest level of access on a network. In most cases, the founder of the network is the netadmin. Networks may, however, have multiple netadmins - espescially networks with large populations.

IRC operators are divided into local and global operators. The former are limited to the server(s) they have specific access to; however, global operators can perform actions affecting all users on the network. In order to perform their duties, IRC operators usually have the ability to:

* Forcibly disconnect users (Kill)
* Ban (K-line or G-line) users
* Change network routing by disconnecting (squitting) or connecting servers

Traditionally, a list of operators on a particular server is available in the MOTD, or through the /stats o [servername] command. A user can become an operator by sending the command /oper to the irc server he or she currently is on using a pre-selected username and a password as parameters. The command only works for the server which has the proper O-line in its ircd configuration file. The IP address that the user is opering from may also have to match a predefined one, as an extra layer of security to prevent unauthorized users opering if they have cracked the operator’s password.