rfc2813.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,460 行 · 第 1/4 页


RFC 2813          Internet Relay Chat: Server Protocol        April 2000


   section 5.7 (Tracking recently used nicknames) for more information
   on this procedure.

   Numeric replies:

           ERR_NOPRIVILEGES                ERR_NOSUCHSERVER
           ERR_NEEDMOREPARAMS

   Example:

   SQUIT tolsun.oulu.fi :Bad Link ?  ; the server link tolson.oulu.fi
                                   has been terminated because of "Bad
                                   Link".

   :Trillian SQUIT cm22.eng.umd.edu :Server out of control ; message
                                   from Trillian to disconnect
                                   "cm22.eng.umd.edu" from the net
                                   because "Server out of control".

4.2 Channel operations

   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 network send commands which will
   ultimately clash.  It is also REQUIRED that servers keep a nickname
   history to ensure that wherever a <nick> parameter is given, the
   server check its history in case it has recently been changed.

4.2.1 Join message

      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 allowed to join a channel is
   checked only by the local server the client is connected to; all
   other servers automatically add the user to the channel when the
   command is received from other servers.

   Optionally, the user status (channel modes 'O', 'o', and 'v') on the
   channel may be appended to the channel name using a control G (^G or
   ASCII 7) as separator.  Such data MUST be ignored if the message
   wasn't received from a server.  This format MUST NOT be sent to
   clients, it can only be used between servers and SHOULD be avoided.





Kalt                         Informational                     [Page 14]

RFC 2813          Internet Relay Chat: Server Protocol        April 2000


   The JOIN command MUST be broadcast to all servers so that each server
   knows where to find the users who are on the channel.  This allows
   optimal delivery of PRIVMSG and NOTICE messages to the channel.

   Numeric Replies:

           ERR_NEEDMOREPARAMS              ERR_BANNEDFROMCHAN
           ERR_INVITEONLYCHAN              ERR_BADCHANNELKEY
           ERR_CHANNELISFULL               ERR_BADCHANMASK
           ERR_NOSUCHCHANNEL               ERR_TOOMANYCHANNELS
           ERR_TOOMANYTARGETS              ERR_UNAVAILRESOURCE
           RPL_TOPIC

   Examples:

   :WiZ JOIN #Twilight_zone        ; JOIN message from WiZ

4.2.2 Njoin message

      Command: NJOIN
   Parameters: <channel> [ "@@" / "@" ] [ "+" ] <nickname>
                         *( "," [ "@@" / "@" ] [ "+" ] <nickname> )

   The NJOIN message is used between servers only.  If such a message is
   received from a client, it MUST be ignored.  It is used when two
   servers connect to each other to exchange the list of channel members
   for each channel.

   Even though the same function can be performed by using a succession
   of JOIN, this message SHOULD be used instead as it is more efficient.
   The prefix "@@" indicates that the user is the "channel creator", the
   character "@" alone indicates a "channel operator", and the character
   '+' indicates that the user has the voice privilege.

   Numeric Replies:

           ERR_NEEDMOREPARAMS              ERR_NOSUCHCHANNEL
           ERR_ALREADYREGISTRED

   Examples:

   :ircd.stealth.net NJOIN #Twilight_zone :@WiZ,+syrk,avalon ; NJOIN
                                   message from ircd.stealth.net
                                   announcing users joining the
                                   #Twilight_zone channel: WiZ with
                                   channel operator status, syrk with
                                   voice privilege and avalon with no
                                   privilege.



Kalt                         Informational                     [Page 15]

RFC 2813          Internet Relay Chat: Server Protocol        April 2000


4.2.3 Mode message

   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 resulted passed on.

   It is REQUIRED that servers are able to change channel modes so that
   "channel creator" and "channel operators" may be created.

5. Implementation details

   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 numeric replies. Unfortunately,
   due to backward compatibility requirements, the implementation of
   some parts of this document varies with what is laid out.  One
   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.

5.1 Connection 'Liveness'

   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 a given amount of time.

   If a connection doesn't respond in time, its connection is closed
   using the appropriate procedures.

5.2 Accepting a client to server connection

5.2.1 Users

   When a server successfully registers a new user connection, it is
   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 modes (RPL_MYINFO), and it
   MAY send any introductory messages which may be deemed appropriate.



Kalt                         Informational                     [Page 16]

RFC 2813          Internet Relay Chat: Server Protocol        April 2000


   In particular the server SHALL send the current user/service/server
   count (as per the LUSER reply) and finally the MOTD (if any, as per
   the MOTD reply).

   After dealing with registration, the server MUST then send out to
   other servers the new user's nickname (NICK message), other
   information as supplied by itself (USER message) and as the server
   could discover (from DNS servers).  The server MUST NOT send this
   information out with a pair of NICK and USER messages as defined in
   "IRC Client Protocol" [IRC-CLIENT], but MUST instead take advantage
   of the extended NICK message defined in section 4.1.3.

5.2.2 Services

   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_MYINFO.

   After dealing with this, the server MUST then send out to other
   servers (SERVICE message) the new service's nickname and other
   information as supplied by the service (SERVICE message) and as the
   server could discover (from DNS servers).

5.3 Establishing a server-server connection.

   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 a PASS/SERVER
   pair which were recognized 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.

5.3.1 Link options

   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).






Kalt                         Informational                     [Page 17]

RFC 2813          Internet Relay Chat: Server Protocol        April 2000


5.3.1.1 Compressed server to server links

   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, then the remainder of the
   communication is to be compressed.  If any server fails to initialize
   the stream, it will send an uncompressed ERROR message to its peer
   and close the connection.

   The data format used for the compression is described by RFC 1950
   [ZLIB], RFC 1951 [DEFLATE] and RFC 1952 [GZIP].

5.3.1.2 Anti abuse protections

   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 all servers implement and enable such
   features on a particular network, the 'P' flag is used when two
   servers connect.  If this flag is present, it means that the server
   protections are enabled, and that the server REQUIRES all its server
   links to enable them as well.

   Commonly found protections are described in sections 5.7 (Tracking
   recently used nicknames) and 5.8 (Flood control of clients).

5.3.2 State information exchange when connecting

   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.

   Information regarding servers is sent via extra SERVER messages,
   client information with NICK and SERVICE messages and channels with
   NJOIN/MODE messages.

   NOTE: channel topics SHOULD NOT be exchanged here because the TOPIC
   command overwrites any old topic information, so at best, the two
   sides of the connection would exchange topics.






Kalt                         Informational                     [Page 18]

RFC 2813          Internet Relay Chat: Server Protocol        April 2000


   By passing the state information about servers first, any collisions
   with servers that already exist occur before nickname collisions
   caused by 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.  In this event, the place where the server collision occurs
   indicates where the net needs to split.

5.4 Terminating server-client connections

   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

   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 then sends a list of SQUITs (one for each
   server behind that connection).  (See Section 4.1.6 (SQUIT)).

5.6 Tracking nickname changes

   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.  Messages which MUST trace nick
   changes are:

           * KILL (the nick being disconnected)

           * MODE (+/- o,v on channels)

           * KICK (the nick being removed from channel)

      No other commands need to check nick changes.

   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 now 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.






Kalt                         Informational                     [Page 19]

RFC 2813          Internet Relay Chat: Server Protocol        April 2000


   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).

5.7 Tracking recently used nicknames

   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 track of nickname changes, servers SHOULD keep
   track of nicknames which were recently used and were released as the
   result of a "network split" or a KILL message.  These nicknames are
   then unavailable to the server local clients and cannot be re-used
   (even though they are not currently in use) for a certain period of
   time.

   The duration for which a nickname remains unavailable SHOULD be set
   considering many factors among which are the size (user wise) of the
   IRC network, and the usual duration of "network splits".  It SHOULD
   be uniform on all servers for a given IRC network.

5.8 Flood control of clients

   With a large network of interconnected IRC servers, it is quite easy