Internet Relay Chat: Architecture
draft-kalt-irc-arch-00

Internet Draft                                                   C. Kalt
Expires: 22 Dec 1999                                         22 Jun 1999

                   Internet Relay Chat: Architecture
                       draft-kalt-irc-arch-00.txt

Status of this Memo

      This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups. Note that other groups may also distribute
   working documents as Internet Drafts.

      Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

      The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

      The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC 2119[1].

Abstract

      The IRC (Internet Relay Chat) protocol is for use with text based
   conferencing. It has been developed since 1989 when it was originally
   implemented as a mean for users on a BBS to chat amongst themselves.

      First formally documented in May 1993 by RFC 1459 [IRC], the
   protocol has kept evolving. This document is an update describing the
   architecture of the current IRC protocol and the role of its
   different components.  Other documents describe in detail the
   protocol used between the various components defined here.

Kalt                                                            [Page 1]
Internet Draft      Internet Relay Chat: Architecture        22 Jun 1999

                  Table of Contents

   1.  Introduction ...............................................   2

   2.  Components .................................................   2
      2.1  Servers ................................................   2
      2.2  Clients ................................................   2
         2.2.1  User Clients ......................................   2
         2.2.2  Service Clients ...................................   2

   3.  Architecture ...............................................   3

   4.  IRC Protocol Services ......................................   3
      4.1  Client Locator .........................................   3
      4.2  Message Relaying .......................................   4
      4.3  Channel Hosting And Management .........................   4

   5.  IRC Concepts ...............................................   4
      5.1  One-To-One Communication ...............................   4
      5.2  One-To-Many ............................................   5
         5.2.1  To A Channel ......................................   5
         5.2.2  To A Host/Server Mask .............................   5
         5.2.3  To A List .........................................   5
      5.3  One-To-All .............................................   6
         5.3.1  Client-to-Client ..................................   6
         5.3.2  Client-to-Server ..................................   6
         5.3.3  Server-to-Server ..................................   6

   6.  Current Problems ...........................................   6
      6.1  Scalability ............................................   6
      6.2  Reliability ............................................   7
      6.3  Network Congestion .....................................   7
      6.4  Privacy ................................................   7

   7.  Security Considerations ....................................   7

   8.  Current Support And Availability ...........................   7

   9.  Acknowledgements ...........................................   8

   10.  References ................................................   8

   11.  Author's Address ..........................................   8

Kalt                                                            [Page 2]
Internet Draft      Internet Relay Chat: Architecture        22 Jun 1999

1. Introduction

      The IRC (Internet Relay Chat) protocol has been designed over a
   number of years for use with text based conferencing.  This document
   describes its current architecture.

      The IRC Protocol is based on the client-server model, and is well
   suited to running on many machines in a distributed fashion.  A
   typical setup involves a single process (the server) forming a
   central point for clients (or other servers) to connect to,
   performing the required message delivery/multiplexing and other
   functions.

      This distributed model, which requires each server to have a copy
   of the global state information, is still the most flagrant problem
   of the protocol as it is a serious handicap, which limits the maximum
   size a network can reach.  If the existing networks have been able to
   keep growing at an incredible pace, we must thank hardware
   manufacturers for giving us ever more powerful systems.

2. Components

      The following paragraphs define the basic components of the IRC
   protocol.

2.1 Servers

      The server forms the backbone of IRC as it is the only component
   of the protocol which is able to link all the other components
   together: it provides a point to which clients may connect to talk to
   each other [IRC-CLIENT], and a point for other servers to connect to
   [IRC-SERVER].  The server is also responsible for providing the basic
   services defined by the IRC protocol.

2.2 Clients

      A client is anything connecting to a server that is not another
   server.  There are two types of clients which both serve a different
   purpose.

2.2.1 User Clients

      User clients are generally programs providing a text based
   interface that is used to communicate interactively via IRC.  This
   particular type of clients is often referred as "users".

2.2.2 Service Clients

Kalt                                                            [Page 3]
Internet Draft      Internet Relay Chat: Architecture        22 Jun 1999

      Unlike users, service clients are not intended to be used manually
   nor for talking.  They have a more limited access to the chat
   functions of the protocol, while optionally having access to more
   private data from the servers.

      Services are typically automatons used to provide some kind of
   service (not necessarily related to IRC itself) to users.  An example
   is a service collecting statistics about the origin of users
   connected on the IRC network.

3. Architecture

      An IRC network is defined by a group of servers connected to each
   other.  A single server forms the simplest IRC network.

      The only network configuration allowed for IRC servers is that of
   a spanning tree where each server acts as a central node for the rest
   of the network it sees.

                       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 ]

   The IRC protocol provides no mean for two clients to directly commu¡
nicate.  All communication between clients is relayed by the server(s).

4. IRC Protocol Services

      This section describes the services offered by the IRC protocol.
   The combination of these services allow real-time conferencing.

4.1 Client Locator

      To be able to exchange messages, two clients must be able to
   locate each other.

      Upon connecting to a server, a client registers using a label
   which is then used by other servers and clients to know where the
   client is located.  Servers are responsible for keeping track of all

Kalt                                                            [Page 4]
Internet Draft      Internet Relay Chat: Architecture        22 Jun 1999

   the labels being used.

4.2 Message Relaying

      The IRC protocol provides no mean for two clients to directly com¡
   municate.  All communication between clients is relayed by the
   server(s).

4.3 Channel Hosting And Management

      A channel is a named group of one or more users which will all
   receive messages addressed to that channel.  A channel is character¡
   ized by its name and current members, it also has a set of properties
   which can be manipulated by (some of) its members.

      Channels provide a mean for a message to be sent to several
   clients.  Servers host channels, providing the necessary message mul¡
   tiplexing.  Servers are also responsible for managing channels by
   keeping track of the channel members.  The exact role of servers is
   defined in "Internet Relay Chat: Channel Management" [IRC-CHAN].

5. IRC Concepts

      This section is devoted to describing the actual concepts behind
   the organization of the IRC protocol and how different classes of
   messages are delivered.

5.1 One-To-One Communication

      Communication on a one-to-one basis is usually performed by
   clients, since most server-server traffic is not a result of servers
   talking only to each other.  To provide a means for clients to talk
   to each other, it is REQUIRED that all servers be able to send a mes¡
   sage in exactly one direction along the spanning tree in order to
   reach any client.  Thus the path of a message being delivered is the
   shortest path between any two points on the spanning tree.

     The following examples 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 see the message.

Kalt                                                            [Page 5]
Internet Draft      Internet Relay Chat: Architecture        22 Jun 1999

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 provide a forum which allows easy and
   efficient conferencing (one to many conversations).  IRC offers sev¡
   eral means to achieve this, each serving its own purpose.

5.2.1 To A Channel

      In IRC the channel has a role equivalent to that of the multicast
   group; their existence is dynamic and the actual conversation carried
   out on a channel MUST only be sent to servers which are supporting
   users on a given channel.  Moreover, the message SHALL only be sent
   once to every local link as each server is responsible to fan the
   original message to ensure that it will reach all the recipients.

     The following examples 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 traverse a path as if they
     were 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 those servers which must be traversed
     by the message if it were a private message to a single client.  If
     client 1 sends a message, it goes back to client 2 and then via
     server B to client 3.

5.2.2 To A Host/Server Mask

      To provide with some mechanism to send messages to a large body of
   related users, host and server mask messages are available.  These
   messages are sent to users whose host or server information match
   that of the mask.  The messages are only sent to locations where
   users are, in a fashion similar to that of channels.

5.2.3 To A List

      The least efficient style of one-to-many conversation is through
   clients talking to a 'list' of targets (client, channel, mask).  How

Kalt                                                            [Page 6]
Internet Draft      Internet Relay Chat: Architecture        22 Jun 1999

   this is done is almost self explanatory: the client gives a list of
   destinations to which the message is to be delivered and the server
   breaks it up and dispatches a separate copy of the message to each
   given destination.

      This is not as efficient as using a channel since the destination
   list MAY be broken up and the dispatch sent without checking to make
   sure duplicates aren't sent down each path.

5.3 One-To-All

      The one-to-all type of message is better described as a broadcast
   message, sent to all clients or servers or both.  On a large network
   of users and servers, a single message can result in a lot of traffic
   being sent over the network in an effort to reach all of the desired
   destinations.

      For some class of messages, there is no option but to broadcast it
   to all servers so that the state information held by each server is
   consistent between servers.

5.3.1 Client-to-Client

      There is no class of message which, from a single message, results
   in a message being sent to every other client.

5.3.2 Client-to-Server

      Most of the commands which result in a change of state information
   (such as channel membership, channel mode, user status, etc) MUST be
   sent to all servers by default, and this distribution SHALL NOT be
   changed by the client.

5.3.3 Server-to-Server

      While most messages between servers are distributed to all 'other'
   servers, this is only required for any message that affects a user,
   channel or server.  Since these are the basic items found in IRC,
   nearly all messages originating from a server are broadcast to all
   other connected servers.

6. Current Problems

      There are a number of recognized problems with this protocol, this
   section only addresses the problems related to the architecture of
   the protocol.

6.1 Scalability

Kalt                                                            [Page 7]
Internet Draft      Internet Relay Chat: Architecture        22 Jun 1999

      It is widely recognized that this protocol does not scale suffi¡
   ciently well when used in a large arena.  The main problem comes from
   the requirement that all servers know about all other servers,
   clients and channels and that information regarding them be updated
   as soon as it changes.

6.2 Reliability

      As the only network configuration allowed for IRC servers is that
   of a spanning tree, each link between two servers is an obvious and
   quite serious point of failure.  This particular issue is addressed
   more in detail in "Internet Relay Chat: Server Protocol" [IRC-
   SERVER].

6.3 Network Congestion

      Another problem related to the scalability and reliability issues,
   as well as the spanning tree architecture, is that the protocol and
   architecture for IRC are extremely vulnerable to network congestions.
   This problem is endemic, and should be solved for the next genera¡
   tion: if congestion and high traffic volume cause a link between two
   servers to fail, not only this failure generates more network traf¡
   fic, but the reconnection (eventually elsewhere) of two servers also
   generates more traffic.

      In an attempt to minimize the impact of these problems, it is
   strongly RECOMMENDED that servers do not automatically try to recon¡
   nect too fast, in order to avoid aggravating the situation.

6.4 Privacy

      Besides not scaling well, the fact that servers need to know all
   information about other entities, the issue of privacy is also a con¡
   cern.  This is in particular true for channels, as the related infor¡
   mation is quite a lot more revealing than whether a user is online or
   not.

7. Security Considerations

      Asides from the privacy concerns mentionned in section 6.4 (Pri¡
   vacy), security is believed to be irrelevant to this document.

8. Current Support And Availability

        Mailing lists for IRC related discussion:
          General discussion: ircd-users@irc.org
          Protocol development: ircd-dev@irc.org

Kalt                                                            [Page 8]
Internet Draft      Internet Relay Chat: Architecture        22 Jun 1999

        Software implementations:
          ftp://ftp.irc.org/irc/server
          ftp://ftp.funet.fi/pub/unix/irc
          ftp://coombs.anu.edu.au/pub/irc

        Newsgroup: alt.irc

9. Acknowledgements

      Parts of this document were copied from the RFC 1459 [IRC] which
   first formally documented the IRC Protocol.  It has also benefited
   from many rounds of review and comments.  In particular, the follow¡
   ing people have made significant contributions to this document:

   Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa
   Ruokonen, Magnus Tjernstrom, Stefan Zehl.

10. References

     [KEYWORDS] "Key words for use in RFCs to Indicate Requirement Levels",
         Network Working Group RFC 2119, S. Bradner, March 1997.

     [IRC] "Internet Relay Chat Protocol", Network Working Group RFC 1459,
         J. Oikarinen & D. Reed, May 1993

     [IRC-CLIENT] "Internet Relay Chat: Client Protocol",
         Work In Progress: draft-kalt-irc-client-xx.txt

     [IRC-SERVER] "Internet Relay Chat: Server Protocol",
         Work In Progress: draft-kalt-irc-server-xx.txt

     [IRC-CHAN] "Internet Relay Chat: Channel Management",
         Work In Progress: draft-kalt-irc-chan-xx-txt

11. Author's Address

          Christophe Kalt
          99 Teaneck Rd, Apt #117
          Ridgefield Park, NJ 07660
          USA

          Email: kalt@stealth.net

Kalt                                                            [Page 9]
Internet Draft      Internet Relay Chat: Architecture        22 Jun 1999

Kalt                                                           [Page 10]