Internet延迟交谈通道管理

1、Network Working Group C. KaltRequest for Comments: 2811 April 2000Updates: 1459Category: InformationalInternet延迟交谈：通道管理（RFC2811 Internet relay chat:client protocol）此备忘录的状态该备忘录为互联网团体提供信息。它并不制定任何互联网标准，可以被无限制的发布。Copyright NoticeCopyright (C) The Internet Society (2000). All Rights Reserved.摘要IRC(Intern

2、et延迟交谈)协议最引人注目的一个特征就是允许用户按论坛分组，称作通道，提供了一种多个用户一起交流的方法。这篇文档详细讲述了通道、它们的特征和属性怎样经由IRC服务器管理。1介绍22通道特征22.1名字空间22.2通道范围32.3通道属性32.4特权通道用户33通道生存期43.1标准通道43.2安全通道44通道模式54.1成员身份54.2通道标志64.3通道访问控制75目前的实现85.1追踪最近使用过的通道85.2安全通道86目前的问题106.1标志106.2状态传播延迟106.3冲突和通道状态116.4资源耗尽117安全考虑117.1访问控制117.2通道秘密127.3匿名128目前的支持和

3、获取渠道129. 感谢1210. 参考文献1211. 作者地址13 1介绍这篇文档详细地定义了通道是如何由IRC服务器定义的，它对从事IRC服务器实现的人特别有用。尽管这里定义的概念是IRC的一个重要部分，但它们对于客户端的实现却不是必需的。尽管客户端的趋势是越来越复杂和“聪明”，能够利用通道的内部工作为用户提供一个更友好的界面，但是简单的客户端不需要阅读这篇文档就能够实现。这里定义的许多概念都是由头脑里的IRC体系结构 IRC-ARCH所限定的，并且大多数只有在这种环境下才有意义。但是其他的许多概念能够运用到其他的体系结构，以便为会议系统提供论坛场所。最后，要声明的是IRC用户可能发现以下几

4、部分有用，特别是第二部分(通道特征)和第四部分(通道状态)。2通道特征通道就是由一个或更多用户组成的命名组，组里所有成员都接收寄到这个通道的消息，通道由它的名字，属性，目前的成员来标志。2.1名字空间 通道的名字(由一个&，#，+或者！开头)可以长达五十个字符。通道的名字对大小写敏感。除了第一个字符必须是&，#，+或者！（今后称作“通道前缀”）的要求外。对通道名字的唯一限制是它不能包含任何空格（ ）、控制符G(G或者ASCII 7)、逗号（，被协议用作列表项的分隔符）。还有，冒号（：）用作通道掩码的分隔符。精确的通道名字语法在“IRC Server Protocol“IRC-S

5、erver中定义。不同前缀的使用有效地为通道名字创造了四个名字空间。这很重要，因为此协议的局限性和名字空间有关（一般意义上）。参阅6.1部分（标志）以获得关于局限性的更多细节。2.2通道范围 一个通道实体被IRC网络上一个或更多个服务器所知晓。只有与用户直连的服务器知道的通道，用户才能加入。知道一个特定通道存在的一系列服务器必须是IRC网络上一个邻近的部分，这样发送给该通道的消息才能被发送给所有通道成员。以&为前缀的通道对创建它们的的服务器来说是本地的。其它通道被连到网络上的一个或更多个服务器知晓，依赖于通道掩码：如果没有通道掩码，该通道就被所有服务器知晓。如果有一个通道掩码，此通道只

6、被那些有本地用户连到通道上的服务器所知晓，如果掩码和本地的以及相邻的服务器名字相配，那么也为他的邻近服务器知晓。因为其他服务器完全没有这样一个通道的存在的任何信息，如果这个通道要为所有服务器知晓的话，这些具有和掩码相配的名字的服务器组成的区域必须和该通道相邻。通道掩码最好与服务器主机掩码IRC-SERVER配合使用。2.3通道属性 每个通道都有它自己的有通道状态定义的属性。通道模式能够被通道成员使用。模式影响服务器管理通道的方式。 以+作为前缀的通道不支持通道模式。这意味着所有的模式都是未设定的，只设定了t通道标志。2.4特权通道用户 为了使通道成员对通道保持一定的控制和一些秩序，一些通道成员

7、被赋予特权。只有这些成员才允许在通道上执行一下操作： INVITE 邀请一个客户到一个invite-only通道（模式+i） KICK 将一个客户从通道中逐出 MODE 改变通道的模式，也可以改变成员的特权 PRIVMSG 向通道发消息（模式 +n,+m+v） TOPIC 在模式为+t的通道中改变通道主题2.4.1通道管理员 一个给定通道上的通道管理员（也被称为“chop”或“chanop”）被认为拥有此通道。通道所有权由通道管理员共享。 无论什么时候和通道相关，通道管理员都由与其名字相邻的符号来标志（比如说，回答NAMES,WHO,和WHOIS命令）。 由于以字符+为前缀的通道不支持通道模式

8、，因此没有成员具有通道管理员的地位。2.4.2通道创建者 创建一个通道的用户称为“通道创建者”，以！前缀作为其标志。一旦创建了通道，此用户也就被赋予了通道管理员的地位。 为了识别此地位，通道创建者被赋予锁定通道状态的能力，这种能力是通道管理员所没有的。 通过发送恰当的MODE命令能够区分通道创建者和通道管理员。参阅“IRC Client Protocol”IRCCLIENT以获取这方面的更多信息。3通道生存期 和通道生存期相关的是，存在两组典型的通道：标准通道，它的前缀不是&#就是+，以及安全通道，它的前缀是！。3.1标准通道 这些通道当地一个用户加入时暗中创建，最后一个用户离开时停止

9、生存。但通道生存时，任何客户都能够通过通道的名字引用此通道。 创建通道的用户自动变成通道管理员，当然前缀是+的通道除外，参见第四部分(通道模式)。参阅2.4.1部分以获取此主题的更多信息。 为了避免创建两个一样的通道（特别是当IRC网络由于两个服务器的断连而脱节），通道名字在通道管理员由于网络断连离开时应该不允许再被用户使用。如果这种情况发生了，通道名字就是暂时不能使用了。通道持续不可用时间应该在每个IRC网络的基础上做出调整。需要重点声明的是这样可以防止用同一个名字再创建一个通道，但是不能防止远端用户重新创建该通道。后者在IRC网络重新连接时特别容易发生。很明显，这种机制知识和与名字以字符#

10、开头的通道，但也可能被名字以字符+开头的通道使用。这种机制被普遍称作通道延迟。3.2安全通道 和其他通道不同，“安全通道”不是暗中创建的。希望创建这类通道的用户必须向服务器发送一个特别的JOIN命令以申请创建，服务器中的通道标识符（接着就是未知的了）被字符！替代。此类通道的创建受到严格控制。用户只选择部分通道名字（称为通道短名），服务器自动将用户提供的名字前面加上五个通道标识符。这两种元素结合而成的通道名字是唯一的，使通道不会因为网络断连而被滥用。 创建此类通道的用户自动成为通道创建者。参阅2.4.2部分(通道创建者)以获得关于此主题的更多信息。 如果新通道的短名和另一个业已存在的通道的短名相

11、同，又如果另一个具有相同短名的通道最近存在过而且它的成员由于网络断连离开，那么服务器就禁止这样的通道的创建。这类通道在最后的成员离开并且最近没有其他成员由于网络断连离开后停止生存。 和5.2.2部分(通道延迟)描述的机制不同的是，在这种情况下通道的名字并不变成不可用的：这些通道在最后的成员离开后可能继续生存。只有创建通道的用户才变成“通道创建者”，假如一个存在的空通道的用户并不自动变成“通道创建者”也不变成“通道管理员”。 为了保证通道名字的唯一性，由服务器创建的通道标识符必须遵循一定的规则。更多的细节，参阅5.2.1部分（通道标识符）。4通道模式 通道能够获取的各种模式如下所示： 0 赋予“

12、通道创建者”地位； o 赋予/收回 “通道管理员”特权； v 赋予/收回 发言特权； a 转换匿名通道标志； i 转换invite-only通道标志； m 转换是否调节通道 n 转换是否允许外部客户发送消息到通道 q 转换安静通道标志； p 转换私人通道标志 s 转换秘密通道标志 r 转换服务器reop通道标志 t 转换是否只能由通道管理员设置主题 k 设置/删除通道钥匙（密码）； l 设置/删除通道用户限制 b 设置/删除禁令掩码使用户不能进入 e 设置/删除异常掩码来覆盖禁令掩码； I 设置/删除邀请掩码来覆盖invite-only标志； 除非在下面特别声明，所有这些状态都能被“通道管理员

13、”通过MODE命令使用，MODE命令在“IRC Client Protocol”IRC-CLIENT中定义。4.1成员身份 此域中的模式将通道成员的昵称作为参数并影响赋予成员的特权。 411“通道创建者”身份 模式0只和“安全通道”结合使用而且不能被用户使用。服务器用它来给予创建通道的用户“通道创建者”的身份。 412通道管理员地位 模式o用来转换通道成员的管理员身份。 413发言特权 模式v用来给予通道成员发言特权和从成员处收回发言特权。具有这种特权的用户能够在调节过的通道上交谈。（参阅4.2.3部分(Moderated Channel Flag)。4.2通道标志 此域中的模式用来定义影响通

14、道如何管理的属性。4.2.1匿名标志 通道标志a定义了一个匿名通道。这意味着当一条发送到通道的消息被服务器发送给用户时，并且它来自用户，那么它就要被屏蔽掉。为了屏蔽掉消息，来源被改成“anonymous!anonymousanonymous.”（也就是说，一个别名是“anonymous”，用户名是“anonymous”的用户，来自叫做“anonymous”的主机）。因为这样，服务器必须禁止别名为“anonymous”的用户。服务器不能为用户离开这类通道而发送QUIT笑给其他通道的成员，而是产生一条PART消息。在以字符&为前缀的通道上，这个标志也许由通道管理员转换，但是在以字符！为前缀

15、的通道上，这个标志只能由通道创建者设定（但是不能够不设定）。此标志在其它类型的通道上不能够使用。在匿名标志已经设定的通道上，对whois,who,和names命令的答复不能够表明通道上其他用户的存在。4.2.2 Invite Only标志 当通道标志i设定后，新成员只有当他们的掩码和邀请列表相符（参见4.3.2部分）或者他们已经被通道管理员邀请。这个标志也对通道管理员限制了INVITE命令的使用（参见“IRC Client Protocol”IRC-CLIENT。4.2.3通道已调节标志 通道标志m用来控制谁可以再通道上说话。当它设定时，只有通道管理员，和被赋予了发言特权的成员才可以向其他通道

16、发送消息。这个标志只影响用户。4.2.4不允许通道外客户向通道发送消息 当通道标志n设定时，只有通道成员才可以向通道发送消息。 这个标志只影响用户。4.2.5安静通道 通道标志q仅供服务器使用。设定时，它限制发送给用户的关于通道操作的数据类型：其他用户加入，离开和重要的变化都不发送。从用户的观点来看，通道只包含一个用户。这经常用于创建特别的本地通道，这种通道里服务器发送和它的操作相关的通知。它作为一种更加有效率特富有弹性的方法可以用来取代RFC 1459IRC里定义的用户状态s。4.2.6私人和秘密的通道 通道标志p用来标志一个通道是私人的，通道标志s用来标志一个通道是秘密的。两种性质很相似，

17、他们都向其他用户隐藏了通道的存在。 这意味着如够不加入就没有办法从服务器得到通道的名字。换句话说，对whois命令这样的询问的答复必须将这些通道省略掉。当一个通道是秘密的的时候，除了上面的限制外，对topic,list,names命令这样的询问，服务器必须表现得象通道不存在一样。上述规则只有一个例外：服务器会正确地答复mode命令。最后，当<mask>参数指定时，秘密通道没有责任回复lusers命令（参阅“Internet Relay Chat：Client Protocol”IRCCLIENT）。通道标志p和s不能同时设定。如果服务器的MODE消息设定p标志而且通道已经设定了s，

18、那么这种变化就静静地被忽略掉。这只有在断连恢复期间才能发生。（在“IRC Server Protocol”文档中提到）。4.2.7服务器Reop标志 通道标志r只有在名字以字符s开头的通道中才可用，并且也许只能由通道创建者 来转换。这个标志用来防止一个通道长期处于无通道管理员的状态。当这个标志设定时，任何失去它的所有通道管理员超过reop延迟时期的通道将触发促发服务器里的一种机制，将通道内的一些或所有用户重设为管理员。这种机制在5.2.4部分中有更详细的描述（通道reop机制）。4.2.8主题 通道标志t用来限制通道管理员topic命令的使用。4.2.9用户限制 一个用户限制可以用通道标志l在

19、通道上设置。当达到限制人数时，服务器必须禁止本地用户加入通道。限制的值可以从服务器对mode询问的答复中获取。4.3通道访问控制 状态的最后一个域是用来控制通道的访问的，它们将一个掩码作为参数。为了减小为通道设置的控制访问状态的整体数据库的尺寸，服务器可能对这类状态的设定加上一个最大值限制。如果想加上这种限制，它必须只能影响用户请求。这种限制对每个IRC网络来说应该是类似的。4.3.1通道禁令和异常 当用户请求加入一个通道，它的本地服务器检查用户的地址是否和通道的任何禁令掩码相符，如果相符，用户请求就被拒绝，除非该地址也和通道的一个异常掩码相符。服务器不允许通道禁止的成员在通道上发言，除非次成

20、员是通道管理员或者由发言特权。（参见4.1.3部分（发言特权）。 通道禁止的用户，如果它带有通道管理员发出的邀请，那么就允许加入通道。 4.3.2通道邀请 对那些invite-only标志设置了的通道，任何用户，只要它的地址和通道的邀请掩码相符，就允许加入通道，即使没有受到邀请。5目前的实现 目前这些作为IRC协议一部分的规则的唯一实现是IRC服务器，版本2.10。 这部分的其他内容涉及对那些希望实现服务器的人来说特别重要的事情，但是也有些部分对客户机程序作者很有用。5.1追踪最近使用过的通道 这种机制一般叫做“通道延迟”，通常用于前缀是字符#的通道（参见3.1部分（“标准通道”）。 当网络发

21、生断连，服务器必须追踪哪些通道由于断连失去了一个通道管理员。这些通道接着就处于一种特殊的状态，并持续一段时间。在这种特殊状态下，通道不能停止生存。如果所有通道成员都离开了，通道就变成不可获取的：只要它是空的，本地客户就不能加入。 一旦一个通道不可获取，当远端用户加入通道（最可能因为网络正在恢复）或延迟期满（这种情况下通道停止生存，可能重新创建），它都会变成可获取的。通道的死亡推迟时间的设置需要考虑很多因素，有IRC网络的规模，和网络通常断连的持续时间。对一个给定的IRC网络来说，这个时间在所有服务器上应该都是一样的。5.2安全通道 这篇文档介绍“安全通道”的概念。这些通道前缀为字符!，并且尽最

22、大努力避免此名字空间内的冲突。冲突并不是不可能的，但是一般不会发生。5.2.1通道标识符 通道标识符是时间的一个函数。当前时间被转换成五个字符的字符串，以“ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890”为基数（每个字符都有一个十进制的值,A对应0到0对应35）。 因此通道标识符的周期为365秒（大概700天）5.2.2通道延迟 这些通道必须服从5.1部分描述的“通道延迟”机制。但是，这种机制被稍微改进以运行得更好。 服务器必须追踪由于网络断连而失去成员的通道，不管失去的用户是不是通道管理员。 但是，这些通道从不变的不可获取，即使当它们为空时也可以加入。5.2.3滥用

23、窗口 因为周期如此之长，对特定通道的攻击要很长时间才发生一次。但是，如果有运气和耐心的话，用户仍然可能引起通道冲突。为了避免此类事情的发生，服务器必须向长远看，维持一个通道名字的列表，这些名字的标识符将来要用（比如在未来的几天里）。这样的列表应该保持小的规模，不应成为服务器要维持的负担，这些列表用来在比通道延迟更长的时期内避免相同通道的再创建。 最后一个服务器程序可能选择扩展这种程序，禁止短名相同的通道的创建（接着忽略通道标识符）。5.2.4保持名字空间内的正常 5.2.2和5.2.3部分描述的机制的结合使用户很难令通道发生冲突。但是，存在另外一种形式的滥用，就是创建许多有相同短名但是不同标识

24、符的通道。为了防止其发生，如果通道的短名和目前业已存在的通道相同，服务器就必须禁止这个通道的创建。5.2.5服务器Reop 机制 当一个通道开放时间长于reop延迟时间，并且通道设置了r标志（参见4.2.7(服务器reop标志)），IRC服务器有责任随机地将通道管理员地位赋给一些成员。 下面描述目前的实现中为这种机制使用的逻辑。服务器可能使用不同的逻辑，但是强烈建议所有在一个IRC网络上的服务器使用相同的逻辑，以保证一致性和公正性。基于相同的原因，对一个给定的IRC网络，“reop延迟”的值在所有主机上都应一致。同“通道延迟”一样，“reop延迟”值的设置也应该考虑很多因素，包括IRC网络的规

25、模，网络断连通常的持续时间。a)reop机制在“reop延迟”期满，一段随机时间之后被触发。这样可以限制此机制在两台分离的服务器上同时触发的可能性。b)如果通道规模很小（五个用户或者更少），并且这个通道的“通道延迟”已经期满，如果至少有一个成员对服务器来说是本地的话，那么就将所有用户重设管理员。c)如果通道规模很小（五个用户或者更少），并且这个通道的“通道延迟”已经期 满，“reop延迟”也已期满。接着就将所有用户重设管理员。d)对于其他情况，至多将通道上的一个成员重设管理员，以服务器的内建方法为基础。如果你不将一个成员重设管理员，内建方法应该就是另一个服务器极可能将某个用户设为管理员。这种方

26、法在整个网络上应该都是一样的。一个好的启发式方法是随机重设管理员。（目前的实现实际上是试着选一个服务器的本地成员，这个成员要是没有闲置太久的，最终推迟行动，因此使其它服务器有机会寻找一个没有太闲置的成员。这太复杂了，因为服务器只知道本地用户的闲置时间）6目前的问题 IRC通道管理方式有一些问题已经被认识到了。有一些能直接归因于这篇文档里定义的规则，其它的是底层的“IRC Server Protocol”的结果。尽管来源于RFC 1459IRC，这篇文档试着提出了一些新鲜方法解决一些已知的问题。6.1标志 这篇文档定义了IRC协议使用的众多标志中的一个。尽管有许多不同的名字空间（给予通道名字前缀

27、），但是不允许在内部重用他们。目前，有可能不同服务器上的用户采用相同的可能引起冲突的标志，（只有一个服务器知道的通道除外，这里能够防止冲突）。6.1.1通道延迟 5.1部分描述的，由前缀是字符#的通道使用的通道延迟机制（追踪最近使用过的通道）是一个防止冲突发生的简单尝试。经验表明，在通常情况下，它非常有效；但是，很明显它有很多局限使它不能够解决这里讨论的问题。6.1.2安全通道 3.2部分（安全通道）描述的“安全通道”是一个较好的防止冲突发生的方法，因为它避免用户对他们选择的标志拥有完全控制。这种标志明显的缺点是他们对用户不友好。但是，客户端要改进这一点是相当繁琐的。6.2状态传播延迟 因为网

28、络引起的延迟，以及每个服务器都要求检查状态变化的正确性（比如，用户存在且有合适的特权），有时一条状态信息只影响部分网络，经常使服务器上关于通道状态的信息出现差异。尽管这个毛病看起来容易改正（通过让源服务器检查状态变化正确性的方法），但却有各种理由决定不这样做。一种担心是服务器彼此不能信任，这样发生错误的服务器就容易检测出来。这样作业防止了来自各个方向状态信息的不同步对通道造成的巨大影响。6.3冲突和通道状态 “Internet Relay Chat:Server Protocol”文档IRC-SERVER描述了当两台服务器连接时通道数据是如何交换的。通道冲突（不管是合理的或是不合理的）被认为是

29、内部的事情，意味着参与的通道都使通道成员优先连接。类似的，每个服务器发送通道状态给其它服务器。因此，每个服务器也接收这些通道状态。对一个给定的通道有三种模式：标志，掩码，和数据。前两种容易处理，因为他们要么设置要么不设置。如果这样的一种模式在服务器上设置了，由于相连，它必须在另一个服务器上也进行设置。由于主题不作为交换的一部分进行发送，他们不成问题。但是，通道模式l和k参与交换，如果在连接之前它们在双方服务器上都设置了，就没有一种机制来决定这两个值那个优先。留给用户去调整由此导致的差异。6.4资源耗尽 4.3部分定义的以掩码为基础的模式使IRC服务器（和网络）容易草率地滥用系统：一个通道管理员

30、能够在一个通道上尽可能多地设置不同的掩码。这很容易导致服务器浪费内存和网络带宽（因为信息被传播到其它服务器上）。由于此原因，建议象4.3部分提到的那样对每个通道能设置的掩码数量进行限制。而且，可能还有更复杂的机制用来避免为相同的通道设置多余的掩码。7安全考虑7.1访问控制 控制对通道的访问的最主要的方法之一就是使用掩码，掩码基于用户连接的用户名和主机名。只有在IRC服务器有一种精确的鉴别用户连接的方法，并且用户不能够轻易地逃避这种鉴别的情况下，这种机制才有效率和安全。尽管在理论上可能实现如此严格的鉴别机制，但是大多数IRC网络（特别是公共网络）并没有象这样的机制，而且对一个客户连接的用户名和主

31、机名的准确性只提供了很少的保证。控制访问的另一种方法是使用通道钥匙，但因为这种钥匙是以纯文本形式发送的，因此中途很容易受到攻击。7.2通道秘密因为通道冲突被视为内部事件（参见6.3部分）， 所以有可能用户超越访问控制设置而加入通道。这种方法很长时间都被个人用来通过非法获取通道管理员地位来“控制”通道。同样的方法能用来找出通道的精确成员列表，以及接收许多发送给通道的消息。7.3匿名匿名通道标志（参见4.2.1部分）能用来向这类通道上所有用户呈递“anonymous”，方法是使所有发送到这个通道的消息好像都来自一个昵称为“anonymous”的假用户。这是在客户服务器级别上实现的，在服务器服务器级别上不提供匿名。对读者来说应该很明显，匿名提供的级别是很低的而且不安全，客户程序应向加入此类通道的用户出示严重警告8目前的支持和获取渠道 Mailing lists for IRC related discussion: General discussion: Protocol development: Software implementations: /irc/server ftp:/ftp.funet.fi/pub/unix/irc ftp:/coombs.anu.e