RFC 2810
Internet Relay Chat: Architecture
Internet Relay Chat: Architecture ✨
Okay bestie, this one is RFC 2810 🎀, titled "Internet Relay Chat: Architecture," written by C. Kalt and dated April 2000. It's an Informational doc, so it's sharing info with the community and it does not set an Internet standard 🫶. It updates RFC 1459, the original IRC spec, so think of this as the glow-up 💅.
Status of this Memo
This memo gives information to the Internet community. It isn't an Internet standard of any kind, and anyone can distribute it freely 🌸.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved. 💜
Abstract
IRC (Internet Relay Chat) is a protocol for text based conferencing 💬. It's been around since 1989, when it was first built as a way for people on a BBS to chat with each other 🧚.
It got its first formal write-up in May 1993 in RFC 1459 [IRC], and the protocol has kept evolving ever since 📈. This document is the update, describing the architecture of today's IRC and what each of its components does 🦋. The nitty-gritty details of how those components talk to each other live in other documents.
Table of Contents
1. Introduction ............................................... 2
2. Components ................................................. 2
2.1 Servers ................................................ 2
2.2 Clients ................................................ 3
2.2.1 User Clients ...................................... 3
2.2.2 Service Clients ................................... 3
3. Architecture ............................................... 3
4. IRC Protocol Services ...................................... 4
4.1 Client Locator ......................................... 4
4.2 Message Relaying ....................................... 4
4.3 Channel Hosting And Management ......................... 4
5. IRC Concepts ............................................... 4
5.1 One-To-One Communication ............................... 5
5.2 One-To-Many ............................................ 5
5.2.1 To A Channel ...................................... 5
5.2.2 To A Host/Server Mask ............................. 6
5.2.3 To A List ......................................... 6
5.3 One-To-All ............................................. 6
5.3.1 Client-to-Client .................................. 6
5.3.2 Client-to-Server .................................. 7
5.3.3 Server-to-Server .................................. 7
6. Current Problems ........................................... 7
6.1 Scalability ............................................ 7
6.2 Reliability ............................................ 7
6.3 Network Congestion ..................................... 7
6.4 Privacy ................................................ 8
7. Security Considerations .................................... 8
8. Current Support And Availability ........................... 8
9. Acknowledgements ........................................... 8
10. References ................................................ 8
11. Author's Address .......................................... 9
12. Full Copyright Statement .................................. 101. Introduction ✨
IRC has been cooking for years as a way to do text based conferencing 🍓. This doc describes what its architecture looks like right now.
The IRC protocol is built on the client-server model, and it's super well suited to running across lots of machines in a distributed way 🌈. A typical setup has a single process, the server, acting as the central hub. Clients (or other servers) connect to it, and it handles message delivery, multiplexing, and everything else the network needs 👑.
Here's the tea ☕: this distributed model needs every server to hold a copy of the global state information. That's honestly the biggest problem with the protocol 💀, because it's a serious handicap that caps how big a network can get. The fact that networks have kept growing at an incredible pace is kind of a miracle, and we have to thank hardware manufacturers for making ever more powerful machines 🙈.
2. Components 🎀
Here are the basic components that make up the IRC protocol 💖.
2.1 Servers
The server is the backbone of IRC 🦴. It's the only component that can link all the other components together. Clients connect to it to talk to each other [IRC-CLIENT], and other servers connect to it too [IRC-SERVER]. It's also in charge of providing the basic services the IRC protocol defines 💅.
2.2 Clients
A client is anything that connects to a server and isn't another server 🫶. There are two types, and they each have a different job.
2.2.1 User Clients
User clients are usually programs with a text based interface, used to chat interactively over IRC 💬. This is the type people usually mean when they say "users" 🌸.
2.2.2 Service Clients
Unlike users, service clients aren't meant to be driven by hand or used for chatting 🤖. They have more limited access to the chat functions of the protocol, but they can optionally get access to more private data from the servers 🔒.
Services are usually automatons that provide some kind of service to users, and it doesn't have to be about IRC itself ✨. For example, a service might collect statistics about where the users connected to an IRC network are coming from 📊.
3. Architecture 🧚
An IRC network is just a group of servers connected to each other 💜. A single server on its own counts as the simplest IRC network.
The only network configuration IRC servers are allowed to use is a spanning tree, where each server acts as a central node for the rest of the network it can see 🌳.
1--\
A D---4
2--/ \ /
B----C
/ \
3 E
Servers: A, B, C, D, E Clients: 1, 2, 3, 4
[ Fig. 1. Sample small IRC network ]Okay, the big plot twist: the IRC protocol gives two clients no direct way to talk to each other 😭. Every bit of communication between clients gets relayed through the server(s) 📨.
4. IRC Protocol Services 👑
This section covers the services the IRC protocol offers. Put them together and you get real-time conferencing 🎉.
4.1 Client Locator
Before two clients can swap messages, they have to find each other 🔍.
When a client connects to a server, it registers under a label. Other servers and clients use that label to figure out where the client is hanging out 📍. The servers are responsible for keeping track of every label in use 🗂️.
4.2 Message Relaying
Still the same no-direct-chat rule here 🙈: two clients can't talk directly, so all communication between them is relayed by the server(s) 💌.
4.3 Channel Hosting And Management
A channel is a named group of one or more users, and everyone in it gets the messages sent to that channel 📣. A channel is defined by its name and its current members, and it also has a set of properties that some (not all!) of its members can change ⚙️.
Channels give a way to send one message to several clients at once 🦋. Servers host the channels and do the message multiplexing that makes it work 🔀. They also manage channels by keeping track of who's a member 📋. The exact role of servers in all this is spelled out in "Internet Relay Chat: Channel Management" [IRC-CHAN] 📚.
5. IRC Concepts 🌸
This section is all about the ideas behind how IRC is organized, and how the different classes of messages get delivered 💖.
5.1 One-To-One Communication
One-to-one messaging is usually done by clients, because most server-to-server traffic isn't servers just gossiping with each other 🗣️. To let clients talk to each other, it is REQUIRED that all servers be able to send a message in exactly one direction along the spanning tree to reach any client 🌳. That means a message always takes the shortest path between any two points on the spanning tree 🏃♀️.
The examples below all refer to Figure 1 above 👀.
Example 1: A message between clients 1 and 2 is only seen by server A, which sends it straight to client 2 💫.
Example 2: A message between clients 1 and 3 is seen by servers A & B, and client 3. No other clients or servers are allowed to see the message 🙅♀️.
Example 3: A message between clients 2 and 4 is seen by servers A, B, C & D and client 4 only 🎀.
5.2 One-To-Many
The main goal of IRC is to be a forum for easy and efficient conferencing, which means one-to-many conversations 🎤. IRC has a few ways to do this, and each one has its own purpose 💅.
5.2.1 To A Channel
Channels are basically IRC's version of a multicast group 🦋. They pop in and out of existence dynamically, and the actual conversation happening in a channel MUST only be sent to the servers that are supporting users in that channel 💬. Also, the message SHALL only be sent once over each local link, because every server is responsible for fanning the original message out so it reaches all the recipients 📡.
The examples below all refer to Figure 2 ✨.
Example 4: Any channel with 1 client in it. Messages to the channel go to the server and then nowhere else 🫧.
Example 5: 2 clients in a channel. All messages travel the same path they would as private messages between the two clients outside a channel 🛤️.
Example 6: Clients 1, 2 and 3 in a channel. All messages to the channel are sent to all clients, and only to those servers that must be traversed by the message if it were a private message to a single client 🌈. If client 1 sends a message, it goes to client 2, and then through server B to client 3 💌.
5.2.2 To A Host/Server Mask
IRC also has a way to reach a big crowd of related users at once: host and server mask messages 🎭. These go to users whose host or server information matches the mask 🔎. They're only sent to places where those users actually are, kind of like channels do ✨.
5.2.3 To A List
The least efficient way to do one-to-many chat is for a client to talk to a "list" of targets (clients, channels, or masks) 📝. It's pretty self-explanatory: the client gives a list of destinations, and the server splits it up and sends a separate copy of the message to each one 📮.
This isn't as efficient as using a channel, because the destination list MAY be broken up and dispatched without checking whether duplicates get sent down each path 🙃.
5.3 One-To-All
One-to-all messages are really broadcast messages, sent to all clients, all servers, or both 📢. On a big network, one message can generate a ton of traffic as it tries to reach every single destination 🌊.
For some classes of messages there's no choice but to broadcast them to all servers, so that the state information each server holds stays consistent across the network 🧩.
5.3.1 Client-to-Client
There's no class of message that, from a single message, results in that message being sent to every other client 🙅♀️. Not even a little bit, bestie 💀.
5.3.2. Client-to-Server
Okay so most of the commands that change state info (channel membership, channel mode, user status, etc.) MUST get sent to all servers by default, and the client SHALL NOT change that distribution. Not up for debate, bestie 💅🎀
5.3.3. Server-to-Server
Servers send messages to all the other servers, but only when it matters. If a message affects a user, channel or server, it's required to get broadcast. Those are the basic building blocks of IRC, so basically every message that starts on a server gets blasted to every other connected server 🌸✨
6. Current Problems ⚠️
Okay, there are a bunch of known problems with this protocol 🥺 This section only covers the ones tied to how the protocol is architected.
6.1. Scalability
Everyone agrees this protocol doesn't scale well when the network gets huge 😭 The big issue is that every server has to know about every other server, every client and every channel, and every bit of that info has to be updated the second it changes. That's a LOT of group-chat notifications 💀
6.2. Reliability
IRC servers can only be arranged as a spanning tree 🌳 which means every link between two servers is an obvious and pretty serious point of failure 🙈 This gets covered in more detail in "Internet Relay Chat: Server Protocol" [IRC-SERVER].
6.3. Network Congestion
This one's tied to the scalability and reliability stuff, plus the spanning tree setup. The protocol and architecture are super vulnerable to network congestion, and honestly this problem is endemic 😩 It should get solved in the next generation. Here's the spiral: if congestion and heavy traffic make a link between two servers fail, that failure creates even more traffic, and then reconnecting the two servers (maybe somewhere else) creates even more traffic too 🌀
To cut down on this, it is strongly RECOMMENDED that servers don't try to reconnect too fast, so they don't make things worse 🫶
6.4. Privacy
Besides not scaling well, servers having to know everything about every other entity is also a privacy concern 👀 This is especially true for channels, because channel info reveals a lot more than whether someone is online or not 🙈🔒
7. Security Considerations 🔐
Okay, real talk: apart from the privacy concerns in section 6.4 (Privacy), security is believed to be irrelevant to this document. ⚠️ Still, don't skip reading 6.4, it's the main thing to watch 💜
8. Current Support And Availability 🍓
Mailing lists for IRC related discussion:
General discussion: ircd-users@irc.org
Protocol development: ircd-dev@irc.orgSoftware implementations:
ftp://ftp.irc.org/irc/server
ftp://ftp.funet.fi/pub/unix/irc
ftp://coombs.anu.edu.au/pub/ircNewsgroup: alt.irc 🦋
9. Acknowledgements 💖
Parts of this doc were copied from RFC 1459 [IRC], which was the first formal documentation of the IRC Protocol 👑 It also got better thanks to lots of rounds of review and comments. These people made especially big contributions to this document:
Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa Ruokonen, Magnus Tjernstrom, Stefan Zehl. ✨
10. References 📚
- [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC 1459, May 1993.
- [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812, April 2000.
- [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC 2813, April 2000.
- [IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC 2811, April 2000.
11. Author's Address 🖊️
Christophe Kalt
99 Teaneck Rd, Apt #117
Ridgefield Park, NJ 07660
USA
EMail: kalt@stealth.net12. Full Copyright Statement 🌈
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. 🌍
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. ♾️
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🧚
Acknowledgement 💜
Funding for the RFC Editor function is currently provided by the Internet Society. 🫶✨
📦 where this page comes from
- ietf: rfc2810 2000-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms