rfc2810.txt
  1 Network Working Group                                           C. Kalt
2 Request for Comments: 2810 April 2000
3 Updates: 1459
4 Category: Informational
5
6 Internet Relay Chat: Architecture
7
8 Status of this Memo
9
10 This memo provides information for the Internet community. It does
11 not specify an Internet standard of any kind. Distribution of this
12 memo is unlimited.
13
14 Copyright Notice
15
16 Copyright (C) The Internet Society (2000). All Rights Reserved.
17
18 Abstract
19
20 The IRC (Internet Relay Chat) protocol is for use with text based
21 conferencing. It has been developed since 1989 when it was originally
22 implemented as a mean for users on a BBS to chat amongst themselves.
23
24 First formally documented in May 1993 by RFC 1459 [IRC], the protocol
25 has kept evolving. This document is an update describing the
26 architecture of the current IRC protocol and the role of its
27 different components. Other documents describe in detail the
28 protocol used between the various components defined here.
29
30 Table of Contents
31
32 1. Introduction ............................................... 2
33 2. Components ................................................. 2
34 2.1 Servers ................................................ 2
35 2.2 Clients ................................................ 3
36 2.2.1 User Clients ...................................... 3
37 2.2.2 Service Clients ................................... 3
38 3. Architecture ............................................... 3
39 4. IRC Protocol Services ...................................... 4
40 4.1 Client Locator ......................................... 4
41 4.2 Message Relaying ....................................... 4
42 4.3 Channel Hosting And Management ......................... 4
43 5. IRC Concepts ............................................... 4
44 5.1 One-To-One Communication ............................... 5
45 5.2 One-To-Many ............................................ 5
46 5.2.1 To A Channel ...................................... 5
47 5.2.2 To A Host/Server Mask ............................. 6
48
49 5.2.3 To A List ......................................... 6
50 5.3 One-To-All ............................................. 6
51 5.3.1 Client-to-Client .................................. 6
52 5.3.2 Client-to-Server .................................. 7
53 5.3.3 Server-to-Server .................................. 7
54 6. Current Problems ........................................... 7
55 6.1 Scalability ............................................ 7
56 6.2 Reliability ............................................ 7
57 6.3 Network Congestion ..................................... 7
58 6.4 Privacy ................................................ 8
59 7. Security Considerations .................................... 8
60 8. Current Support And Availability ........................... 8
61 9. Acknowledgements ........................................... 8
62 10. References ................................................ 8
63 11. Author's Address .......................................... 9
64 12. Full Copyright Statement .................................. 10
65
66 1. Introduction
67
68 The IRC (Internet Relay Chat) protocol has been designed over a
69 number of years for use with text based conferencing. This document
70 describes its current architecture.
71
72 The IRC Protocol is based on the client-server model, and is well
73 suited to running on many machines in a distributed fashion. A
74 typical setup involves a single process (the server) forming a
75 central point for clients (or other servers) to connect to,
76 performing the required message delivery/multiplexing and other
77 functions.
78
79 This distributed model, which requires each server to have a copy
80 of the global state information, is still the most flagrant problem
81 of the protocol as it is a serious handicap, which limits the maximum
82 size a network can reach. If the existing networks have been able to
83 keep growing at an incredible pace, we must thank hardware
84 manufacturers for giving us ever more powerful systems.
85
86 2. Components
87
88 The following paragraphs define the basic components of the IRC
89 protocol.
90
91 2.1 Servers
92
93 The server forms the backbone of IRC as it is the only component
94 of the protocol which is able to link all the other components
95 together: it provides a point to which clients may connect to talk to
96
97 each other [IRC-CLIENT], and a point for other servers to connect to
98 [IRC-SERVER]. The server is also responsible for providing the basic
99 services defined by the IRC protocol.
100
101 2.2 Clients
102
103 A client is anything connecting to a server that is not another
104 server. There are two types of clients which both serve a different
105 purpose.
106
107 2.2.1 User Clients
108
109 User clients are generally programs providing a text based
110 interface that is used to communicate interactively via IRC. This
111 particular type of clients is often referred as "users".
112
113 2.2.2 Service Clients
114
115 Unlike users, service clients are not intended to be used manually
116 nor for talking. They have a more limited access to the chat
117 functions of the protocol, while optionally having access to more
118 private data from the servers.
119
120 Services are typically automatons used to provide some kind of
121 service (not necessarily related to IRC itself) to users. An example
122 is a service collecting statistics about the origin of users
123 connected on the IRC network.
124
125 3. Architecture
126
127 An IRC network is defined by a group of servers connected to each
128 other. A single server forms the simplest IRC network.
129
130 The only network configuration allowed for IRC servers is that of
131 a spanning tree where each server acts as a central node for the rest
132 of the network it sees.
133
134 1--\
135 A D---4
136 2--/ \ /
137 B----C
138 / \
139 3 E
140
141 Servers: A, B, C, D, E Clients: 1, 2, 3, 4
142
143 [ Fig. 1. Sample small IRC network ]
144
145 The IRC protocol provides no mean for two clients to directly
146 communicate. All communication between clients is relayed by the
147 server(s).
148
149 4. IRC Protocol Services
150
151 This section describes the services offered by the IRC protocol. The
152 combination of these services allow real-time conferencing.
153
154 4.1 Client Locator
155
156 To be able to exchange messages, two clients must be able to locate
157 each other.
158
159 Upon connecting to a server, a client registers using a label which
160 is then used by other servers and clients to know where the client is
161 located. Servers are responsible for keeping track of all the labels
162 being used.
163
164 4.2 Message Relaying
165
166 The IRC protocol provides no mean for two clients to directly
167 communicate. All communication between clients is relayed by the
168 server(s).
169
170 4.3 Channel Hosting And Management
171
172 A channel is a named group of one or more users which will all
173 receive messages addressed to that channel. A channel is
174 characterized by its name and current members, it also has a set of
175 properties which can be manipulated by (some of) its members.
176
177 Channels provide a mean for a message to be sent to several clients.
178 Servers host channels, providing the necessary message multiplexing.
179 Servers are also responsible for managing channels by keeping track
180 of the channel members. The exact role of servers is defined in
181 "Internet Relay Chat: Channel Management" [IRC-CHAN].
182
183 5. IRC Concepts
184
185 This section is devoted to describing the actual concepts behind the
186 organization of the IRC protocol and how different classes of
187 messages are delivered.
188
189 5.1 One-To-One Communication
190
191 Communication on a one-to-one basis is usually performed by clients,
192 since most server-server traffic is not a result of servers talking
193 only to each other. To provide a means for clients to talk to each
194 other, it is REQUIRED that all servers be able to send a message in
195 exactly one direction along the spanning tree in order to reach any
196 client. Thus the path of a message being delivered is the shortest
197 path between any two points on the spanning tree.
198
199 The following examples all refer to Figure 1 above.
200
201 Example 1: A message between clients 1 and 2 is only seen by server
202 A, which sends it straight to client 2.
203
204 Example 2: A message between clients 1 and 3 is seen by servers A &
205 B, and client 3. No other clients or servers are allowed see the
206 message.
207
208 Example 3: A message between clients 2 and 4 is seen by servers A, B,
209 C & D and client 4 only.
210
211 5.2 One-To-Many
212
213 The main goal of IRC is to provide a forum which allows easy and
214 efficient conferencing (one to many conversations). IRC offers
215 several means to achieve this, each serving its own purpose.
216
217 5.2.1 To A Channel
218
219 In IRC the channel has a role equivalent to that of the multicast
220 group; their existence is dynamic and the actual conversation carried
221 out on a channel MUST only be sent to servers which are supporting
222 users on a given channel. Moreover, the message SHALL only be sent
223 once to every local link as each server is responsible to fan the
224 original message to ensure that it will reach all the recipients.
225
226 The following examples all refer to Figure 2.
227
228 Example 4: Any channel with 1 client in it. Messages to the channel
229 go to the server and then nowhere else.
230
231 Example 5: 2 clients in a channel. All messages traverse a path as if
232 they were private messages between the two clients outside a
233 channel.
234
235 Example 6: Clients 1, 2 and 3 in a channel. All messages to the
236 channel are sent to all clients and only those servers which must
237 be traversed by the message if it were a private message to a
238 single client. If client 1 sends a message, it goes back to
239 client 2 and then via server B to client 3.
240
241 5.2.2 To A Host/Server Mask
242
243 To provide with some mechanism to send messages to a large body of
244 related users, host and server mask messages are available. These
245 messages are sent to users whose host or server information match
246 that of the mask. The messages are only sent to locations where
247 users are, in a fashion similar to that of channels.
248
249 5.2.3 To A List
250
251 The least efficient style of one-to-many conversation is through
252 clients talking to a 'list' of targets (client, channel, mask). How
253 this is done is almost self explanatory: the client gives a list of
254 destinations to which the message is to be delivered and the server
255 breaks it up and dispatches a separate copy of the message to each
256 given destination.
257
258 This is not as efficient as using a channel since the destination
259 list MAY be broken up and the dispatch sent without checking to make
260 sure duplicates aren't sent down each path.
261
262 5.3 One-To-All
263
264 The one-to-all type of message is better described as a broadcast
265 message, sent to all clients or servers or both. On a large network
266 of users and servers, a single message can result in a lot of traffic
267 being sent over the network in an effort to reach all of the desired
268 destinations.
269
270 For some class of messages, there is no option but to broadcast it to
271 all servers so that the state information held by each server is
272 consistent between servers.
273
274 5.3.1 Client-to-Client
275
276 There is no class of message which, from a single message, results in
277 a message being sent to every other client.
278
279 5.3.2 Client-to-Server
280
281 Most of the commands which result in a change of state information
282 (such as channel membership, channel mode, user status, etc.) MUST be
283 sent to all servers by default, and this distribution SHALL NOT be
284 changed by the client.
285
286 5.3.3 Server-to-Server
287
288 While most messages between servers are distributed to all 'other'
289 servers, this is only required for any message that affects a user,
290 channel or server. Since these are the basic items found in IRC,
291 nearly all messages originating from a server are broadcast to all
292 other connected servers.
293
294 6. Current Problems
295
296 There are a number of recognized problems with this protocol, this
297 section only addresses the problems related to the architecture of
298 the protocol.
299
300 6.1 Scalability
301
302 It is widely recognized that this protocol does not scale
303 sufficiently well when used in a large arena. The main problem comes
304 from the requirement that all servers know about all other servers,
305 clients and channels and that information regarding them be updated
306 as soon as it changes.
307
308 6.2 Reliability
309
310 As the only network configuration allowed for IRC servers is that of
311 a spanning tree, each link between two servers is an obvious and
312 quite serious point of failure. This particular issue is addressed
313 more in detail in "Internet Relay Chat: Server Protocol" [IRC-
314 SERVER].
315
316 6.3 Network Congestion
317
318 Another problem related to the scalability and reliability issues, as
319 well as the spanning tree architecture, is that the protocol and
320 architecture for IRC are extremely vulnerable to network congestions.
321 This problem is endemic, and should be solved for the next
322 generation: if congestion and high traffic volume cause a link
323 between two servers to fail, not only this failure generates more
324 network traffic, but the reconnection (eventually elsewhere) of two
325 servers also generates more traffic.
326
327 In an attempt to minimize the impact of these problems, it is
328 strongly RECOMMENDED that servers do not automatically try to
329 reconnect too fast, in order to avoid aggravating the situation.
330
331 6.4 Privacy
332
333 Besides not scaling well, the fact that servers need to know all
334 information about other entities, the issue of privacy is also a
335 concern. This is in particular true for channels, as the related
336 information is quite a lot more revealing than whether a user is
337 online or not.
338
339 7. Security Considerations
340
341 Asides from the privacy concerns mentioned in section 6.4 (Privacy),
342 security is believed to be irrelevant to this document.
343
344 8. Current Support And Availability
345
346 Mailing lists for IRC related discussion:
347 General discussion: ircd-users@irc.org
348 Protocol development: ircd-dev@irc.org
349
350 Software implementations:
351 ftp://ftp.irc.org/irc/server
352 ftp://ftp.funet.fi/pub/unix/irc
353 ftp://coombs.anu.edu.au/pub/irc
354
355 Newsgroup: alt.irc
356
357 9. Acknowledgements
358
359 Parts of this document were copied from the RFC 1459 [IRC] which
360 first formally documented the IRC Protocol. It has also benefited
361 from many rounds of review and comments. In particular, the
362 following people have made significant contributions to this
363 document:
364
365 Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa
366 Ruokonen, Magnus Tjernstrom, Stefan Zehl.
367
368 10. References
369
370 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
371 Requirement Levels", BCP 14, RFC 2119, March 1997.
372
373 [IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat
374 Protocol", RFC 1459, May 1993.
375
376 [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
377 2812, April 2000.
378
379 [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
380 2813, April 2000.
381
382 [IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC
383 2811, April 2000.
384
385 11. Author's Address
386
387 Christophe Kalt
388 99 Teaneck Rd, Apt #117
389 Ridgefield Park, NJ 07660
390 USA
391
392 EMail: kalt@stealth.net
393
394 12. Full Copyright Statement
395
396 Copyright (C) The Internet Society (2000). All Rights Reserved.
397
398 This document and translations of it may be copied and furnished to
399 others, and derivative works that comment on or otherwise explain it
400 or assist in its implementation may be prepared, copied, published
401 and distributed, in whole or in part, without restriction of any
402 kind, provided that the above copyright notice and this paragraph are
403 included on all such copies and derivative works. However, this
404 document itself may not be modified in any way, such as by removing
405 the copyright notice or references to the Internet Society or other
406 Internet organizations, except as needed for the purpose of
407 developing Internet standards in which case the procedures for
408 copyrights defined in the Internet Standards process must be
409 followed, or as required to translate it into languages other than
410 English.
411
412 The limited permissions granted above are perpetual and will not be
413 revoked by the Internet Society or its successors or assigns.
414
415 This document and the information contained herein is provided on an
416 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
417 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
418 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
419 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
420 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
421
422 Acknowledgement
423
424 Funding for the RFC Editor function is currently provided by the
425 Internet Society.