rfc2810.txt

<VC++网络游戏建摸与实现>源代码


RFC 2810           Internet Relay Chat: Architecture          April 2000


   Example 6: Clients 1, 2 and 3 in a channel.  All messages to the
       channel are sent to all clients and only those servers which must
       be traversed by the message if it were a private message to a
       single client.  If client 1 sends a message, it goes back to
       client 2 and then via server B to client 3.

5.2.2 To A Host/Server Mask

   To provide with some mechanism to send messages to a large body of
   related users, host and server mask messages are available.  These
   messages are sent to users whose host or server information match
   that of the mask.  The messages are only sent to locations where
   users are, in a fashion similar to that of channels.

5.2.3 To A List

   The least efficient style of one-to-many conversation is through
   clients talking to a 'list' of targets (client, channel, mask).  How
   this is done is almost self explanatory: the client gives a list of
   destinations to which the message is to be delivered and the server
   breaks it up and dispatches a separate copy of the message to each
   given destination.

   This is not as efficient as using a channel since the destination
   list MAY be broken up and the dispatch sent without checking to make
   sure duplicates aren't sent down each path.

5.3 One-To-All

   The one-to-all type of message is better described as a broadcast
   message, sent to all clients or servers or both.  On a large network
   of users and servers, a single message can result in a lot of traffic
   being sent over the network in an effort to reach all of the desired
   destinations.

   For some class of messages, there is no option but to broadcast it to
   all servers so that the state information held by each server is
   consistent between servers.

5.3.1 Client-to-Client

   There is no class of message which, from a single message, results in
   a message being sent to every other client.








Kalt                         Informational                      [Page 6]

RFC 2810           Internet Relay Chat: Architecture          April 2000


5.3.2 Client-to-Server

   Most of the commands which result in a change of state information
   (such as channel membership, channel mode, user status, etc.) MUST be
   sent to all servers by default, and this distribution SHALL NOT be
   changed by the client.

5.3.3 Server-to-Server

   While most messages between servers are distributed to all 'other'
   servers, this is only required for any message that affects a user,
   channel or server.  Since these are the basic items found in IRC,
   nearly all messages originating from a server are broadcast to all
   other connected servers.

6. Current Problems

   There are a number of recognized problems with this protocol, this
   section only addresses the problems related to the architecture of
   the protocol.

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,
   clients and channels and that information regarding them be updated
   as soon as it changes.

6.2 Reliability

   As the only network configuration allowed for IRC servers is that of
   a spanning tree, each link between two servers is an obvious and
   quite serious point of failure.  This particular issue is addressed
   more in detail in "Internet Relay Chat: Server Protocol" [IRC-
   SERVER].

6.3 Network Congestion

   Another problem related to the scalability and reliability issues, as
   well as the spanning tree architecture, is that the protocol and
   architecture for IRC are extremely vulnerable to network congestions.
   This problem is endemic, and should be solved for the next
   generation: if congestion and high traffic volume cause a link
   between two servers to fail, not only this failure generates more
   network traffic, but the reconnection (eventually elsewhere) of two
   servers also generates more traffic.




Kalt                         Informational                      [Page 7]

RFC 2810           Internet Relay Chat: Architecture          April 2000


   In an attempt to minimize the impact of these problems, it is
   strongly RECOMMENDED that servers do not automatically try to
   reconnect too fast, in order to avoid aggravating the situation.

6.4 Privacy

   Besides not scaling well, the fact that servers need to know all
   information about other entities, the issue of privacy is also a
   concern. This is in particular true for channels, as the related
   information is quite a lot more revealing than whether a user is
   online or not.

7. Security Considerations

   Asides from the privacy concerns mentioned in section 6.4 (Privacy),
   security is believed to be irrelevant to this document.

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.











Kalt                         Informational                      [Page 8]

RFC 2810           Internet Relay Chat: Architecture          April 2000


10. References

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

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

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

   [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
                2813, April 2000.

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

11. Author's Address

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

   EMail: [e-mail]


























Kalt                         Informational                      [Page 9]

RFC 2810           Internet Relay Chat: Architecture          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 10]