rfc2813.txt

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

Network Working Group                                           C. Kalt
Request for Comments: 2813                                   April 2000
Updates: 1459
Category: Informational


                  Internet Relay Chat: Server Protocol

Status of this Memo

   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

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   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 originally a superset of the client protocol but has
   evolved differently.

   First formally documented in May 1993 as part of RFC 1459 [IRC], most
   of the changes brought since then can be found in this document as
   development was focused on making the protocol scale better.  Better
   scalability has allowed existing world-wide networks to keep growing
   and reach sizes which defy the old specification.


















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


Table of Contents

   1.  Introduction ...............................................   3
   2.  Global database ............................................   3
      2.1  Servers ................................................   3
      2.2  Clients ................................................   4
         2.2.1  Users .............................................   4
         2.2.2  Services ..........................................   4
      2.3  Channels ...............................................   4
   3.  The IRC Server Specification ...............................   5
      3.1  Overview ...............................................   5
      3.2  Character codes ........................................   5
      3.3  Messages ...............................................   5
         3.3.1  Message format in Augmented BNF ...................   6
      3.4  Numeric replies ........................................   7
   4.  Message Details ............................................   7
      4.1  Connection Registration ................................   8
         4.1.1  Password message ..................................   8
         4.1.2  Server message ....................................   9
         4.1.3  Nick ..............................................  10
         4.1.4  Service message ...................................  11
         4.1.5  Quit ..............................................  12
         4.1.6  Server quit message ...............................  13
      4.2  Channel operations .....................................  14
         4.2.1  Join message ......................................  14
         4.2.2  Njoin message .....................................  15
         4.2.3  Mode message ......................................  16
   5.  Implementation details  ....................................  16
      5.1  Connection 'Liveness' ..................................  16
      5.2  Accepting a client to server connection ................  16
         5.2.1  Users .............................................  16
         5.2.2  Services ..........................................  17
      5.3  Establishing a server-server connection. ...............  17
         5.3.1  Link options ......................................  17
            5.3.1.1  Compressed server to server links ............  18
            5.3.1.2  Anti abuse protections .......................  18
         5.3.2  State information exchange when connecting ........  18
      5.4  Terminating server-client connections ..................  19
      5.5  Terminating server-server connections ..................  19
      5.6  Tracking nickname changes ..............................  19
      5.7  Tracking recently used nicknames .......................  20
      5.8  Flood control of clients ...............................  20
      5.9  Non-blocking lookups ...................................  21
         5.9.1  Hostname (DNS) lookups ............................  21
         5.9.2  Username (Ident) lookups ..........................  21
   6.  Current problems ...........................................  21
      6.1  Scalability ............................................  21
      6.2  Labels .................................................  22



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


         6.2.1  Nicknames .........................................  22
         6.2.2  Channels ..........................................  22
         6.2.3  Servers ...........................................  22
      6.3  Algorithms .............................................  22
   7.  Security Considerations ....................................  23
      7.1  Authentication .........................................  23
      7.2  Integrity ..............................................  23
   8.  Current support and availability ...........................  24
   9.  Acknowledgements ...........................................  24
   10.  References ................................................  24
   11.  Author's Address ..........................................  25
   12. Full Copyright Statement ...................................  26

1. Introduction

   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 "Internet Relay Chat: Architecture"
   [IRC-ARCH]: client locator (via the client protocol [IRC-CLIENT]),
   message relaying (via the server protocol defined in this document)
   and channel hosting and management (following specific rules [IRC-
   CHAN]).

2. Global database

   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

   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 by all other servers, however it is
   possible to define a "hostmask" to group servers together according
   to their name.  Inside the hostmasked area, all the servers have a
   name which matches the hostmask, and any other server with a name
   matching the hostmask SHALL NOT be connected to the IRC network
   outside the hostmasked area.  Servers which are outside the area have
   no knowledge of the individual servers present inside the area,
   instead they are presented with a virtual server which has the
   hostmask for name.




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


2.2 Clients

   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

   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, all servers MUST have the
   following information about all users: the name of the host that the
   user is running on, the username of the user on that host, and the
   server to which the client is connected.

2.2.2 Services

   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 not be used in a nickname.  The
   server name used to compose the service name is the name of the
   server to which the service is connected.  In addition to this
   service name all servers MUST know the service type.

   Services differ from users by the format of their identifier, but
   more importantly services and users don't have the same type of
   access to the server: services can request part or all of the global
   state information that a server maintains, but have a more restricted
   set of commands available to them (See "IRC Client Protocol" [IRC-
   CLIENT] for details on which) and are not allowed to join channels.
   Finally services are not usually subject to the "Flood control"
   mechanism described in section 5.8.

2.3 Channels

   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.










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


3. The IRC Server Specification

3.1 Overview

   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 considered to be untrustworthy) than on server connections.

3.2 Character codes

   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 for control codes which act as
   message delimiters.

   Regardless of being an 8-bit protocol, the delimiters and keywords
   are such that protocol is mostly usable from US-ASCII terminal and a
   telnet connection.

   Because of IRC's Scandinavian origin, the characters {}|^ are
   considered to be the lower case equivalents of the characters []\~,
   respectively. This is a critical issue when determining the
   equivalence of two nicknames, or channel names.

3.3 Messages

   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 up to three main parts: the prefix
   (OPTIONAL), the command, and the command parameters (maximum of
   fifteen (15)).  The prefix, command, and all parameters are separated
   by one ASCII space character (0x20) each.

   The presence of a prefix is indicated with a single leading ASCII
   colon character (':', 0x3b), which MUST be the first character of the
   message itself.  There MUST be NO gap (whitespace) between the colon
   and the prefix.  The prefix is used by servers to indicate the true
   origin of the message.  If the prefix is missing from the message, it
   is assumed to have originated from the connection from which it was
   received.  Clients SHOULD not use a prefix when sending a message
   from themselves; if they use one, the only valid prefix is the
   registered nickname associated with the client.



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


   When a server receives a message, it MUST identify its source using
   the (eventually assumed) prefix.  If the prefix cannot be found in
   the server's internal database, it MUST be discarded, and if the
   prefix indicates the message comes from an (unknown) server, the link
   from which the message was received MUST be dropped.  Dropping a link
   in such circumstances is a little excessive but necessary to maintain
   the integrity of the network and to prevent future problems.  Another
   common error condition is that the prefix found in the server's
   internal database identifies a different source (typically a source
   registered from a different link than from which the message
   arrived).  If the message was received from a server link and the
   prefix identifies a client, a KILL message MUST be issued for the
   client and sent to all servers.  In other cases, the link from which
   the message arrived SHOULD be dropped for clients, and MUST be
   dropped for servers.  In all cases, the message MUST be discarded.

   The command MUST either be a valid IRC command or a three (3) digit
   number represented in ASCII text.

   IRC messages are always lines of characters terminated with a CR-LF
   (Carriage Return - Line Feed) pair, and these messages SHALL NOT
   exceed 512 characters in length, counting all characters including
   the trailing CR-LF. Thus, there are 510 characters maximum allowed
   for the command and its parameters.  There is no provision for
   continuation message lines.  See section 5 for more details about
   current implementations.

3.3.1 Message format in Augmented BNF

   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 CR-LF between messages without
   extra problems.

   The extracted message is parsed into the components <prefix>,
   <command> and list of parameters (<params>).

   The Augmented BNF representation for this is found in "IRC Client
   Protocol" [IRC-CLIENT].

   The extended prefix (["!" user "@" host ]) MUST NOT be used in server
   to server communications and is only intended for server to client
   messages in order to provide clients with more useful information
   about who a message is from without the need for additional queries.






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


3.4 Numeric replies

   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, the three digit numeric, and
   the target of the reply.  A numeric reply is not allowed to originate
   from a client; any such messages received by a server are silently
   dropped. In all other respects, a numeric reply is just like a normal
   message, except that the keyword is made up of 3 numeric digits
   rather than a string of letters.  A list of different replies is
   supplied in "IRC Client Protocol" [IRC-CLIENT].

4. Message Details

   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 NOT send
   any other replies after this error for that command.

   The server to which a client is connected is required to parse the