archive

- Random tools & helpful resources for IRC
git clone git://git.acid.vegas/archive.git
Log | Files | Refs | Archive

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