123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561 |
-
-
-
-
- Network Working Group C. Kalt
- Request for Comments: 2810 April 2000
- Updates: 1459
- Category: Informational
-
-
- Internet Relay Chat: Architecture
-
- Status of this Memo
-
- This memo provides information for the Internet community. It does
- not specify an Internet standard of any kind. Distribution of this
- memo is unlimited.
-
- Copyright Notice
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
- 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.
-
- Table of Contents
-
- 1. Introduction ............................................... 2
- 2. Components ................................................. 2
- 2.1 Servers ................................................ 2
- 2.2 Clients ................................................ 3
- 2.2.1 User Clients ...................................... 3
- 2.2.2 Service Clients ................................... 3
- 3. Architecture ............................................... 3
- 4. IRC Protocol Services ...................................... 4
- 4.1 Client Locator ......................................... 4
- 4.2 Message Relaying ....................................... 4
- 4.3 Channel Hosting And Management ......................... 4
- 5. IRC Concepts ............................................... 4
- 5.1 One-To-One Communication ............................... 5
- 5.2 One-To-Many ............................................ 5
- 5.2.1 To A Channel ...................................... 5
- 5.2.2 To A Host/Server Mask ............................. 6
-
-
-
- Kalt Informational [Page 1]
-
- RFC 2810 Internet Relay Chat: Architecture April 2000
-
-
- 5.2.3 To A List ......................................... 6
- 5.3 One-To-All ............................................. 6
- 5.3.1 Client-to-Client .................................. 6
- 5.3.2 Client-to-Server .................................. 7
- 5.3.3 Server-to-Server .................................. 7
- 6. Current Problems ........................................... 7
- 6.1 Scalability ............................................ 7
- 6.2 Reliability ............................................ 7
- 6.3 Network Congestion ..................................... 7
- 6.4 Privacy ................................................ 8
- 7. Security Considerations .................................... 8
- 8. Current Support And Availability ........................... 8
- 9. Acknowledgements ........................................... 8
- 10. References ................................................ 8
- 11. Author's Address .......................................... 9
- 12. Full Copyright Statement .................................. 10
-
- 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
-
-
-
-
- Kalt Informational [Page 2]
-
- RFC 2810 Internet Relay Chat: Architecture April 2000
-
-
- 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
-
- 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 ]
-
-
-
-
- Kalt Informational [Page 3]
-
- RFC 2810 Internet Relay Chat: Architecture April 2000
-
-
- The IRC protocol provides no mean for two clients to directly
- communicate. 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 the labels
- being used.
-
- 4.2 Message Relaying
-
- The IRC protocol provides no mean for two clients to directly
- communicate. 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
- characterized 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 multiplexing.
- 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.
-
-
-
-
-
-
-
-
- Kalt Informational [Page 4]
-
- RFC 2810 Internet Relay Chat: Architecture April 2000
-
-
- 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 message 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.
-
- 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
- several 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.
-
-
-
-
-
-
- Kalt Informational [Page 5]
-
- RFC 2810 Internet Relay Chat: Architecture April 2000
-
-
- 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
- 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.
-
-
-
-
-
-
-
-
- Kalt Informational [Page 6]
-
- RFC 2810 Internet Relay Chat: Architecture April 2000
-
-
- 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
-
- It is widely recognized that this protocol does not scale
- sufficiently 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
- generation: if congestion and high traffic volume cause a link
- between two servers to fail, not only this failure generates more
- network traffic, but the reconnection (eventually elsewhere) of two
- servers also generates more traffic.
-
-
-
-
- Kalt Informational [Page 7]
-
- RFC 2810 Internet Relay Chat: Architecture April 2000
-
-
- In an attempt to minimize the impact of these problems, it is
- strongly RECOMMENDED that servers do not automatically try to
- reconnect 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
- concern. This is in particular true for channels, as the related
- information is quite a lot more revealing than whether a user is
- online or not.
-
- 7. Security Considerations
-
- Asides from the privacy concerns mentioned in section 6.4 (Privacy),
- 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
-
- 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
- following people have made significant contributions to this
- document:
-
- Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa
- Ruokonen, Magnus Tjernstrom, Stefan Zehl.
-
-
-
-
-
-
-
-
-
-
-
- Kalt Informational [Page 8]
-
- RFC 2810 Internet Relay Chat: Architecture April 2000
-
-
- 10. References
-
- [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat
- Protocol", RFC 1459, May 1993.
-
- [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
- 2812, April 2000.
-
- [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
- 2813, April 2000.
-
- [IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC
- 2811, April 2000.
-
- 11. Author's Address
-
- Christophe Kalt
- 99 Teaneck Rd, Apt #117
- Ridgefield Park, NJ 07660
- USA
-
- EMail: kalt@stealth.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Kalt Informational [Page 9]
-
- RFC 2810 Internet Relay Chat: Architecture April 2000
-
-
- 12. Full Copyright Statement
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
- Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Kalt Informational [Page 10]
-
|