IRCd
From Wikipedia, the free encyclopedia
An IRCd, short for Internet Relay Chat daemon, server software that implements the IRC protocol, enabling people to talk to each other via the Internet (exchanging textual messages in real time).
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.
Contents |
[edit] History
The original IRCd was known as 'ircd', and was authored by Jarkko Oikarinen (WiZ on IRC) around 1989. He received help from a number of others, such as Markku Savela (msa on IRC), who helped with the 2.2+msa release, etc.
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
- 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.
[edit] Sidestream Versions
More recently, several irc daemons were written from scratch, such as ithildin[1], InspIRCd[2], csircd (also from Comstud), ConferenceRoom[3], Microsoft Exchange Chat Service, or IRCPlus/IRCXPro[4].
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).
[edit] Features
[edit] Ports
The officially assigned port numbers are 194 ("irc"), 529 ("irc-serv"), and 994 ("ircs"). However, these ports are in the privileged range (0-1024), which on a Unix-like system means that the daemon would have to have superuser privileges in order to open them. For various security reasons this is undesirable.
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.
[edit] Numerous connections
Running a large IRC server, one that has more than a few thousand simultaneous users, requires keeping a very large number of TCP connections open for long periods. Very few ircds are multithreaded due to the fact that 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. 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. 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.
[edit] SSL
Some IRCd support SSL, for those who don't, it is still possible to use SSL via Stunnel. The unofficial, but most often used port for SSL IRCd connections is 6697.
[edit] IP
IRC daemons support IPv4, and some also support IPv6.
[edit] Configuration
[edit] Jupe
In Internet Relay Chat (IRC), juping a server, a channel, or a nickname refers to the practice of blocking said channel or nickname on the server or network or said server on the network. One possible explanation of how this term came about is that it is named after the oper named Jupiter, who gained control of the nickname NickServ on EFnet. EFnet does not offer services such as NickServ; Jupiter gained control of the nickname to make fun of people who sent him passwords. Today, EFnet opers jupe nicknames that are used as services on other networks.
A nickname or server jupe takes advantage of the fact that certain identifiers are unique; by using an identifier, one acquires an exclusive lock that prevents other users from making use of it.
Officially sanctioned jupes may also utilize services or server configuration options to enforce the jupe, such as when a compromised server is juped to prevent it from harming the network.
In practice IRC operators now use jupe configurations to administratively make channel or nick names unavailable.[5] A channel jupe refers to a server specific ban of a channel, which means that a specific channel cannot be joined when connected to a certain server, but other servers may allow a user to join the channel. This is a way of banning access to problematic channels.
[edit] O-line
An O-line, shortened from Operator Line, is a line of code in an IRC daemon configuration file that determines which users can become an IRC Operator and which permissions they get upon doing so. The name comes from the prefix used for the line in the original ircd, a capital O. The O-line specifies the username, password, operator flags, and hostmask restrictions for a particular operator. A server may have many O-lines depending on the administrative needs of the server and network[6].
Operator flags are used to describe the permissions an operator is granted. While some IRC Operators may be in charge of network routing, others may be in charge of network abuse, making their need for certain permissions different.[7] Operator flags available vary widely depending on which IRC daemon is in use. Generally, more feature rich IRC daemons tend to have more operator flags, and more traditional IRC daemons have fewer.
An O-line may also be set so that only users of a certain hostmask or IP address can gain IRC Operator status using that O-line. Using hostmasks and IP addresses in the O-line require the IP address to remain the same but provide additional security.
[edit] K-Line
A k-line or kill line (also written k:line) is an Internet Relay Chat term, applied to a specific user. When a user is k-lined, it bans the user from a certain server, either for a certain amount of time or permanently. Once the user is banned, they are not allowed back onto that server; they have to join a different server to get onto IRC. This is recorded as a line in the server's IRC daemon configuration file prefixed with the letter "K", hence "K-line".
While the precise reason for the disconnection varies from case to case, usual reasons involve some aspect of the client or the user it is issued against.
- User behavior
- The most common cause for a k-line is inappropriate behavior on the part of the user, such as nickname colliding, mode "hacking", multiple channel flooding, harassing other users via private messaging features, spamming etc., or in the case of older networks without timestamping, split riding, which cannot be corrected through use of channel operator privileges alone.
- Client software
- Some IRC Daemons can be configured to scan for viruses or other vulnerabilities in clients connecting to them, and will react in various ways according to the result. Outdated and insecure client software might be blocked to protect other network users from vulnerabilities, for instance. Some networks, e.g. freenode, will disconnect clients operating on/via open proxies, or running an insecure web server.
- Geographic location
- An IRC network operating multiple servers in different locales will attempt to reduce the distance between a client and a server. This is often achieved by disconnecting (and/or banning) clients from distant locales in favour of local ones.
[edit] Other "lines"
There are a number of other network "lines" relating to the k-line.
[edit] G-Line/AKill
A Gline or AKill is a global network ban applied to a user; the former term comes from Undernet and the latter from DALNet. The term "AKill" comes from an earlier implementation in which the IRC Services would automatically "kill" (disconnect) the user remotely upon login, rather than the individual servers simply denying the connection.
[edit] Z-line
On some IRCds, such as UnrealIRCd, a Zline is similar to a g-line, but applied to a client's IP address range, and is considered to be used in extreme cases. Because a Zline 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 Zline is more efficient and uses fewer resources than a Gline or Kline when banning large numbers of users. Because not all IRCds are the same, others, such as Charybdis, use a 'Dline' instead.
[edit] Q-line
On some IRCds, such as UnrealIRCd, a Qline forbids a nickname, or any nickname matching a given pattern. This is most often used to forbid use of services nicknames (such as 'X', or NickServ) or forbid use of IRC Operator nicknames by non-operators. Some IRC daemons may disconnect users when initially applying the Qline, whilst others will force a nickname change, or do nothing until the user covered by the Qline reconnects. Other IRCds, like Charybdis, use an 'Xline' instead.
[edit] See also
[edit] External links
- irc.org - IRC resources
- Technical comparison of TS and nickname delay mechanisms
- DarkFire IRC Manual (network specific)
- Undernet K-Line and G-Line FAQ with reasons for them, amongst other things
- EFnet FAQ with several -line terms explained
- Quakenet General FAQ G/K-Line
- GLine, KLine, QLine and ELine syntax