 |
|
CowCulture 1459 IRCP - Internet Relay Chat Protocol
|
 Status of This Memo [333 B] This memo defines an Experimental Protocol for the Internet
community. Discussion and suggestions for improvement are requested.
Please refer to the current edition of the "IAB Official Protocol
Standards" for the standardizati __
Abstract [513 B] The IRC protocol was developed over the last 4 years since it was
first implemented as a means for users on a BBS to chat amongst
themselves. Now it supports a world-wide network of servers and
clients, and is stringing to cope with grow __
Table of Contents [7.56 KB]
1. INTRODUCTION [741 B] The IRC (Internet Relay Chat) protocol has been designed over a
number of years for use with text based conferencing. This document
describes the current IRC protocol.
The IRC protocol has been developed on systems using the TCP/IP
n __
1.1 Servers [1.29 KB] The server forms the backbone of IRC, providing a point to which
clients may connect to to talk to each other, and a point for other
servers to connect to, forming an IRC network. The only network
configuration allowed for IRC servers is __
1.2 Clients [540 B] A client is anything connecting to a server that is not another
server. Each client is distinguished from other clients by a unique
nickname having a maximum length of nine (9) characters. See the
protocol grammar rules for what may and __
1.2.1 Operators [1.01 KB] To allow a reasonable amount of order to be kept within the IRC
network, a special class of clients (operators) is allowed to perform
general maintenance functions on the network. Although the powers
granted to an operator can be conside __
1.3 Channels [2.54 KB] A channel is a named group of one or more clients which will all
receive messages addressed to that channel. The channel is created
implicitly when the first client joins it, and the channel ceases to
exist when the last client leaves it __
1.3.1 Channel Operators [1 KB] The channel operator (also referred to as a "chop" or "chanop") on a
given channel is considered to 'own' that channel. In recognition of
this status, channel operators are endowed with certain powers which
enable the __
2. The IRC Specification [1 B]
2.1 Overview [251 B] The protocol as described herein is for use both with server to
server and client to server connections. There are, however, more
restrictions on client connections (which are considered to be
untrustworthy) than on server connections.
__
2.2 Character codes [699 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 __
2.3 Messages [2 KB] Servers and clients send eachother messages which may or may not
generate a reply. If the message contains a valid command, as
described in later sections, the client should expect a reply as
specified but it is not advised to wait forev __
2.3.1 Message format in 'pseudo' BNF [3.59 KB] 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 __
2.4 Numeric replies [657 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 __
3. IRC Concepts. [540 B] This section is devoted to describing the actual concepts behind the
organization of the IRC protocol and how the current
implementations deliver different classes of messages.
1--
__
3.1 One-to-one communication [870 B] Communication on a one-to-one basis is usually only performed by
clients, since most server-server traffic is not a result of servers
talking only to each other. To provide a secure means for clients to
message in exactly one direction a __
3.2 One-to-many [207 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.
__
3.2.1 To a list [528 B] The least efficient style of one-to-many conversation is through
clients talking to a 'list' of users. 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 s __
3.2.2 To a group (channel) [1.24 KB] In IRC the channel has a role equivalent to that of the multicast
group; their existence is dynamic (coming and going as people join
and leave channels) and the actual conversation carried out on a
channel is only sent to servers which ar __
3.2.3 To a host/server mask [354 B] To provide IRC operators with some mechanism to send messages to a
large body of related users, host and server mask messages are
provided. These messages are sent to users whose host or server
information match that of the mask. __
3.3 One-to-all [480 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 __
3.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.
__
3.3.2 Client-to-Server [237 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 may not be
changed by the client.
__
3.3.3 Server-to-Server. [318 B] While most messages between servers are distributed to all 'other'
servers, this is only required for any message that affects either a
user, channel or server. Since these are the basic items found in
IRC, nearly all messages originati __
4. Message details [1.46 KB] On the following pages are descriptions of each message recognized by
the IRC server and client. All commands described in this section
must be implemented by any server for this protocol.
Where the reply ERR_NOSUCHSERVER is listed, it __
4.1 Connection Registration [569 B] The commands described here are used to register a connection with an
IRC server as either a user or a server as well as correctly
disconnect.
A "PASS" command is not required for either client or server
connection to be reg __
4.1.1 Password message [798 B] Command: PASS
Parameters: <password>
The PASS command is used to set a 'connection password'. The
password can and must be set before any attempt to register the
connection is made. Currently this requires that clients send __
4.1.2 Nick message [1.31 KB] Command: NICK
Parameters: <nickname> [ <hopcount> ]
NICK message is used to give user a nickname or change the previous
one. The <hopcount> parameter is only used by servers to indicate
how far away a nick is fro __
4.1.3 User message [1.97 KB] Command: USER
Parameters: <username> <hostname> <servername> <realname>
The USER message is used at the beginning of connection to specify
the username, hostname, servername and realname of s new user. It is
__
4.1.4 Server message [2.07 KB] Command: SERVER
Parameters: <servername> <hopcount> <info>
The server message is used to tell a server that the other end of a
new connection is a server. This message is also used to pass server
data over whole n __
4.1.5 Oper [881 B] Command: OPER
Parameters: <user> <password>
OPER message is used by a normal user to obtain operator privileges.
The combination of <user> and <password> are required to gain
Operator privileges.
If the __
4.1.6 Quit [1008 B] Command: QUIT
Parameters: [<Quit message>]
A client session is ended 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 __
4.1.7 Server quit message [2.34 KB] Command: SQUIT
Parameters: <server> <comment>
The SQUIT message is needed to tell about quitting or dead servers.
If a server wishes to break the connection to another server it must
send a SQUIT message to the other se __
4.2 Channel operations [497 B] This group of messages is concerned with manipulating channels, their
properties (channel modes), and their contents (typically clients).
In implementing these, a number of race conditions are inevitable
when clients at opposing ends of a __
4.2.1 Join message [2.18 KB] Command: JOIN
Parameters: <channel>{,<channel>} [<key>{,<key>}]
The JOIN command is used by client to start listening a specific
channel. Whether or not a client is allowed to join a channel is
checked only __
4.2.2 Part message [565 B] Parameters: <channel>{,<channel>}
The PART message causes the client sending the message to be removed
from the list of active users for all given channels listed in the
parameter string.
Numeric Replies:
ERR_ __
4.2.3 Mode message [421 B] Command: MODE
The MODE command is a dual-purpose command in IRC. It allows both
usernames and channels to have their mode changed. The rationale for
this choice is that one day nicknames will be obsolete and the
equivalent proper __
4.2.3.1 Channel modes [1.01 KB] Parameters: <channel> {[+|-]|o|p|s|i|t|n|b|v} [<limit>] [<user>]
[<ban mask>]
The MODE command is provided so that channel operators may change the
characteristics of `their' channel. It is also requi __
4.2.3.2 User modes [2.71 KB] Parameters: <nickname> {[+|-]|i|w|s|o}
The user MODEs are typically changes which affect either how the
client is seen by others or what 'extra' messages the client is sent.
A user MODE command may only be accepted if both the send __
4.2.4 Topic message [749 B] Command: TOPIC
Parameters: <channel> [<topic>]
The TOPIC message is used to change or view the topic of a channel.
The topic for channel <channel> is returned if there is no <topic>
given. If the <topic& __
4.2.5 Names message [1.07 KB] Command: NAMES
Parameters: [<channel>{,<channel>}]
By using the NAMES command, a user can list all nicknames that are
visible to them on any channel that they can see. Channel names
which they can see are those which a __
4.2.6 List message [746 B] Command: LIST
Parameters: [<channel>{,<channel>} [<server>]]
The list message is used to list channels and their topics. If the
<channel> parameter is used, only the status of that channel
topics) __
4.2.7 Invite message [1006 B] Command: INVITE
Parameters: <nickname> <channel>
The INVITE message is used to invite users to a channel. The
parameter <nickname> is the nickname of the person to be invited to
the target channel <channel> __
4.2.8 Kick command [1.23 KB] Command: KICK
Parameters: <channel> <user> [<comment>]
The KICK command can be used to forcibly remove a user from a
channel. It 'kicks them out' of the channel (forced PART).
Only a channel operator __
4.3 Server queries and commands [657 B] The server query group of commands has been designed to return
information about any server which is connected to the network. All
servers connected must respond to these queries and respond
correctly. Any invalid response (or lack ther __
4.3.1 Version message [649 B] Command: VERSION
Parameters: [<server>]
The VERSION message is used to query the version of the server
program. An optional parameter <server> is used to query the version
of the server program which a client is __
4.3.2 Stats message [2.72 KB] Command: STATS
Parameters: [<query> [<server>]]
The stats message is used to query statistics of certain server. If
<server> parameter is omitted, only the end of stats reply is sent
back. The implementation of __
4.3.3 Links message [957 B] Command: LINKS
Parameters: [[<remote server>] <server mask>]
With LINKS, a user can list all servers which are known by the server
answering the query. The returned list of servers must match the
mask, or if no mask is __
4.3.4 Time message [588 B] Command: TIME
Parameters: [<server>]
The time message is used to query local time from the specified
server. If the server parameter is not given, the server handling the
command must reply to the query.
Numeric Replies:
__
4.3.5 Connect message [899 B] Command: CONNECT
Parameters: <target server> [<port> [<remote server>]]
The CONNECT command can be used to force a server to try to establish
a new connection to another server immediately. CONNECT is a
privilege __
4.3.6 Trace message [1.75 KB] Command: TRACE
Parameters: [<server>]
TRACE command is used to find the route to specific server. Each
server that processes this message must tell the sender about it by
sending a reply indicating it is a pass-through link, __
4.3.7 Admin command [719 B] Command: ADMIN
Parameters: [<server>]
The admin message is used to find the name of the administrator of
the given server, or current server if <server> parameter is omitted.
Each server must have the ability to forward __
4.3.8 Info command [763 B] Command: INFO
Parameters: [<server>]
The INFO command is required to return information which describes
the server: its version, when it was compiled, the patchlevel, when
it was started, and any other miscellaneous informati __
4.4 Sending messages [347 B] The main purpose of the IRC protocol is to provide a base for clients
to communicate with each other. PRIVMSG and NOTICE are the only
messages available which actually perform delivery of a text message
from one client to another - the r __
4.4.1 Private messages [2.03 KB] Command: PRIVMSG
Parameters: <receiver>{,<receiver>} <text to be sent>
PRIVMSG is used to send private messages between users. <receiver>
is the nickname of the receiver of the message. <receiver> can a __
4.4.2 Notice [781 B] Command: NOTICE
Parameters: <nickname> <text>
The NOTICE message is used similarly to PRIVMSG. The difference
between NOTICE and PRIVMSG is that automatic replies must never be
sent in response to a NOTICE message. Th __
4.5 User based queries [403 B] User queries are a group of commands which are primarily concerned
with finding details on a particular user or group users. When using
wildcards with any of these commands, if they match, they will only
return information on users who a __
4.5.1 Who query [1.11 KB] Command: WHO
Parameters: [<name> [<o>]]
The WHO message is used by a client to generate a query which returns
a list of information which 'matches' the <name> parameter given by
(users who aren't invisible (user m __
4.5.2 Whois query [1.35 KB] Command: WHOIS
Parameters: [<server>] <nickmask>[,<nickmask>[,...]]
This message is used to query information about particular user. The
server will answer this message with several numeric messages
indicating di __
4.5.3 Whowas [1.42 KB] Command: WHOWAS
Parameters: <nickname> [<count> [<server>]]
Whowas asks for information about a nickname which no longer exists.
This may either be due to a nickname change or the user leaving IRC.
In response to __
4.6 Miscellaneous messages [144 B] Messages in this category do not fit into any of the above categories
but are nonetheless still a part of and required by the protocol.
__
4.6.1 Kill message [2 KB] Command: KILL
Parameters: <nickname> <comment>
The KILL message is used to cause a client-server connection to be
closed by the server which has the actual connection. KILL is used
by servers when they encounter a dupl __
4.6.2 Ping message [1.18 KB] Command: PING
Parameters: <server1> [<server2>]
The PING message is used to test the presence of an active client at
the other end of the connection. A PING message is sent at regular
intervals if no other activity det __
4.6.3 Pong message [533 B] Command: PONG
Parameters: <daemon> [<daemon2>]
PONG message is a reply to ping message. If parameter <daemon2> is
given this message must be forwarded to given daemon. The <daemon>
parameter is the name of __
4.6.4 Error [1.18 KB] Command: ERROR
Parameters: <error message>
The ERROR command is for use by servers when reporting a serious or
fatal error to its operators. It may also be sent from one server to
another but must not be accepted from any no __
5. OPTIONALS [1.2 KB] This section describes OPTIONAL messages. They are not required in a
working server implementation of the protocol described herein. In
the absence of the option, an error reply message must be generated
or an unknown command error. If __
5.2 Rehash message [454 B] Command: REHASH
Parameters: None
The rehash message can be used by the operator to force the server to
re-read and process its configuration file.
Numeric Replies:
RPL_REHASHING ERR_NOPRIVILEGES
Exampl __
5.3 Restart message [554 B] Command: RESTART
Parameters: None
restart itself. This message is optional since it may be viewed as a
risk to allow arbitrary people to connect to a server as an operator
and execute this command, causing (at least) a disruption __
5.4 Summon message [1.97 KB] Command: SUMMON
Parameters: <user> [<server>]
The SUMMON command can be used to give users who are on a host
running an IRC server a message asking them to please join IRC. This
message is only sent if the target serve __
5.6 Operwall message [787 B] Command: WALLOPS
Parameters: Text to be sent to all operators currently online
Sends a message to all operators currently online. After
implementing WALLOPS as a user command it was found that it was
often and commo __
5.7 Userhost message [605 B] Command: USERHOST
Parameters: <nickname>{<space><nickname>}
The USERHOST command takes a list of up to 5 nicknames, each
separated by a space character and returns a list of information
about each nickname that it __
5.8 Ison message [1.16 KB] Command: ISON
Parameters: <nickname>{<space><nickname>}
The ISON command was implemented to provide a quick and efficient
means to get a response about whether a given nickname was currently
on IRC. ISON only __
6. REPLIES [178 B] The following is a list of numeric replies which are generated in
response to the commands given above. Each numeric is given with its
number, name and reply string.
__
6.1 Error Replies. [10.28 KB] 401 ERR_NOSUCHNICK
"<nickname> :No such nick/channel"
- Used to indicate the nickname parameter supplied to a
command is currently unused.
402 ERR_NOS __
6.2 Command responses. [16.98 KB] 300 RPL_NONE
Dummy reply number. Not used.
302 RPL_USERHOST
":[<reply>{<space><reply>}]"
- Reply format used by USERHOST to list rep __
6.3 Reserved numerics. [785 B] These numerics are not described above since they fall into one of
the following categories:
1. no longer in use;
2. reserved for future planned use;
3. in current use but are part of a non-generic 'feature' of
__
7. Client and server authentication [993 B] Clients and servers are both subject to the same level of
authentication. For both, an IP number to hostname lookup (and
reverse check on this) is performed for all connections made to the
server. Both connections are then subject to a __
8. Current implementations [726 B] The only current implementation of this protocol is the IRC server,
version 2.8. Earlier versions may implement some or all of the
commands described by this document with NOTICE messages replacing
many of the numeric replies. Unfortuna __
8.1 Network protocol: TCP - why it is best used here. [260 B] IRC has been implemented on top of TCP since TCP supplies a reliable
network protocol which is well suited to this scale of conferencing.
The use of multicast IP is an alternative, but it is not widely
available or supported at the presen __
8.1.1 Support of Unix sockets [496 B] Given that Unix domain sockets allow listen/connect operations, the
current implementation can be configured to listen and accept both
client and server connections on a Unix domain socket. These are
recognized as sockets where the hostn __
8.2 Command Parsing [558 B] To provide useful 'non-buffered' network IO for clients and servers,
each connection is given its own private 'input buffer' in which the
results of the most recent read and parsing are kept. A buffer size
of 512 bytes is used so as to h __
8.3 Message delivery [845 B] are sending data unable to send data. Although Unix typically
handles this through the TCP window and internal buffers, the server
often has large amounts of data to send (especially when a new
server-server link forms) and the small buf __
8.4 Connection 'Liveness' [452 B] To detect when a connection has died or become unresponsive, the
server must ping each of its connections that it doesn't get a
response from in a given amount of time.
If a connection doesn't respond in time, its connection is closed
__
8.5 Establishing a server to client connection [641 B] Upon connecting to an IRC server, a client is sent the MOTD (if
present) as well as the current user/server count (as per the LUSER
command). The server is also required to give an unambiguous message
to the client which states its name __
8.6 Establishing a server-server connection. [618 B] The process of establishing of 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 __
8.6.1 Server exchange of state information when connecting [1 KB] The order of state information being exchanged between servers is
essential. The required order is as follows:
* all known other servers;
* all known user information;
* all known channel information.
Information __
8.7 Terminating server-client connections [187 B] When a client connection closes, a QUIT message is generated on
behalf of the client by the server to which the client connected. No
other message is to be generated or used.
__
8.8 Terminating server-server connections [327 B] If a server-server connection is closed, either via a remotely
generated SQUIT or 'natural' causes, the rest of the connected IRC
detected the closure. The server then sends a list of SQUITs (one
for each server behind that connection) a __
8.9 Tracking nickname changes [1.1 KB] All IRC servers are required to keep a history of recent nickname
changes. This is required to allow the server to have a chance of
keeping in touch of things when nick-change race conditions occur
with commands which manipulate them. C __
8.10 Flood control of clients [913 B] 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 __
8.11 Non-blocking lookups [471 B] In a real-time environment, it is essential that a server process do
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 ser __
8.11.1 Hostname (DNS) lookups [308 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 which were
setup for non-blocking IO operations __
8.11.2 Username (Ident) lookups [336 B] Although there are numerous ident libraries for use and inclusion
into other programs, these caused problems since they operated in a
synchronous manner and resulted in frequent delays. Again the
solution was to write a set of routines w __
8.12 Configuration File [1.32 KB] To provide a flexible way of setting up and running the server, it is
recommended that a configuration file be used which contains
instructions to the server on the following:
* which hosts to accept client connections from;
__
8.12.1 Allowing clients to connect [316 B] A server should use some sort of 'access control list' (either in the
configuration file or elsewhere) that is read at startup and used to
decide what hosts clients may use to connect to it.
Both 'deny' and 'allow' should be implemented __
8.12.2 Operators [535 B] The granting of operator privileges to a disruptive person can have
dire consequences for the well-being of the IRC net in general due to
the powers given to them. Thus, the acquisition of such powers
should not be very easy. The curren __
8.12.3 Allowing servers to connect [424 B] The interconnection of server is not a trivial matter: a bad
connection can have a large impact on the usefulness of IRC. Thus,
each server should have a list of servers to which it may connect and
which servers may connect to it. Under __
8.12.4 Administrivia [157 B] To provide accurate and valid replies to the ADMIN command (see
section 4.3.7), the server should find the relevant details in the
configuration.
__
8.13 Channel membership [245 B] The current server allows any registered local user to join upto 10
different channels. There is no limit imposed on non-local users so
that the server remains (reasonably) consistant with all others on a
channel membership basis
__
9. Current problems [231 B] There are a number of recognized problems with this protocol, all of
which hope to be solved sometime in the near future during its
rewrite. Currently, work is underway to find working solutions to
these problems.
__
9.1 Scalability [473 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
and users and that information regarding th __
9.2 Labels [909 B] The current IRC protocol has 3 types of labels: the nickname, the
channel name and the server name. Each of the three types has its
own domain and no duplicates are allowed inside that domain.
Currently, it is possible for users to pick __
9.2.2 Channels [405 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 ( __
9.2.3 Servers [207 B] Although the number of servers is usually small relative to the
number of users and channels, they two currently required to be known
globally, either each one separately or hidden behind a mask.
__
9.3 Algorithms [814 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 no database consistency checks,
each server __
10. Current support and availability [324 B] Mailing lists for IRC related discussion:
Future protocol: ircd-three-request@eff.org
General discussion: operlist-request@eff.org
Software implemenations
nic.funet.fi:/pub/irc
__
11. Security Considerations [81 B] Security issues are discussed in sections 4.1, 4.1.1, 4.1.3, 5.5, and
7.
__
|
Gogloom.com - Loading
- Please, wait
Search Examples: