rfc2813.txt

很多RFC的中文文档

并且以这样的形式来完成网络服务。“P”标志位通常在两个服务器连接中使用。如果这个
标志位现在存在，就说明服务器的保护是激活的，并且那个服务器需要所有与它相连的服务
器都激活此项。

建立普通的保护在5。7中描述（跟踪当前用户的呢称）和5。8（客户端的防火墙）。

5．3．2在连接是改变状态信息

在服务器之间改变状态信息的顺序是必需的。格式如下：
*众所周知的服务器
*众所周知的客户端信息
*众所周知的信道信息

关于服务器的信息是被额外的服务器信息发送的，客户端信息包括了呢称和服务，信道信息
包括NJOIN/MODE信息也一起被发送。

注意：信道标题在这里不可以被改变，因为标题会覆盖掉所有旧的标题信息，所以，最起码
要服务器两端一起修改。

通过一开始就传输的有关服务器的状态信息，任何已经出现的有关服务器的冲突就会发生，
在呢称冲突（由于另外的服务器也有相同的呢称）之前。归功于IRC网络服务只可以以非
循环图的形式表现，所以也有可能网络服务在其他的地方已经从新连接过了。在处理这种事
情时，服务器冲突发生的地方，就以为这网络要分裂了。

5．4中断服务器与客户端的连接

当一个客户端连接出乎意料的中断了，服务器就会在客户端上产生一个QUIT 信息。其他
的命令都不用。

5．5中断之间的连接

如果服务器到服务器之间的连接被中断了，不管是SQUIT或者“NATRUAL”原因，剩下
的IRC网络服务就一定由检测到中断的那个服务器来休正。中断的那个就要发送一个SQUIT
清单。（给这个连接之后的每一个服务器一个）（请看4。1。6）。

5．6跟踪呢称变化

所有IRC服务器都必须保存一份记录，有关呢称改变的。这很重要，尤其是对于服务器可
以在呢称改变是，用适当的命令来与它们保持联系。跟踪的信息：

*KILL（该呢称断线）
*MODE(+/- o,v on channels)
*KICK（该呢称被从信道上消除了）

其他命令不需要检查呢称改变。

在上述情况中，服务器要先检测现有的呢称，然后查看历史记录，那个呢称现在属于谁？这
就降低了出错的可能性，但是它还是会在服务器终止一个错误的客户端是发生。当实现一个
改变对上述命令的跟踪时，建议限定历史的时间范围，太旧的记录可以被忽略。

对于一个合情合理的历史记录，服务器就应该保存客户端以前的名称，如果它们想改变名称
的话。这种状况会有其他因素制约。（比如记忆体，等等）

5．7跟踪最近使用过的用户名

这种体制通常被认为是“NICK DELAY”，它已经被证实，可以减少用户名冲突的数量，就
是那些主要由网络分裂和再登陆引起的。

保持跟踪呢称的改变，服务器要随时跟踪最近使用过的用户，并且随时释放那些被网络分裂
和KILL信息加载过的用户名。这些呢称就会变成不可信的，对于服务器当地的客户端。并
且在一端特定的时间里不能被使用。

呢称不可使用的时间限制，是受许多因素影响的，这些因素大多与IRC网络服务和普通的
网络分裂的时间有关。对于所有服务器来说，这是个规矩。

5．8客户端的溢出控制

由于太多的网络服务连接IRC 服务器上，对于每一个客户端来说，提供连穿的信息是非常
容易的，不仅仅是溢出,同时也会降低对其他服务器服务的级别。不是对每个受害人都提供
保护，溢出保护被写进服务器，被应用到客户端，除了服务。当前采用的法则运算是这样的：

*检查客户端的信息记时器比当前的时间少（设置成相等看看是否相同）。

*从客户端读取信息

*如果记时器比当前的少10秒，分析当前信息，然后把每个信息都向后2秒。

*附加处罚可能用来一些特殊的信息，可以产生很多通过网络传输的输入。

5．9无模块查找

在一个真实时间的环境里，所必须的是，服务器进程做最少时间的等待，所以所有客户端服
务都是平等的。很明显，这就需要在读/写操作上执行无模块的IO。对于那些普通的服务器
连接，这并不难，但是还有些其他相关的操作，可能会导致服务器停止（比如读盘）。在那
些可能的地方，这种行为可能会导致时间超标。

5．9．1主机名查询（DNS）

使用标准的Berkeley伯克利资料库，或者其他的资料库，就意味着在某些事情中会产生大
量的中断，而且会出现回复暂停。为了防止这种事情发生，一个独立的DNS程序被写入了
为了当前的执行。程序被安装，连同当地的高速缓冲存储器一起，就可以达到无模块化的
IO操作，然后就可以被拖进主服务器IO回路。

5．9．2用户名（IDENT）查询

尽管有很多用户名资料库（执行见证协定[IDENT]），可以使用，并且包含了很多的其他的
程序，这就导致了问题的发生，因为它们以相同的方式操作，并且导致了很多频繁的延迟。
同样，解决方法就是写一个程序，它可以同其他服务器连接，并且可以使用NON-BLOCKING 
IO。

6．当前问题

这个协议中公认的问题就有很多，所有的问题都期待着能在不久的将来被解决。现在，这项
工作已经在进行中了。

6．1可靠性

广泛认同：如果协议在一个很大的地区使用，那它就不能很好的工作。最大的问题就是服务
器需要了解所有其他服务器和客户端的信息，只要它们一改变，就随之改变。保持服务器数
量低也是个有效的办法，只要如此，两点之间的距离就不会太长，生成的树型网络也就有效
的多。

6．2标志

当前的IRC协议有四个类型的标志：用户呢称，信道名，服务器名，服务名。每一个都有
自己的使用范围，并且在自己的范围里，没有复本。当前，如果用户把其中一个当作另外三
个，就会引起冲突。广泛的认同：这项操作需要重新设计，有这样一个计划：每一个标志有
它们自己的特殊的名字，就象解决循环树问题一样。

6．2．1呢称

IRC中关于呢称的方法对于用户来说，是非常方便的，尤其是在信道外聊天时。但是，存储
呢称的空间是有限的，并且一直存在，几个人用一个名字是不可以的。如果两个人选了一个
名字，那么其中的一个，或者两个人一起，会被KILL命令删除。（详情请看3。7。1IRC客
户端协议[IRC客户端]）

6．2．2信道

当前的信道规则：所有服务器都要知道所有信道，它们的位置和特性。由于执行不是很好，
不被干扰的事情还是需要担心的。信道冲突被看作是集体冲突（信道上两个网中的人有着一
样的名字被认为是信道中的成员），而不是象呢称冲突一样的单一事件。

协议定义了"安全信道"，这种信道不太可能发生信道冲突。其他信道模式保存下来为了向后
的兼容性。

6．3运算法则

服务器代码中的某些地方，不可以不用N^2这样的法则，因为要检测信道上的客户端。

在当前服务器的版本中，只有少数数据库包含了检测方法，现在大多数服务器，每一个都只
能假想周边的服务器是正确的。这就为大量问题打开了大门，如果一个连接中服务器有问题，
或者它正向网络中散发病毒。

当前，由于缺少独一无二的中央处理器和全球范围的标志，多种多样的问题都已经出现。这
种情况大多是由问题引发的，因为它们需要时间来传播信息，并且作用于网络。即使把它们
更改成独一无二的标志，也还是会产生问题，使信道连接中断。

7．安全考虑

7．1证明

服务器通常只有两种方法来鉴别加入的连接：检测密码和DNS查找。尽管这种方法是脆弱
的并且被公认为不够安全，它们的合并已经在过去被证实了：

*公共的网络只需要对用户进行很少的限制和约定，不需要很严格的测试。

*在控制环境下的私人网络，经常使用HOME-GROWN鉴定装置，但是在INTERNET上是
不可信的：只有在某些服务器上[IDENT]，或者其他私有的服务器上才是可用的。

同样的坚定应用与IRC 操作员的鉴定。

同样也会注意：就是那里有很多年不需要更强的鉴定，不需要更大的努力提供更好的鉴别用
户，当前的协议提供了足够的额外的鉴别方法，以客户端信息为基础，并且服从于服务器连
接，：服务器名，用户名，密码。

7．2完整性

路径和操作信息被发送进空白的文档，串层加密装置，（象TLS协议），可以用来保护这些
操作。

8．相关支持和联接

IRC相关讨论：主论区：[e-mail]
协议开发：[e-mail]
软件操作：
        ftp://ftp.irc.org/irc/server
        ftp://ftp.funet.fi/pub/unix/irc
        ftp://coombs.anu.edu.au/pub/irc
新闻组：alt.irc

9．鸣谢：
这篇文章部分是从RFC-1459[IRC]，是第一次正式的公布IRC协议。它得意于很多的观点和
内容。特别是下面的对本书作出极大贡献：
Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa
   Ruokonen, Magnus Tjernstrom, Stefan Zehl.

10．参考书目：


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

   [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．作者地址

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

   EMail: [e-mail]

12．版权说明


   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.

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




RFC2813——Internet Relay Chat: Server Protocol            Internet 交换交谈：服务器协议


1
RFC文档中文翻译计划