 |
|
CowCulture 2810 IRC - Internet Relay Chat: Architecture
|
 Status of this Memo [166 B] 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 [70 B] Copyright (C) The Internet Society (2000). All Rights Reserved.
__
Abstract [545 B] 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 __
Table of Contents [2.18 KB]
1. Introduction [935 B] 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
__
2. Components [82 B] The following paragraphs define the basic components of the IRC
protocol.
__
2.1 Servers [396 B] 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 fo __
2.2 Clients [153 B] 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 [204 B] 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 [477 B] 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 __
3. Architecture [740 B] 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 centr __
4. IRC Protocol Services [138 B] This section describes the services offered by the IRC protocol. The
combination of these services allow real-time conferencing.
__
4.1 Client Locator [321 B] 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. Server __
4.2 Message Relaying [150 B] 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 [615 B] 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) __
5. IRC Concepts [166 B] 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 [932 B] 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 se __
5.2 One-To-Many [201 B] 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 [1.05 KB] 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 __
5.2.2 To A Host/Server Mask [335 B] 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 on __
5.2.3 To A List [565 B] 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 __
5.3 One-To-All [477 B] 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 __
5.3.1 Client-to-Client [122 B] 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 [241 B] 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 [310 B] 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 __
6. Current Problems [159 B] 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 [304 B] 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 __
6.2 Reliability [301 B] 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 Rel __
6.3 Network Congestion [655 B] Another problem related to the scalability and reliability issues, as
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 traf __
6.4 Privacy [292 B] 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 t __
7. Security Considerations [133 B] 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 [336 B] 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 __
9. Acknowledgements [333 B] 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
document:
Matthew Green, Michael Neumayer __
10. References [617 B] [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 __
11. Author's Address [105 B] Christophe Kalt
99 Teaneck Rd, Apt #117
Ridgefield Park, NJ 07660
EMail: kalt@stealth.net
__
12. Full Copyright Statement [1.43 KB] 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 __
Acknowledgement [91 B] Funding for the RFC Editor function is currently provided by the
Internet Society.
__
|
Gogloom.com - Loading
- Please, wait
Search Examples: