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