rfc2813.txt

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

   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 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 (10) seconds ahead of the current
     time, parse any present messages and penalize the client by two (2)
     seconds for each message;

   * additional penalties MAY be used for specific commands which
     generate a lot of traffic across the network.

   This in essence means that the client may send one (1) message every
   two (2) seconds without being adversely affected.  Services MAY also
   be subject to this mechanism.




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


5.9 Non-blocking lookups

   In a real-time environment, it is essential that a server process
   does 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.

5.9.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 for the
   current implementation.  Routines were setup for non-blocking IO
   operations with local cache, and then polled from within the main
   server IO loop.

5.9.2 Username (Ident) lookups

   Although there are numerous ident libraries (implementing the
   "Identification Protocol" [IDENT]) 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.

6. Current problems

   There are a number of recognized problems with this protocol, all of
   which are hoped to be solved sometime in the near future during its
   rewrite.  Currently, work is underway to find working solutions to
   these problems.

6.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 clients 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.







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


6.2 Labels

   The current IRC protocol has 4 types of labels: the nickname, the
   channel name, the server name and the service name.  Each of the four
   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 first three, resulting in collisions.  It is widely
   recognized that this needs reworking, with a plan for unique names
   for nicks that don't collide being desirable as well as a solution
   allowing a cyclic tree.

6.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, it's 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 be removed by use of KILL (See Section 3.7.1 of "IRC Client
   Protocol" [IRC-CLIENT]).

6.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 (people from both nets on
   channel with common name are considered to be members of it) rather
   than an exclusive one such as used to solve nickname collisions.

   This protocol defines "Safe Channels" which are very unlikely to be
   the subject of a channel collision.  Other channel types are kept for
   backward compatibility.

6.2.3 Servers

   Although the number of servers is usually small relative to the
   number of users and channels, they too are currently REQUIRED to be
   known globally, either each one separately or hidden behind a mask.

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






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


   In current server versions, there are only few database consistency
   checks, most of the time 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.

7. Security Considerations

7.1 Authentication

   Servers only have two means of authenticating incoming connections:
   plain text password, and DNS lookups.  While these methods are weak
   and widely recognized as unsafe, their combination has proven to be
   sufficient in the past:

    * public networks typically allow user connections with only few
      restrictions, without requiring accurate authentication.

    * private networks which operate in a controlled environment often
      use home-grown authentication mechanisms not available on the
      internet: reliable ident servers [IDENT], or other proprietary
      mechanisms.

   The same comments apply to the authentication of IRC Operators.

   It should also be noted that while there has been no real demand over
   the years for stronger authentication, and no real effort to provide
   better means to safely authenticate users, the current protocol
   offers enough to be able to easily plug-in external authentication
   methods based on the information that a client can submit to the
   server upon connection: nickname, username, password.

7.2 Integrity

   Since the PASS and OPER messages of the IRC protocol are sent in
   clear text, a stream layer encryption mechanism (like "The TLS
   Protocol" [TLS]) could be used to protect these transactions.







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


8. Current support and availability

      Mailing lists for IRC related discussion:
        General discussion: [e-mail]
        Protocol development: [e-mail]

      Software implementations:
        ftp://ftp.irc.org/irc/server
        ftp://ftp.funet.fi/pub/unix/irc
        ftp://coombs.anu.edu.au/pub/irc

      Newsgroup: alt.irc

9. Acknowledgements

   Parts of this document were copied from the RFC 1459 [IRC] which
   first formally documented the IRC Protocol.  It has also benefited
   from many rounds of review and comments.  In particular, the
   following people have made significant contributions to this
   document:

   Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa
   Ruokonen, Magnus Tjernstrom, Stefan Zehl.

10. References

   [KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

   [ABNF]       Crocker, D. and P. Overell, "Augmented BNF for Syntax
                Specifications: ABNF", RFC 2234, November 1997.

   [IRC]        Oikarinen, J. and D. Reed, "Internet Relay Chat
                Protocol", RFC 1459, May 1993.

   [IRC-ARCH]   Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
                April 2000.

   [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
                2812, April 2000.


   [IRC-CHAN]   Kalt, C., "Internet Relay Chat: Channel Management", RFC
                2811, April 2000.

   [ZLIB]       Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data
                Format Specification version 3.3", RFC 1950, May 1996.




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


   [DEFLATE]    Deutsch, P., "DEFLATE Compressed Data Format
                Specification version 1.3", RFC 1951, May 1996.

   [GZIP]       Deutsch, P., "GZIP file format specification version
                4.3", RFC 1952, May 1996.

   [IDENT]      St. Johns, M., "The Identification Protocol", RFC 1413,
                February 1993.

   [TLS]        Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246,
                January 1999.

11. Author's Address

   Christophe Kalt
   99 Teaneck Rd, Apt #117
   Ridgefield Park, NJ 07660
   USA

   EMail: [e-mail]































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


12.  Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Kalt                         Informational                     [Page 26]