 |
|
CowCulture 2813 IRC - Internet Relay Chat: Server Protocol
|
 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 [596 B] While based on the client-server model, the IRC (Internet Relay Chat)
protocol allows servers to connect to each other effectively forming
a network.
This document defines the protocol used by servers to talk to each
other. It was or __
Table of Contents [4.01 KB]
1. Introduction [512 B] This document is intended for people working on implementing an IRC
server but will also be useful to anyone implementing an IRC service.
Servers provide the three basic services required for realtime
conferencing defined by the "In __
2. Global database [216 B] Although the IRC Protocol defines a fairly distributed model, each
server maintains a "global state database" about the whole IRC
network. This database is, in theory, identical on all servers.
__
2.1 Servers [731 B] Servers are uniquely identified by their name which has a maximum
length of sixty three (63) characters. See the protocol grammar
rules (section 3.3.1) for what may and may not be used in a server
name.
Each server is typically known __
2.2 Clients [199 B] For each client, all servers MUST have the following information: a
netwide unique identifier (whose format depends on the type of
client) and the server to which the client is connected.
__
2.2.1 Users [465 B] Each user is distinguished from other users by a unique nickname
having a maximum length of nine (9) characters. See the protocol
grammar rules (section 3.3.1) for what may and may not be used in a
nickname. In addition to the nickname, __
2.2.2 Services [1022 B] Each service is distinguished from other services by a service name
composed of a nickname and a server name. The nickname has a maximum
length of nine (9) characters. See the protocol grammar rules
(section 3.3.1) for what may and may __
2.3 Channels [238 B] Alike services, channels have a scope [IRC-CHAN] and are not
necessarily known to all servers. When a channel existence is known
to a server, the server MUST keep track of the channel members, as
well as the channel modes.
__
3. The IRC Server Specification [1 B]
3.1 Overview [306 B] The protocol as described herein is for use with server to server
connections. For client to server connections, see the IRC Client
Protocol specification.
There are, however, more restrictions on client connections (which
are consid __
3.2 Character codes [720 B] No specific character set is specified. The protocol is based on a a
set of codes which are composed of eight (8) bits, making up an
octet. Each message may be composed of any number of these octets;
however, some octet values are used f __
3.3 Messages [2.55 KB] Servers and clients send each other messages which may or may not
generate a reply. Most communication between servers do not generate
any reply, as servers mostly perform routing tasks for the clients.
Each IRC message may consist of u __
3.3.1 Message format in Augmented BNF [777 B] The protocol messages must be extracted from the contiguous stream of
octets. The current solution is to designate two characters, CR and
LF, as message separators. Empty messages are silently ignored,
which permits use of the sequence __
3.4 Numeric replies [692 B] Most of the messages sent to the server generate a reply of some
sort. The most common reply is the numeric reply, used for both
errors and normal replies. The numeric reply MUST be sent as one
message consisting of the sender prefix, t __
4. Message Details [1.74 KB] All the messages recognized by the IRC server and client are
described in the IRC Client Protocol specification.
Where the reply ERR_NOSUCHSERVER is returned, it means that the
target of the message could not be found. The server MUST N __
4.1 Connection Registration [95 B] The commands described here are used to register a connection with
another IRC server.
__
4.1.1 Password message [2.19 KB] Command: PASS
Parameters: <password> <version> <flags> [<options>]
The PASS command is used to set a 'connection password'. The
password MUST be set before any attempt to register the connection is
made. C __
4.1.2 Server message [3.19 KB] Command: SERVER
Parameters: <servername> <hopcount> <token> <info>
The SERVER command is used to register a new server. A new connection
introduces itself as a server to its peer. This message is also used
__
4.1.3 Nick [1.53 KB] Command: NICK
Parameters: <nickname> <hopcount> <username> <host> <servertoken>
<umode> <realname>
This form of the NICK message MUST NOT be allowed from user
connections. Howev __
4.1.4 Service message [1.87 KB] Command: SERVICE
Parameters: <servicename> <servertoken> <distribution> <type>
<hopcount> <info>
The SERVICE command is used to introduce a new service. This form of
the SERVICE mes __
4.1.5 Quit [1.4 KB] Command: QUIT
Parameters: [<Quit Message>]
A client session ends with a quit message. The server MUST close the
connection to a client which sends a QUIT message. If a "Quit
Message" is given, this will be sent ins __
4.1.6 Server quit message [2.6 KB] Command: SQUIT
Parameters: <server> <comment>
The SQUIT message has two distinct uses.
The first one (described in "Internet Relay Chat: Client Protocol"
[IRC-CLIENT]) allows operators to break a local or rem __
4.2 Channel operations [494 B] This group of messages is concerned with manipulating channels, their
properties (channel modes), and their contents (typically users). In
implementing these, a number of race conditions are inevitable when
users at opposing ends of a ne __
4.2.1 Join message [1.35 KB] Command: JOIN
Parameters: <channel>[ %x7 <modes> ]
*( "," <channel>[ %x7 <modes> ] )
The JOIN command is used by client to start listening a specific
channel. Whether or not a client is __
4.2.2 Njoin message [1.34 KB] Command: NJOIN
Parameters: <channel> [ "@@" / "@" ] [ "+" ] <nickname>
*( "," [ "@@" / "@" ] [ "+" ] <nickname> )
The NJOIN __
4.2.3 Mode message [421 B] The MODE message is a dual-purpose command in IRC. It allows both
usernames and channels to have their mode changed.
When parsing MODE messages, it is RECOMMENDED that the entire message
be parsed first, and then the changes which resul __
5. Implementation details [752 B] A the time of writing, the only current implementation of this
protocol is the IRC server, version 2.10. Earlier versions may
implement some or all of the commands described by this document with
NOTICE messages replacing many of the nume __
5.1 Connection 'Liveness' [383 B] To detect when a connection has died or become unresponsive, the
server MUST poll each of its connections. The PING command (See "IRC
Client Protocol" [IRC-CLIENT]) is used if the server doesn't get a
response from its peer in __
5.2 Accepting a client to server connection [1 B]
5.2.1 Users [996 B] REQUIRED to send to the user unambiguous messages stating: the user
identifiers upon which it was registered (RPL_WELCOME), the server
name and version (RPL_YOURHOST), the server birth information
(RPL_CREATED), available user and channel __
5.2.2 Services [507 B] Upon successfully registering a new service connection, the server is
subject to the same kind of REQUIREMENTS as for a user. Services
being somewhat different, only the following replies are sent:
RPL_YOURESERVICE, RPL_YOURHOST, RPL_MYI __
5.3 Establishing a server-server connection. [678 B] The process of establishing a server-to-server connection is fraught
with danger since there are many possible areas where problems can
occur - the least of which are race conditions.
After a server has received a connection following by __
5.3.1 Link options [173 B] Server links are based on a common protocol (defined by this
document) but a particular link MAY set specific options using the
PASS message (See Section 4.1.1).
__
5.3.1.1 Compressed server to server links [573 B] If a server wishes to establish a compressed link with its peer, it
MUST set the 'Z' flag in the options parameter to the PASS message.
If both servers request compression and both servers are able to
initialize the two compressed streams __
5.3.1.2 Anti abuse protections [666 B] Most servers implement various kinds of protections against possible
abusive behaviours from non trusted parties (typically users). On
some networks, such protections are indispensable, on others they are
superfluous. To require that al __
5.3.2 State information exchange when connecting [1.04 KB] The order of state information being exchanged between servers is
essential. The REQUIRED order is as follows:
* all known servers;
* all known client information;
* all known channel information.
Inform __
5.4 Terminating server-client connections [204 B] When a client connection unexpectedly closes, a QUIT message is
generated on behalf of the client by the server to which the client
was connected. No other message is to be generated or used.
__
5.5 Terminating server-server connections [357 B] If a server-server connection is closed, either via a SQUIT command
or "natural" causes, the rest of the connected IRC network MUST have
its information updated by the server which detected the closure.
The terminating server th __
5.6 Tracking nickname changes [1.06 KB] All IRC servers are REQUIRED to keep a history of recent nickname
changes. This is important to allow the server to have a chance of
keeping in touch of things when nick-change race conditions occur
with commands manipulating them. Mess __
5.7 Tracking recently used nicknames [882 B] This mechanism is commonly known as "Nickname Delay", it has been
proven to significantly reduce the number of nickname collisions
resulting from "network splits"/reconnections as well as abuse.
In addition of keeping __
5.8 Flood control of clients [1.01 KB] With a large network of interconnected IRC servers, it is quite easy
for any single client attached to the network to supply a continuous
stream of messages that result in not only flooding the network, but
also degrading the level of ser __
5.9 Non-blocking lookups [473 B] In a real-time environment, it is essential that a server process
does as little waiting as possible so that all the clients are
serviced fairly. Obviously this requires non-blocking IO on all
network read/write operations. For normal s __
5.9.1 Hostname (DNS) lookups [365 B] Using the standard resolver libraries from Berkeley and others has
meant large delays in some cases where replies have timed out. To
avoid this, a separate set of DNS routines were written for the
current implementation. Routines were s __
5.9.2 Username (Ident) lookups [402 B] Although there are numerous ident libraries (implementing the
"Identification Protocol" [IDENT]) for use and inclusion into other
programs, these caused problems since they operated in a synchronous
manner and resulted in freque __
6. Current problems [234 B] There are a number of recognized problems with this protocol, all of
which are hoped to be solved sometime in the near future during its
rewrite. Currently, work is underway to find working solutions to
these problems.
__
6.1 Scalability [402 B] It is widely recognized that this protocol does not scale
from the requirement that all servers know about all other servers
and clients and that information regarding them be updated as soon as
it changes. It is also desirable to keep t __
6.2 Labels [517 B] The current IRC protocol has 4 types of labels: the nickname, the
channel name, the server name and the service name. Each of the four
types has its own domain and no duplicates are allowed inside that
domain. Currently, it is possible __
6.2.1 Nicknames [470 B] The idea of the nickname on IRC is very convenient for users to use
when talking to each other outside of a channel, but there is only a
finite nickname space and being what they are, it's not uncommon for
several people to want to use th __
6.2.2 Channels [598 B] The current channel layout requires that all servers know about all
channels, their inhabitants and properties. Besides not scaling
well, the issue of privacy is also a concern. A collision of
channels is treated as an inclusive event ( __
6.2.3 Servers [210 B] Although the number of servers is usually small relative to the
number of users and channels, they too are currently REQUIRED to be
known globally, either each one separately or hidden behind a mask.
__
6.3 Algorithms [831 B] In some places within the server code, it has not been possible to
avoid N^2 algorithms such as checking the channel list of a set of
clients.
In current server versions, there are only few database consistency
checks, most of the tim __
7. Security Considerations [1 B]
7.1 Authentication [1.05 KB] Servers only have two means of authenticating incoming connections:
plain text password, and DNS lookups. While these methods are weak
and widely recognized as unsafe, their combination has proven to be
sufficient in the past:
* pub __
7.2 Integrity [211 B] Since the PASS and OPER messages of the IRC protocol are sent in
clear text, a stream layer encryption mechanism (like "The TLS
Protocol" [TLS]) could be used to protect these transactions.
__
8. Current support and availability [320 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/pub/unix/ir __
9. Acknowledgements [397 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
following people have made significant contri __
10. References [1.28 KB] [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specification __
11. Author's Address [111 B] Christophe Kalt
99 Teaneck Rd, Apt #117
Ridgefield Park, NJ 07660
USA
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: