IRCd

An IRCd, short for Internet Relay Chat daemon, is server software that implements the IRC protocol, enabling people to talk to each other via the Internet (exchanging textual messages in real time).

Around version 2.7, there was a small but notable dispute[clarification needed], which led to ircu – the Undernet fork of ircd.

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 development line produced the 4 IRC RFCs released after RFC 1459, which document this server protocol exclusively.

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

[16] These attempts have met with mixed success, and large doses of skepticism from the existing IRC development community.

[19] 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).

Very few ircds are multithreaded as nearly every action needs to access (at least read and possibly modify) the global state.

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.

[citation needed] Some IRCd support Transport Layer Security, or TLS, for those who don't, it is still possible to use SSL via Stunnel.

More recently, as a security enhancement and usability enhancement, various client and server authors have begun drafting a standard known as the STARTTLS standard[22] which allows for TLS and plain text connections to co-exist on the same TCP port.

In general, the difference between IPv6 and IPv4 connections to IRC is purely academic and the service operates in much the same manner through either protocol.

Large IRC networks consist of multiple servers for horizontal scaling purposes.

In practice IRC operators now use jupe configurations to administratively make channel or nicknames unavailable.

This is recorded as a line in the server's IRC daemon configuration file prefixed with the letter "K", hence "K-line".

Some IRC daemons, including ircd-hybrid and its descendants, can be configured to propagate K-lines to some or all other servers on a network.

G-lines are often regarded as an extreme measure, only to be used in cases of repeated abuse when extensive attempts have been made to reason with the offending user.

Because a Z-line does not have to check usernames (identd) or resolved hostnames, it can be applied to a user before they send any data at all upon connection.

Therefore, a Z-line is more efficient and uses fewer resources than a K-line or G-line when banning large numbers of users.

This can result in delays, or if the DNS doesn't return correctly, banned users could still get on the network.

In actuality, the *@host option is completely against the intentions of using a Z-line, and therefore some IRCd programs will not allow anything other than *@IP, with wildcards (?,*) or CIDR prefix lengths (e.g. /8) allowed in the IP section to block entire subnets.

A disadvantage to using Z-line over K-line or G-line is that it becomes more difficult to ban entire ISPs and very dynamic IP addresses, common with some dialup and DSL connections.

For example, if a network administrator wants to ban all of ISP example.com (with hypothetical IP address ranges of 68.0.0.0 – 68.255.255.255 and 37.0.0.0 – 38.255.255.255), a G-line could use *@*example.com, whereas Z-line would require *@37.*.*.