idnits 2.17.1 draft-kalt-irc-arch-00.txt: -(161): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(181): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(188): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(193): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(209): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(231): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(346): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(352): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(353): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(379): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == There are 14 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([IRC]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 27 == Unused Reference: 'KEYWORDS' is defined on line 387, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 1459 (ref. 'IRC') -- No information found for draft-kalt-irc-client-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IRC-CLIENT' -- No information found for draft-kalt-irc-server-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IRC-SERVER' -- No information found for draft-kalt-irc-chan-xx-txt - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IRC-CHAN' Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft C. Kalt 2 Internet Relay Chat: Architecture 3 draft-kalt-irc-arch-00.txt 5 Status of this Memo 7 This document is an Internet-Draft and is in full conformance with 8 all provisions of Section 10 of RFC2026. Internet-Drafts are working 9 documents of the Internet Engineering Task Force (IETF), its areas, 10 and its working groups. Note that other groups may also distribute 11 working documents as Internet Drafts. 13 Internet-Drafts are draft documents valid for a maximum of six 14 months and may be updated, replaced, or obsoleted by other documents 15 at any time. It is inappropriate to use Internet-Drafts as reference 16 material or to cite them other than as "work in progress." 18 The list of current Internet-Drafts can be accessed at 19 http://www.ietf.org/ietf/1id-abstracts.txt 21 The list of Internet-Draft Shadow Directories can be accessed at 22 http://www.ietf.org/shadow.html. 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 25 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 26 this document are to be interpreted as described in RFC 2119[1]. 28 Abstract 30 The IRC (Internet Relay Chat) protocol is for use with text based 31 conferencing. It has been developed since 1989 when it was originally 32 implemented as a mean for users on a BBS to chat amongst themselves. 34 First formally documented in May 1993 by RFC 1459 [IRC], the 35 protocol has kept evolving. This document is an update describing the 36 architecture of the current IRC protocol and the role of its 37 different components. Other documents describe in detail the 38 protocol used between the various components defined here. 40 Table of Contents 42 1. Introduction ............................................... 2 44 2. Components ................................................. 2 45 2.1 Servers ................................................ 2 46 2.2 Clients ................................................ 2 47 2.2.1 User Clients ...................................... 2 48 2.2.2 Service Clients ................................... 2 50 3. Architecture ............................................... 3 52 4. IRC Protocol Services ...................................... 3 53 4.1 Client Locator ......................................... 3 54 4.2 Message Relaying ....................................... 4 55 4.3 Channel Hosting And Management ......................... 4 57 5. IRC Concepts ............................................... 4 58 5.1 One-To-One Communication ............................... 4 59 5.2 One-To-Many ............................................ 5 60 5.2.1 To A Channel ...................................... 5 61 5.2.2 To A Host/Server Mask ............................. 5 62 5.2.3 To A List ......................................... 5 63 5.3 One-To-All ............................................. 6 64 5.3.1 Client-to-Client .................................. 6 65 5.3.2 Client-to-Server .................................. 6 66 5.3.3 Server-to-Server .................................. 6 68 6. Current Problems ........................................... 6 69 6.1 Scalability ............................................ 6 70 6.2 Reliability ............................................ 7 71 6.3 Network Congestion ..................................... 7 72 6.4 Privacy ................................................ 7 74 7. Security Considerations .................................... 7 76 8. Current Support And Availability ........................... 7 78 9. Acknowledgements ........................................... 8 80 10. References ................................................ 8 82 11. Author's Address .......................................... 8 84 1. Introduction 86 The IRC (Internet Relay Chat) protocol has been designed over a 87 number of years for use with text based conferencing. This document 88 describes its current architecture. 90 The IRC Protocol is based on the client-server model, and is well 91 suited to running on many machines in a distributed fashion. A 92 typical setup involves a single process (the server) forming a 93 central point for clients (or other servers) to connect to, 94 performing the required message delivery/multiplexing and other 95 functions. 97 This distributed model, which requires each server to have a copy 98 of the global state information, is still the most flagrant problem 99 of the protocol as it is a serious handicap, which limits the maximum 100 size a network can reach. If the existing networks have been able to 101 keep growing at an incredible pace, we must thank hardware 102 manufacturers for giving us ever more powerful systems. 104 2. Components 106 The following paragraphs define the basic components of the IRC 107 protocol. 109 2.1 Servers 111 The server forms the backbone of IRC as it is the only component 112 of the protocol which is able to link all the other components 113 together: it provides a point to which clients may connect to talk to 114 each other [IRC-CLIENT], and a point for other servers to connect to 115 [IRC-SERVER]. The server is also responsible for providing the basic 116 services defined by the IRC protocol. 118 2.2 Clients 120 A client is anything connecting to a server that is not another 121 server. There are two types of clients which both serve a different 122 purpose. 124 2.2.1 User Clients 126 User clients are generally programs providing a text based 127 interface that is used to communicate interactively via IRC. This 128 particular type of clients is often referred as "users". 130 2.2.2 Service Clients 131 Unlike users, service clients are not intended to be used manually 132 nor for talking. They have a more limited access to the chat 133 functions of the protocol, while optionally having access to more 134 private data from the servers. 136 Services are typically automatons used to provide some kind of 137 service (not necessarily related to IRC itself) to users. An example 138 is a service collecting statistics about the origin of users 139 connected on the IRC network. 141 3. Architecture 143 An IRC network is defined by a group of servers connected to each 144 other. A single server forms the simplest IRC network. 146 The only network configuration allowed for IRC servers is that of 147 a spanning tree where each server acts as a central node for the rest 148 of the network it sees. 150 1--\ 151 A D---4 152 2--/ \ / 153 B----C 154 / \ 155 3 E 157 Servers: A, B, C, D, E Clients: 1, 2, 3, 4 159 [ Fig. 1. Sample small IRC network ] 161 The IRC protocol provides no mean for two clients to directly commu� 162 nicate. All communication between clients is relayed by the server(s). 164 4. IRC Protocol Services 166 This section describes the services offered by the IRC protocol. 167 The combination of these services allow real-time conferencing. 169 4.1 Client Locator 171 To be able to exchange messages, two clients must be able to 172 locate each other. 174 Upon connecting to a server, a client registers using a label 175 which is then used by other servers and clients to know where the 176 client is located. Servers are responsible for keeping track of all 177 the labels being used. 179 4.2 Message Relaying 181 The IRC protocol provides no mean for two clients to directly com� 182 municate. All communication between clients is relayed by the 183 server(s). 185 4.3 Channel Hosting And Management 187 A channel is a named group of one or more users which will all 188 receive messages addressed to that channel. A channel is character� 189 ized by its name and current members, it also has a set of properties 190 which can be manipulated by (some of) its members. 192 Channels provide a mean for a message to be sent to several 193 clients. Servers host channels, providing the necessary message mul� 194 tiplexing. Servers are also responsible for managing channels by 195 keeping track of the channel members. The exact role of servers is 196 defined in "Internet Relay Chat: Channel Management" [IRC-CHAN]. 198 5. IRC Concepts 200 This section is devoted to describing the actual concepts behind 201 the organization of the IRC protocol and how different classes of 202 messages are delivered. 204 5.1 One-To-One Communication 206 Communication on a one-to-one basis is usually performed by 207 clients, since most server-server traffic is not a result of servers 208 talking only to each other. To provide a means for clients to talk 209 to each other, it is REQUIRED that all servers be able to send a mes� 210 sage in exactly one direction along the spanning tree in order to 211 reach any client. Thus the path of a message being delivered is the 212 shortest path between any two points on the spanning tree. 214 The following examples all refer to Figure 1 above. 216 Example 1: 217 A message between clients 1 and 2 is only seen by server A, which 218 sends it straight to client 2. 220 Example 2: 221 A message between clients 1 and 3 is seen by servers A & B, and 222 client 3. No other clients or servers are allowed see the message. 224 Example 3: 225 A message between clients 2 and 4 is seen by servers A, B, C & D 226 and client 4 only. 228 5.2 One-To-Many 230 The main goal of IRC is to provide a forum which allows easy and 231 efficient conferencing (one to many conversations). IRC offers sev� 232 eral means to achieve this, each serving its own purpose. 234 5.2.1 To A Channel 236 In IRC the channel has a role equivalent to that of the multicast 237 group; their existence is dynamic and the actual conversation carried 238 out on a channel MUST only be sent to servers which are supporting 239 users on a given channel. Moreover, the message SHALL only be sent 240 once to every local link as each server is responsible to fan the 241 original message to ensure that it will reach all the recipients. 243 The following examples all refer to Figure 2. 245 Example 4: 246 Any channel with 1 client in it. Messages to the channel go to the 247 server and then nowhere else. 249 Example 5: 250 2 clients in a channel. All messages traverse a path as if they 251 were private messages between the two clients outside a channel. 253 Example 6: 254 Clients 1, 2 and 3 in a channel. All messages to the channel are 255 sent to all clients and only those servers which must be traversed 256 by the message if it were a private message to a single client. If 257 client 1 sends a message, it goes back to client 2 and then via 258 server B to client 3. 260 5.2.2 To A Host/Server Mask 262 To provide with some mechanism to send messages to a large body of 263 related users, host and server mask messages are available. These 264 messages are sent to users whose host or server information match 265 that of the mask. The messages are only sent to locations where 266 users are, in a fashion similar to that of channels. 268 5.2.3 To A List 270 The least efficient style of one-to-many conversation is through 271 clients talking to a 'list' of targets (client, channel, mask). How 272 this is done is almost self explanatory: the client gives a list of 273 destinations to which the message is to be delivered and the server 274 breaks it up and dispatches a separate copy of the message to each 275 given destination. 277 This is not as efficient as using a channel since the destination 278 list MAY be broken up and the dispatch sent without checking to make 279 sure duplicates aren't sent down each path. 281 5.3 One-To-All 283 The one-to-all type of message is better described as a broadcast 284 message, sent to all clients or servers or both. On a large network 285 of users and servers, a single message can result in a lot of traffic 286 being sent over the network in an effort to reach all of the desired 287 destinations. 289 For some class of messages, there is no option but to broadcast it 290 to all servers so that the state information held by each server is 291 consistent between servers. 293 5.3.1 Client-to-Client 295 There is no class of message which, from a single message, results 296 in a message being sent to every other client. 298 5.3.2 Client-to-Server 300 Most of the commands which result in a change of state information 301 (such as channel membership, channel mode, user status, etc) MUST be 302 sent to all servers by default, and this distribution SHALL NOT be 303 changed by the client. 305 5.3.3 Server-to-Server 307 While most messages between servers are distributed to all 'other' 308 servers, this is only required for any message that affects a user, 309 channel or server. Since these are the basic items found in IRC, 310 nearly all messages originating from a server are broadcast to all 311 other connected servers. 313 6. Current Problems 315 There are a number of recognized problems with this protocol, this 316 section only addresses the problems related to the architecture of 317 the protocol. 319 6.1 Scalability 320 It is widely recognized that this protocol does not scale suffi� 321 ciently well when used in a large arena. The main problem comes from 322 the requirement that all servers know about all other servers, 323 clients and channels and that information regarding them be updated 324 as soon as it changes. 326 6.2 Reliability 328 As the only network configuration allowed for IRC servers is that 329 of a spanning tree, each link between two servers is an obvious and 330 quite serious point of failure. This particular issue is addressed 331 more in detail in "Internet Relay Chat: Server Protocol" [IRC- 332 SERVER]. 334 6.3 Network Congestion 336 Another problem related to the scalability and reliability issues, 337 as well as the spanning tree architecture, is that the protocol and 338 architecture for IRC are extremely vulnerable to network congestions. 339 This problem is endemic, and should be solved for the next genera� 340 tion: if congestion and high traffic volume cause a link between two 341 servers to fail, not only this failure generates more network traf� 342 fic, but the reconnection (eventually elsewhere) of two servers also 343 generates more traffic. 345 In an attempt to minimize the impact of these problems, it is 346 strongly RECOMMENDED that servers do not automatically try to recon� 347 nect too fast, in order to avoid aggravating the situation. 349 6.4 Privacy 351 Besides not scaling well, the fact that servers need to know all 352 information about other entities, the issue of privacy is also a con� 353 cern. This is in particular true for channels, as the related infor� 354 mation is quite a lot more revealing than whether a user is online or 355 not. 357 7. Security Considerations 359 Asides from the privacy concerns mentionned in section 6.4 (Pri� 360 vacy), security is believed to be irrelevant to this document. 362 8. Current Support And Availability 364 Mailing lists for IRC related discussion: 365 General discussion: ircd-users@irc.org 366 Protocol development: ircd-dev@irc.org 368 Software implementations: 369 ftp://ftp.irc.org/irc/server 370 ftp://ftp.funet.fi/pub/unix/irc 371 ftp://coombs.anu.edu.au/pub/irc 373 Newsgroup: alt.irc 375 9. Acknowledgements 377 Parts of this document were copied from the RFC 1459 [IRC] which 378 first formally documented the IRC Protocol. It has also benefited 379 from many rounds of review and comments. In particular, the follow� 380 ing people have made significant contributions to this document: 382 Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa 383 Ruokonen, Magnus Tjernstrom, Stefan Zehl. 385 10. References 387 [KEYWORDS] "Key words for use in RFCs to Indicate Requirement Levels", 388 Network Working Group RFC 2119, S. Bradner, March 1997. 390 [IRC] "Internet Relay Chat Protocol", Network Working Group RFC 1459, 391 J. Oikarinen & D. Reed, May 1993 393 [IRC-CLIENT] "Internet Relay Chat: Client Protocol", 394 Work In Progress: draft-kalt-irc-client-xx.txt 396 [IRC-SERVER] "Internet Relay Chat: Server Protocol", 397 Work In Progress: draft-kalt-irc-server-xx.txt 399 [IRC-CHAN] "Internet Relay Chat: Channel Management", 400 Work In Progress: draft-kalt-irc-chan-xx-txt 402 11. Author's Address 404 Christophe Kalt 405 99 Teaneck Rd, Apt #117 406 Ridgefield Park, NJ 07660 407 USA 409 Email: kalt@stealth.net