rfc2813.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 1,460 行 · 第 1/4 页

   complete message, returning any appropriate errors.  If the server
   encounters a fatal error while parsing a message, an error MUST be
   sent back to the client and the parsing terminated.  A fatal error
   may follow from incorrect command, a destination which is otherwise
   unknown to the server (server, client or channel names fit this
   category), not enough parameters or incorrect privileges.

   If a full set of parameters is presented, then each MUST be checked
   for validity and appropriate responses sent back to the client.  In
   the case of messages which use parameter lists using the comma as an
   item separator, a reply MUST be sent for each item.

   In the examples below, some messages appear using the full format:

   :Name COMMAND parameter list

   Such examples represent a message from "Name" in transit between
   servers, where it is essential to include the name of the original
   sender of the message so remote servers may send back a reply along
   the correct path.

   The message details for client to server communication are described
   in the "IRC Client Protocol" [IRC-CLIENT].  Some sections in the
   following pages apply to some of these messages, they are additions
   to the message specifications which are only relevant to server to



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


   server communication, or to the server implementation.  The messages
   which are introduced here are only used for server to server
   communication.

4.1 Connection Registration

   The commands described here are used to register a connection with
   another IRC server.

4.1.1 Password message

      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.  Currently this means that servers MUST send a PASS command
   before any SERVER command.  Only one (1) PASS command SHALL be
   accepted from a connection.

   The last three (3) parameters MUST be ignored if received from a
   client (e.g. a user or a service).  They are only relevant when
   received from a server.

   The <version> parameter is a string of at least four (4) characters,
   and up to fourteen (14) characters.  The first four (4) characters
   MUST be digits and indicate the protocol version known by the server
   issuing the message.  The protocol described by this document is
   version 2.10 which is encoded as "0210".  The remaining OPTIONAL
   characters are implementation dependent and should describe the
   software version number.

   The <flags> parameter is a string of up to one hundred (100)
   characters.  It is composed of two substrings separated by the
   character "|" (%x7C).  If present, the first substring MUST be the
   name of the implementation.  The reference implementation (See
   Section 8, "Current support and availability") uses the string "IRC".
   If a different implementation is written, which needs an identifier,
   then that identifier should be registered through publication of an
   RFC. The second substring is implementation dependent.  Both
   substrings are OPTIONAL, but the character "|" is REQUIRED.  The
   character "|" MUST NOT appear in either substring.

   Finally, the last parameter, <options>, is used for link options.
   The only options defined by the protocol are link compression (using
   the character "Z"), and an abuse protection flag (using the character





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


   "P").  See sections 5.3.1.1 (Compressed server to server links) and
   5.3.1.2 (Anti abuse protections) respectively for more information on
   these options.

   Numeric Replies:

           ERR_NEEDMOREPARAMS              ERR_ALREADYREGISTRED

   Example:

        PASS moresecretpassword 0210010000 IRC|aBgH$ Z

4.1.2 Server message

      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
   to pass server data over whole net.  When a new server is connected
   to net, information about it MUST be broadcasted to the whole
   network.

   The <info> parameter may contain space characters.

   <hopcount> is used to give all servers some internal information on
   how far away each server is.  Local peers have a value of 0, and each
   passed server increments the value.  With a full server list, it
   would be possible to construct a map of the entire server tree, but
   hostmasks prevent this from being done.

   The <token> parameter is an unsigned number used by servers as an
   identifier.  This identifier is subsequently used to reference a
   server in the NICK and SERVICE messages sent between servers.  Server
   tokens only have a meaning for the point-to-point peering they are
   used and MUST be unique for that connection.  They are not global.

   The SERVER message MUST only be accepted from either (a) a connection
   which is yet to be registered and is attempting to register as a
   server, or (b) an existing connection to another server, in which
   case the SERVER message is introducing a new server behind that
   server.

   Most errors that occur with the receipt of a SERVER command result in
   the connection being terminated by the destination host (target
   SERVER).  Because of the severity of such event, error replies are
   usually sent using the "ERROR" command rather than a numeric.




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


   If a SERVER message is parsed and it attempts to introduce a server
   which is already known to the receiving server, the connection, from
   which that message arrived, MUST be closed (following the correct
   procedures), since a duplicate route to a server has been formed and
   the acyclic nature of the IRC tree breaks.  In some conditions, the
   connection from which the already known server has registered MAY be
   closed instead.  It should be noted that this kind of error can also
   be the result of a second running server, problem which cannot be
   fixed within the protocol and typically requires human intervention.
   This type of problem is particularly insidious, as it can quite
   easily result in part of the IRC network to be isolated, with one of
   the two servers connected to each partition therefore making it
   impossible for the two parts to unite.

   Numeric Replies:

           ERR_ALREADYREGISTRED

   Example:

   SERVER test.oulu.fi 1 1 :Experimental server ; New server
                                   test.oulu.fi introducing itself and
                                   attempting to register.

   :tolsun.oulu.fi SERVER csd.bu.edu 5 34 :BU Central Server ; Server
                                   tolsun.oulu.fi is our uplink for
                                   csd.bu.edu which is 5 hops away.  The
                                   token "34" will be used by
                                   tolsun.oulu.fi when introducing new
                                   users or services connected to
                                   csd.bu.edu.

4.1.3 Nick

      Command: NICK
   Parameters: <nickname> <hopcount> <username> <host> <servertoken>
               <umode> <realname>

   This form of the NICK message MUST NOT be allowed from user
   connections. However, it MUST be used instead of the NICK/USER pair
   to notify other servers of new users joining the IRC network.

   This message is really the combination of three distinct messages:
   NICK, USER and MODE [IRC-CLIENT].

   The <hopcount> parameter is used by servers to indicate how far away
   a user is from its home server.  A local connection has a hopcount of
   0.  The hopcount value is incremented by each passed server.



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


   The <servertoken> parameter replaces the <servername> parameter of
   the USER (See section 4.1.2 for more information on server tokens).

   Examples:

   NICK syrk 5 kalt millennium.stealth.net 34 +i :Christophe Kalt ; New
                                   user with nickname "syrk", username
                                   "kalt", connected from host
                                   "millennium.stealth.net" to server
                                   "34" ("csd.bu.edu" according to the
                                   previous example).

   :krys NICK syrk                 ; The other form of the NICK message,
                                   as defined in "IRC Client Protocol"
                                   [IRC-CLIENT] and used between
                                   servers: krys changed his nickname to
                                   syrk

4.1.4 Service message

      Command: SERVICE
   Parameters: <servicename> <servertoken> <distribution> <type>
                <hopcount> <info>

   The SERVICE command is used to introduce a new service.  This form of
   the SERVICE message SHOULD NOT be allowed from client (unregistered,
   or registered) connections.  However, it MUST be used between servers
   to notify other servers of new services joining the IRC network.

   The <servertoken> is used to identify the server to which the service
   is connected.  (See section 4.1.2 for more information on server
   tokens).

   The <hopcount> parameter is used by servers to indicate how far away
   a service is from its home server.  A local connection has a hopcount
   of 0.  The hopcount value is incremented by each passed server.

   The <distribution> parameter is used to specify the visibility of a
   service.  The service may only be known to servers which have a name
   matching the distribution.  For a matching server to have knowledge
   of the service, the network path between that server and the server
   to which the service is connected MUST be composed of servers whose
   names all match the mask.  Plain "*" is used when no restriction is
   wished.

   The <type> parameter is currently reserved for future usage.





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


   Numeric Replies:

           ERR_ALREADYREGISTRED            ERR_NEEDMOREPARAMS
           ERR_ERRONEUSNICKNAME
           RPL_YOURESERVICE                RPL_YOURHOST
           RPL_MYINFO

   Example:

SERVICE [e-mail] 9 *.fr 0 1 :French Dictionary r" registered on
                                   server "9" is being announced to
                                   another server.  This service will
                                   only be available on servers whose
                                   name matches "*.fr".

4.1.5 Quit

      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 instead of the default message,
   the nickname or service name.

   When "netsplit" (See Section 4.1.6) occur, the "Quit Message" is
   composed of the names of two servers involved, separated by a space.
   The first name is that of the server which is still connected and the
   second name is either that of the server which has become
   disconnected or that of the server to which the leaving client was
   connected:

      <Quit Message> =  ":" servername SPACE servername

   Because the "Quit Message" has a special meaning for "netsplits",
   servers SHOULD NOT allow a client to use a <Quit Message> in the
   format described above.

   If, for some other reason, a client connection is closed without the
   client issuing a QUIT command (e.g. client dies and EOF occurs on
   socket), the server is REQUIRED to fill in the quit message with some
   sort of message reflecting the nature of the event which caused it to
   happen.  Typically, this is done by reporting a system specific
   error.

   Numeric Replies:

           None.



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


   Examples:

   :WiZ QUIT :Gone to have lunch   ; Preferred message format.

4.1.6 Server quit message

      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 remote server
   link.  This form of the message is also eventually used by servers to
   break a remote server link.

   The second use of this message is needed to inform other servers when
   a "network split" (also known as "netsplit") occurs, in other words
   to inform other servers 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 server, using the name of the other server as
   the server parameter, which then closes its connection to the
   quitting server.

   The <comment> is filled in by servers which SHOULD place an error or
   similar message here.

   Both of the servers which are on either side of the connection being
   closed are REQUIRED to send out a SQUIT message (to all its other
   server connections) for all other servers which are considered to be
   behind that link.

   Similarly, a QUIT message MAY be sent to the other still connected
   servers on behalf of all clients behind that quitting link.  In
   addition to this, all channel members of a channel which lost a
   member due to the "split" MUST be sent a QUIT message.  Messages to
   channel members are generated by each client's local server.

   If a server connection is terminated prematurely (e.g., the server on
   the other end of the link died), the server which detects this
   disconnection is REQUIRED to inform the rest of the network that the
   connection has closed and fill in the comment field with something
   appropriate.

   When a client is removed as the result of a SQUIT message, the server
   SHOULD add the nickname to the list of temporarily unavailable
   nicknames in an attempt to prevent future nickname collisions. See




Kalt                         Informational                     [Page 13]