RFC 1459
Internet Relay Chat Protocol
6. REPLIES 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. 401 ERR_NOSUCHNICK "<nickname> :No such nick/channel" - Used to indicate the nickname parameter supplied to a command is currently unused. 402 ERR_NOSUCHSERVER "<server name> :No such server" - Used to indicate the server name given currently doesn't exist. 403 ERR_NOSUCHCHANNEL "<channel name> :No such channel" - Used to indicate the given channel name is invalid. 404 ERR_CANNOTSENDTOCHAN "<channel name> :Cannot send to channel" - Sent to a user who is either (a) not on a channel which is mode +n or (b) not a chanop (or mode +v) on a channel which has mode +m set and is trying to send a PRIVMSG message to that channel. 405 ERR_TOOMANYCHANNELS "<channel name> :You have joined too many \ channels" - Sent to a user when they have joined the maximum number of allowed channels and they try to join another channel. 406 ERR_WASNOSUCHNICK "<nickname> :There was no such nickname" - Returned by WHOWAS to indicate there is no history information for that nickname. 407 ERR_TOOMANYTARGETS "<target> :Duplicate recipients. No message \
delivered"
- Returned to a client which is attempting to send a
PRIVMSG/NOTICE using the user@host destination format
and for a user@host which has several occurrences.
409 ERR_NOORIGIN
":No origin specified"
- PING or PONG message missing the originator parameter
which is required since these commands must work
without valid prefixes.
411 ERR_NORECIPIENT
":No recipient given (<command>)"
412 ERR_NOTEXTTOSEND
":No text to send"
413 ERR_NOTOPLEVEL
"<mask> :No toplevel domain specified"
414 ERR_WILDTOPLEVEL
"<mask> :Wildcard in toplevel domain"
- 412 - 414 are returned by PRIVMSG to indicate that
the message wasn't delivered for some reason.
ERR_NOTOPLEVEL and ERR_WILDTOPLEVEL are errors that
are returned when an invalid use of
"PRIVMSG $<server>" or "PRIVMSG #<host>" is attempted.
421 ERR_UNKNOWNCOMMAND
"<command> :Unknown command"
- Returned to a registered client to indicate that the
command sent is unknown by the server.
422 ERR_NOMOTD
":MOTD File is missing"
- Server's MOTD file could not be opened by the server.
423 ERR_NOADMININFO
"<server> :No administrative info available"
- Returned by a server in response to an ADMIN message
when there is an error in finding the appropriate
information.
424 ERR_FILEERROR
":File error doing <file op> on <file>"
- Generic error message used to report a failed file
operation during the processing of a message.
431 ERR_NONICKNAMEGIVEN
":No nickname given"
- Returned when a nickname parameter expected for a
command and isn't found.
432 ERR_ERRONEUSNICKNAME
"<nick> :Erroneus nickname"
- Returned after receiving a NICK message which contains
characters which do not fall in the defined set. See
section x.x.x for details on valid nicknames.
433 ERR_NICKNAMEINUSE
"<nick> :Nickname is already in use"
- Returned when a NICK message is processed that results
in an attempt to change to a currently existing
nickname.
436 ERR_NICKCOLLISION
"<nick> :Nickname collision KILL"
- Returned by a server to a client when it detects a
nickname collision (registered of a NICK that
already exists by another server).
441 ERR_USERNOTINCHANNEL
"<nick> <channel> :They aren't on that channel"
- Returned by the server to indicate that the target
user of the command is not on the given channel.
442 ERR_NOTONCHANNEL
"<channel> :You're not on that channel"
- Returned by the server whenever a client tries to
perform a channel effecting command for which the
client isn't a member.
443 ERR_USERONCHANNEL
"<user> <channel> :is already on channel"
- Returned when a client tries to invite a user to a
channel they are already on.
444 ERR_NOLOGIN
"<user> :User not logged in"
- Returned by the summon after a SUMMON command for a
user was unable to be performed since they were not
logged in.
445 ERR_SUMMONDISABLED
":SUMMON has been disabled"
- Returned as a response to the SUMMON command. Must be
returned by any server which does not implement it.
446 ERR_USERSDISABLED
":USERS has been disabled"
- Returned as a response to the USERS command. Must be
returned by any server which does not implement it.
451 ERR_NOTREGISTERED
":You have not registered"
- Returned by the server to indicate that the client
must be registered before the server will allow it
to be parsed in detail.
461 ERR_NEEDMOREPARAMS
"<command> :Not enough parameters"
- Returned by the server by numerous commands to
indicate to the client that it didn't supply enough
parameters.
462 ERR_ALREADYREGISTRED
":You may not reregister"
- Returned by the server to any link which tries to
change part of the registered details (such as
password or user details from second USER message).
463 ERR_NOPERMFORHOST
":Your host isn't among the privileged"
- Returned to a client which attempts to register with
a server which does not been setup to allow
connections from the host the attempted connection
is tried.
464 ERR_PASSWDMISMATCH
":Password incorrect"
- Returned to indicate a failed attempt at registering
a connection for which a password was required and
was either not given or incorrect.
465 ERR_YOUREBANNEDCREEP
":You are banned from this server"
- Returned after an attempt to connect and register
yourself with a server which has been setup to
explicitly deny connections to you.
467 ERR_KEYSET
"<channel> :Channel key already set"
471 ERR_CHANNELISFULL
"<channel> :Cannot join channel (+l)"
472 ERR_UNKNOWNMODE
"<char> :is unknown mode char to me"
473 ERR_INVITEONLYCHAN
"<channel> :Cannot join channel (+i)"
474 ERR_BANNEDFROMCHAN
"<channel> :Cannot join channel (+b)"
475 ERR_BADCHANNELKEY
"<channel> :Cannot join channel (+k)"
481 ERR_NOPRIVILEGES
":Permission Denied- You're not an IRC operator"
- Any command requiring operator privileges to operate
must return this error to indicate the attempt was
unsuccessful.
482 ERR_CHANOPRIVSNEEDED
"<channel> :You're not channel operator"
- Any command requiring 'chanop' privileges (such as
MODE messages) must return this error if the client
making the attempt is not a chanop on the specified
channel.
483 ERR_CANTKILLSERVER
":You cant kill a server!"
- Any attempts to use the KILL command on a server
are to be refused and this error returned directly
to the client.
491 ERR_NOOPERHOST
":No O-lines for your host"
- If a client sends an OPER message and the server has
not been configured to allow connections from the
client's host as an operator, this error must be
returned.
501 ERR_UMODEUNKNOWNFLAG
":Unknown MODE flag"
- Returned by the server to indicate that a MODE
message was sent with a nickname parameter and that
the a mode flag sent was not recognized.
502 ERR_USERSDONTMATCH
":Cant change mode for other users"
- Error sent to any user trying to view or change the
user mode for a user other than themselves.
6.2 Command responses.
300 RPL_NONE
Dummy reply number. Not used.
302 RPL_USERHOST
":[<reply>{<space><reply>}]"
- Reply format used by USERHOST to list replies to
the query list. The reply string is composed as
follows:
<reply> ::= <nick>['*'] '=' <'+'|'-'><hostname>
The '*' indicates whether the client has registered
as an Operator. The '-' or '+' characters represent
whether the client has set an AWAY message or not
respectively.
303 RPL_ISON
":[<nick> {<space><nick>}]"
- Reply format used by ISON to list replies to the
query list.
301 RPL_AWAY
"<nick> :<away message>"
305 RPL_UNAWAY
":You are no longer marked as being away"
306 RPL_NOWAWAY
":You have been marked as being away"
- These replies are used with the AWAY command (if
allowed). RPL_AWAY is sent to any client sending a
PRIVMSG to a client which is away. RPL_AWAY is only
sent by the server to which the client is connected.
Replies RPL_UNAWAY and RPL_NOWAWAY are sent when the
client removes and sets an AWAY message.
311 RPL_WHOISUSER
"<nick> <user> <host> * :<real name>"
312 RPL_WHOISSERVER
"<nick> <server> :<server info>"
313 RPL_WHOISOPERATOR
"<nick> :is an IRC operator"
317 RPL_WHOISIDLE
"<nick> <integer> :seconds idle"
318 RPL_ENDOFWHOIS
"<nick> :End of /WHOIS list"
319 RPL_WHOISCHANNELS
"<nick> :{[@|+]<channel><space>}"
- Replies 311 - 313, 317 - 319 are all replies
generated in response to a WHOIS message. Given that
there are enough parameters present, the answering
server must either formulate a reply out of the above
numerics (if the query nick is found) or return an
error reply. The '*' in RPL_WHOISUSER is there as
the literal character and not as a wild card. For
each reply set, only RPL_WHOISCHANNELS may appear
more than once (for long lists of channel names).
The '@' and '+' characters next to the channel name
indicate whether a client is a channel operator or
has been granted permission to speak on a moderated
channel. The RPL_ENDOFWHOIS reply is used to mark
the end of processing a WHOIS message.
314 RPL_WHOWASUSER
"<nick> <user> <host> * :<real name>"
369 RPL_ENDOFWHOWAS
"<nick> :End of WHOWAS"
- When replying to a WHOWAS message, a server must use
the replies RPL_WHOWASUSER, RPL_WHOISSERVER or
ERR_WASNOSUCHNICK for each nickname in the presented
list. At the end of all reply batches, there must
be RPL_ENDOFWHOWAS (even if there was only one reply
and it was an error).
321 RPL_LISTSTART
"Channel :Users Name"
322 RPL_LIST
"<channel> <# visible> :<topic>"
323 RPL_LISTEND
":End of /LIST"
- Replies RPL_LISTSTART, RPL_LIST, RPL_LISTEND mark
the start, actual replies with data and end of the
server's response to a LIST command. If there are
no channels available to return, only the start
and end reply must be sent.
324 RPL_CHANNELMODEIS
"<channel> <mode> <mode params>"
331 RPL_NOTOPIC
"<channel> :No topic is set"
332 RPL_TOPIC
"<channel> :<topic>"
- When sending a TOPIC message to determine the
channel topic, one of two replies is sent. If
the topic is set, RPL_TOPIC is sent back else
RPL_NOTOPIC.
341 RPL_INVITING
"<channel> <nick>"
- Returned by the server to indicate that the
attempted INVITE message was successful and is
being passed onto the end client.
342 RPL_SUMMONING
"<user> :Summoning user to IRC"
- Returned by a server answering a SUMMON message to
indicate that it is summoning that user.
351 RPL_VERSION
"<version>.<debuglevel> <server> :<comments>"
- Reply by the server showing its version details.
The <version> is the version of the software being
used (including any patchlevel revisions) and the
<debuglevel> is used to indicate if the server is
running in "debug mode".
The "comments" field may contain any comments about
the version or further version details.
352 RPL_WHOREPLY
"<channel> <user> <host> <server> <nick> \
<H|G>[*][@|+] :<hopcount> <real name>"
315 RPL_ENDOFWHO
"<name> :End of /WHO list"
- The RPL_WHOREPLY and RPL_ENDOFWHO pair are used
to answer a WHO message. The RPL_WHOREPLY is only
sent if there is an appropriate match to the WHO
query. If there is a list of parameters supplied
with a WHO message, a RPL_ENDOFWHO must be sent
after processing each list item with <name> being
the item.
353 RPL_NAMREPLY
"<channel> :[[@|+]<nick> [[@|+]<nick> [...]]]"
366 RPL_ENDOFNAMES
"<channel> :End of /NAMES list"
- To reply to a NAMES message, a reply pair consisting
of RPL_NAMREPLY and RPL_ENDOFNAMES is sent by the
server back to the client. If there is no channel
found as in the query, then only RPL_ENDOFNAMES is
returned. The exception to this is when a NAMES
message is sent with no parameters and all visible
channels and contents are sent back in a series of
RPL_NAMEREPLY messages with a RPL_ENDOFNAMES to mark
the end.
364 RPL_LINKS
"<mask> <server> :<hopcount> <server info>"
365 RPL_ENDOFLINKS
"<mask> :End of /LINKS list"
- In replying to the LINKS message, a server must send
replies back using the RPL_LINKS numeric and mark the
end of the list using an RPL_ENDOFLINKS reply.
367 RPL_BANLIST
"<channel> <banid>"
368 RPL_ENDOFBANLIST
"<channel> :End of channel ban list"
- When listing the active 'bans' for a given channel,
a server is required to send the list back using the
RPL_BANLIST and RPL_ENDOFBANLIST messages. A separate
RPL_BANLIST is sent for each active banid. After the
banids have been listed (or if none present) a
RPL_ENDOFBANLIST must be sent.
371 RPL_INFO
":<string>"
374 RPL_ENDOFINFO
":End of /INFO list"
- A server responding to an INFO message is required to
send all its 'info' in a series of RPL_INFO messages
with a RPL_ENDOFINFO reply to indicate the end of the
replies.
375 RPL_MOTDSTART
":- <server> Message of the day - "
372 RPL_MOTD
":- <text>"
376 RPL_ENDOFMOTD
":End of /MOTD command"
- When responding to the MOTD message and the MOTD file
is found, the file is displayed line by line, with
each line no longer than 80 characters, using
RPL_MOTD format replies. These should be surrounded
by a RPL_MOTDSTART (before the RPL_MOTDs) and an
RPL_ENDOFMOTD (after).
381 RPL_YOUREOPER
":You are now an IRC operator"
- RPL_YOUREOPER is sent back to a client which has
just successfully issued an OPER message and gained
operator status.
382 RPL_REHASHING
"<config file> :Rehashing"
- If the REHASH option is used and an operator sends
a REHASH message, an RPL_REHASHING is sent back to
the operator.
391 RPL_TIME
"<server> :<string showing server's local time>"
- When replying to the TIME message, a server must send
the reply using the RPL_TIME format above. The string
showing the time need only contain the correct day and
time there. There is no further requirement for the
time string.
392 RPL_USERSSTART
":UserID Terminal Host"
393 RPL_USERS
":%-8s %-9s %-8s"
394 RPL_ENDOFUSERS
":End of users"
395 RPL_NOUSERS
":Nobody logged in"
- If the USERS message is handled by a server, the
replies RPL_USERSTART, RPL_USERS, RPL_ENDOFUSERS and
RPL_NOUSERS are used. RPL_USERSSTART must be sent
first, following by either a sequence of RPL_USERS
or a single RPL_NOUSER. Following this is
RPL_ENDOFUSERS.
200 RPL_TRACELINK
"Link <version & debug level> <destination> \
<next server>"
201 RPL_TRACECONNECTING
"Try. <class> <server>"
202 RPL_TRACEHANDSHAKE
"H.S. <class> <server>"
203 RPL_TRACEUNKNOWN
"???? <class> [<client IP address in dot form>]"
204 RPL_TRACEOPERATOR
"Oper <class> <nick>"
205 RPL_TRACEUSER
"User <class> <nick>"
206 RPL_TRACESERVER
"Serv <class> <int>S <int>C <server> \
<nick!user|*!*>@<host|server>"
208 RPL_TRACENEWTYPE
"<newtype> 0 <client name>"
261 RPL_TRACELOG
"File <logfile> <debug level>"
- The RPL_TRACE* are all returned by the server in
response to the TRACE message. How many are
returned is dependent on the the TRACE message and
whether it was sent by an operator or not. There
is no predefined order for which occurs first.
Replies RPL_TRACEUNKNOWN, RPL_TRACECONNECTING and
RPL_TRACEHANDSHAKE are all used for connections
which have not been fully established and are either
unknown, still attempting to connect or in the
process of completing the 'server handshake'.
RPL_TRACELINK is sent by any server which handles
a TRACE message and has to pass it on to another
server. The list of RPL_TRACELINKs sent in
response to a TRACE command traversing the IRC
network should reflect the actual connectivity of
the servers themselves along that path.
RPL_TRACENEWTYPE is to be used for any connection
which does not fit in the other categories but is
being displayed anyway.
211 RPL_STATSLINKINFO
"<linkname> <sendq> <sent messages> \
<sent bytes> <received messages> \
<received bytes> <time open>"
212 RPL_STATSCOMMANDS
"<command> <count>"
213 RPL_STATSCLINE
"C <host> * <name> <port> <class>"
214 RPL_STATSNLINE
"N <host> * <name> <port> <class>"
215 RPL_STATSILINE
"I <host> * <host> <port> <class>"
216 RPL_STATSKLINE
"K <host> * <username> <port> <class>"
218 RPL_STATSYLINE
"Y <class> <ping frequency> <connect \
frequency> <max sendq>"
219 RPL_ENDOFSTATS
"<stats letter> :End of /STATS report"
241 RPL_STATSLLINE
"L <hostmask> * <servername> <maxdepth>"
242 RPL_STATSUPTIME
":Server Up %d days %d:%02d:%02d"
243 RPL_STATSOLINE
"O <hostmask> * <name>"
244 RPL_STATSHLINE
"H <hostmask> * <servername>"
221 RPL_UMODEIS
"<user mode string>"
- To answer a query about a client's own mode,
RPL_UMODEIS is sent back.
251 RPL_LUSERCLIENT
":There are <integer> users and <integer> \
invisible on <integer> servers"
252 RPL_LUSEROP
"<integer> :operator(s) online"
253 RPL_LUSERUNKNOWN
"<integer> :unknown connection(s)"
254 RPL_LUSERCHANNELS
"<integer> :channels formed"
255 RPL_LUSERME
":I have <integer> clients and <integer> \
servers"
- In processing an LUSERS message, the server
sends a set of replies from RPL_LUSERCLIENT,
RPL_LUSEROP, RPL_USERUNKNOWN,
RPL_LUSERCHANNELS and RPL_LUSERME. When
replying, a server must send back
RPL_LUSERCLIENT and RPL_LUSERME. The other
replies are only sent back if a non-zero count
is found for them.
256 RPL_ADMINME
"<server> :Administrative info"
257 RPL_ADMINLOC1
":<admin info>"
258 RPL_ADMINLOC2
":<admin info>"
259 RPL_ADMINEMAIL
":<admin info>"
- When replying to an ADMIN message, a server
is expected to use replies RLP_ADMINME
through to RPL_ADMINEMAIL and provide a text
message with each. For RPL_ADMINLOC1 a
description of what city, state and country
the server is in is expected, followed by
details of the university and department
(RPL_ADMINLOC2) and finally the administrative
contact for the server (an email address here
is required) in RPL_ADMINEMAIL.
6.3 Reserved numerics. 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 the current IRC server. 209 RPL_TRACECLASS 217 RPL_STATSQLINE 231 RPL_SERVICEINFO 232 RPL_ENDOFSERVICES 233 RPL_SERVICE 234 RPL_SERVLIST 235 RPL_SERVLISTEND 316 RPL_WHOISCHANOP 361 RPL_KILLDONE 362 RPL_CLOSING 363 RPL_CLOSEEND 373 RPL_INFOSTART 384 RPL_MYPORTIS 466 ERR_YOUWILLBEBANNED 476 ERR_BADCHANMASK 492 ERR_NOSERVICEHOST 7. Client and server authentication 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 password check (if there is a password set for that connection). These checks are possible on all connections although the password check is only commonly used with servers. An additional check that is becoming of more and more common is that of the username responsible for making the connection. Finding the username of the other end of the connection typically involves connecting to an authentication server such as IDENT as described in RFC 1413. Given that without passwords it is not easy to reliably determine who is on the other end of a network connection, use of passwords is strongly recommended on inter-server connections in addition to any other measures such as using an ident server. 8. Current implementations 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. Unfortunately, due to backward
compatibility requirements, the implementation of some parts of this
document varies with what is laid out. On notable difference is:
* recognition that any LF or CR anywhere in a message marks the
end of that message (instead of requiring CR-LF);
The rest of this section deals with issues that are mostly of
importance to those who wish to implement a server but some parts
also apply directly to clients as well.
8.1 Network protocol: TCP - why it is best used here.
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 present time.
8.1.1 Support of Unix sockets
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 hostname starts with a '/'.
When providing any information about the connections on a Unix domain
socket, the server is required to supplant the actual hostname in
place of the pathname unless the actual socket name is being asked
for.
8.2 Command Parsing
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 hold 1 full message, although, this
will usually hold several commands. The private buffer is parsed
after every read operation for valid messages. When dealing with
multiple messages from one client in the buffer, care should be taken
in case one happens to cause the client to be 'removed'.
8.3 Message delivery
It is common to find network links saturated or hosts to which you
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 buffers provided in the
kernel are not enough for the outgoing queue. To alleviate this problem, a "send queue" is used as a FIFO queue for data to be sent. A typical "send queue" may grow to 200 Kbytes on a large IRC network with a slow network connection when a new server connects. When polling its connections, a server will first read and parse all incoming data, queuing any data to be sent out. When all available input is processed, the queued data is sent. This reduces the number of write() system calls and helps TCP make bigger packets. 8.4 Connection 'Liveness' 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 using the appropriate procedures. A connection is also dropped if its sendq grows beyond the maximum allowed, because it is better to close a slow connection than have a server process block. 8.5 Establishing a server to client connection 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 and version as well as any other introductory messages which may be deemed appropriate. After dealing with this, the server must then send out the new user's nickname and other information as supplied by itself (USER command) and as the server could discover (from DNS/authentication servers). The server must send this information out with NICK first followed by USER. 8.6 Establishing a server-server connection. 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 by a PASS/SERVER pair which were recognised as being valid, the server should then reply with its own PASS/SERVER information for that connection as well as all of the other state information it knows about as described below. When the initiating server receives a PASS/SERVER pair, it too then
checks that the server responding is authenticated properly before accepting the connection to be that server. 8.6.1 Server exchange of state information when connecting 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 regarding servers is sent via extra SERVER messages, user information with NICK/USER/MODE/JOIN messages and channels with MODE messages. NOTE: channel topics are *NOT* exchanged here because the TOPIC command overwrites any old topic information, so at best, the two sides of the connection would exchange topics. By passing the state information about servers first, any collisions with servers that already exist occur before nickname collisions due to a second server introducing a particular nickname. Due to the IRC network only being able to exist as an acyclic graph, it may be possible that the network has already reconnected in another location, the place where the collision occurs indicating where the net needs to split. 8.7 Terminating server-client connections 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 If a server-server connection is closed, either via a remotely generated SQUIT or 'natural' causes, the rest of the connected IRC network must have its information updated with by the server which detected the closure. The server then sends a list of SQUITs (one for each server behind that connection) and a list of QUITs (again, one for each client behind that connection).
8.9 Tracking nickname changes 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. Commands which must trace nick changes are: * KILL (the nick being killed) * MODE (+/- o,v) * KICK (the nick being kicked) No other commands are to have nick changes checked for. In the above cases, the server is required to first check for the existence of the nickname, then check its history to see who that nick currently belongs to (if anyone!). This reduces the chances of race conditions but they can still occur with the server ending up affecting the wrong client. When performing a change trace for an above command it is recommended that a time range be given and entries which are too old ignored. For a reasonable history, a server should be able to keep previous nickname for every client it knows about if they all decided to change. This size is limited by other factors (such as memory, etc). 8.10 Flood control of clients 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 service provided to others. Rather than require every 'victim' to be provide their own protection, flood protection was written into the server and is applied to all clients except services. The current algorithm is as follows: * check to see if client's `message timer' is less than current time (set to be equal if it is); * read any data present from the client; * while the timer is less than ten seconds ahead of the current time, parse any present messages and penalize the client by 2 seconds for each message; which in essence means that the client may send 1 message every 2
seconds without being adversely affected. 8.11 Non-blocking lookups 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 server connections, this was not difficult, but there are other support operations that may cause the server to block (such as disk reads). Where possible, such activity should be performed with a short timeout. 8.11.1 Hostname (DNS) lookups 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 and then polled from within the main server IO loop. 8.11.2 Username (Ident) lookups 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 which would cooperate with the rest of the server and work using non-blocking IO. 8.12 Configuration File 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; * which hosts to allow to connect as servers; * which hosts to connect to (both actively and passively); * information about where the server is (university, city/state, company are examples of this); * who is responsible for the server and an email address at which they can be contacted; * hostnames and passwords for clients which wish to be given
access to restricted operator commands.
In specifying hostnames, both domain names and use of the 'dot'
notation (127.0.0.1) should both be accepted. It must be possible to
specify the password to be used/accepted for all outgoing and
incoming connections (although the only outgoing connections are
those to other servers).
The above list is the minimum requirement for any server which wishes
to make a connection with another server. Other items which may be
of use are:
* specifying which servers other server may introduce;
* how deep a server branch is allowed to become;
* hours during which clients may connect.
8.12.1 Allowing clients to connect
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 to provide the required
flexibility for host access control.
8.12.2 Operators
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 current setup requires two 'passwords'
to be used although one of them is usually easy guessed. Storage of
oper passwords in configuration files is preferable to hard coding
them in and should be stored in a crypted format (ie using crypt(3)
from Unix) to prevent easy theft.
8.12.3 Allowing servers to connect
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 no circumstances should a
server allow an arbitrary host to connect as a server. In addition
to which servers may and may not connect, the configuration file
should also store the password and other characteristics of that
link.
8.12.4 Administrivia 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 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 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 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 them be updated as soon as it changes. It is also desirable to keep the number of servers low so that the path length between any two points is kept minimal and the spanning tree as strongly branched as possible. 9.2 Labels 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 the label for any of the three, resulting in collisions. It is widely recognized that this needs reworking, with a plan for unique names for channels and nicks that don't collide being desirable as well as a solution allowing a cyclic tree. 9.2.1 Nicknames 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, its not uncommon for several people to want to use the same nick. If a nickname is chosen by two people using this protocol, either one will not succeed or
both will removed by use of KILL (4.6.1). 9.2.2 Channels 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 (both people who create the new channel are considered to be members of it) rather than an exclusive one such as used to solve nickname collisions. 9.2.3 Servers 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 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 assumes that a neighbouring server is correct. This opens the door to large problems if a connecting server is buggy or otherwise tries to introduce contradictions to the existing net. Currently, because of the lack of unique internal and global labels, there are a multitude of race conditions that exist. These race conditions generally arise from the problem of it taking time for messages to traverse and effect the IRC network. Even by changing to unique labels, there are problems with channel-related commands being disrupted. 10. Current support and availability Mailing lists for IRC related discussion: Future protocol: ircd-three-request@eff.org General discussion: operlist-request@eff.org Software implemenations cs.bu.edu:/irc nic.funet.fi:/pub/irc coombs.anu.edu.au:/pub/irc Newsgroup: alt.irc
Security Considerations Security issues are discussed in sections 4.1, 4.1.1, 4.1.3, 5.5, and 7. 12. Authors' Addresses Jarkko Oikarinen Tuirantie 17 as 9 90500 OULU FINLAND Email: jto@tolsun.oulu.fi Darren Reed 4 Pateman Street Watsonia, Victoria 3087 Australia Email: avalon@coombs.anu.edu.au