Internet延迟交谈：通道管理

【Internet延迟交谈：通道管理】此备忘录的状态
该备忘录为互联网团体提供信息。它并不制定任何互联网标准，可以被无限制的发布。
CopyrightNotice
Copyright(C)TheInternetSociety(2000).AllRightsReserved.
摘要
IRC(Internet延迟交谈)协议最引人注目的一个特征就是答应用户按论坛分组，称作通道，
提供了一种多个用户一起交流的方法。
这篇文档具体讲述了通道、它们的特征和属性怎样经由IRC服务器治理。
1．介绍
这篇文档具体地定义了通道是如何由IRC服务器定义的，它对从事IRC服务器实现的人
非凡有用。
尽管这里定义的概念是IRC的一个重要部分，但它们对于客户端的实现却不是必需的。
尽管客户端的趋势是越来越复杂和“聪明”，能够利用通道的内部工作为用户提供一个更
友好的界面，但是简单的客户端不需要阅读这篇文档就能够实现。
这里定义的许多概念都是由头脑里的IRC体系结构[IRC-ARCH]所限定的，并且大多数
只有在这种环境下才有意义。但是其他的许多概念能够运用到其他的体系结构，以便为会
议系统提供论坛场所。
最后，要声明的是IRC用户可能发现以下几部分有用，非凡是第二部分(通道特征)和第四
部分(通道状态) 。
2．通道特征
通道就是由一个或更多用户组成的命名组，组里所有成员都接收寄到这个通道的消息，通
道由它的名字，属性，目前的成员来标志。
2.1名字空间
通道的名字(由一个‘&’，‘#’，‘ ’或者‘！’开头)可以长达五十个字符。通道的
名字对大小写敏感。
除了第一个字符必须是‘&’，‘#’，‘ ’或者‘！’（今后称作“通道前缀”）的要
求外。对通道名字的唯一限制是它不能包含任何空格（‘’）、控制符G(^G或者ASCII7)、
逗号（‘，’被协议用作列表项的分隔符）。还有，冒号（‘：’）用作通道掩码的分隔符。
精确的通道名字语法在“IRCServerProtocol“[IRC-Server]中定义。
不同前缀的使用有效地为通道名字创造了四个名字空间。这很重要，因为此协议的局限性
和名字空间有关（一般意义上）。参阅6.1部分（标志）以获得关于局限性的更多细节。
2.2通道范围
一个通道实体被IRC网络上一个或更多个服务器所知晓。只有与用户直连的服务器
知道的通道，用户才能加入。知道一个特定通道存在的一系列服务器必须是IRC网络上
一个邻近的部分，这样发送给该通道的消息才能被发送给所有通道成员。
以‘&’为前缀的通道对创建它们的的服务器来说是本地的。
其它通道被连到网络上的一个或更多个服务器知晓，依靠于通道掩码：
假如没有通道掩码，该通道就被所有服务器知晓。
假如有一个通道掩码，此通道只被那些有本地用户连到通道上的服务器所知晓，假如
掩码和本地的以及相邻的服务器名字相配，那么也为他的邻近服务器知晓。因为其他服务
器完全没有这样一个通道的存在的任何信息，假如这个通道要为所有服务器知晓的话，这
些具有和掩码相配的名字的服务器组成的区域必须和该通道相邻。通道掩码最好与服务器
主机掩码[IRC-SERVER]配合使用。
2.3通道属性
每个通道都有它自己的有通道状态定义的属性。通道模式能够被通道成员使用。模
式影响服务器治理通道的方式。
以‘ ’作为前缀的通道不支持通道模式。这意味着所有的模式都是未设定的，只设
定了‘t’通道标志。
2.4特权通道用户
为了使通道成员对通道保持一定的控制和一些秩序，一些通道成员被赋予特权。只
有这些成员才答应在通道上执行一下操作：
INVITE—邀请一个客户到一个invite-only通道（模式 i）
KICK—将一个客户从通道中逐出
MODE—改变通道的模式，也可以改变成员的特权
PRIVMSG—向通道发消息（模式 n, m v）
TOPIC—在模式为 t的通道中改变通道主题
2.4.1通道治理员
一个给定通道上的通道治理员（也被称为“chop”或“chanop”）被认为拥有此通道。
通道所有权由通道治理员共享。
无论什么时候和通道相关，通道治理员都由与其名字相邻的‘@’符号来标志（比
如说，回答NAMES,WHO,和WHOIS命令）。
由于以字符‘ ’为前缀的通道不支持通道模式，因此没有成员具有通道治理员的地位。
2.4.2通道创建者
创建一个通道的用户称为“通道创建者”，以‘！’前缀作为其标志。一旦创建了通
道，此用户也就被赋予了通道治理员的地位。
为了识别此地位，通道创建者被赋予锁定通道状态的能力，这种能力是通道治理员所没有
的。
通过发送恰当的MODE命令能够区分‘通道创建者’和通道治理员。参阅“IRCClient
Protocol”[IRC—CLIENT]以获取这方面的更多信息。
3．通道生存期
和通道生存期相关的是，存在两组典型的通道：标准通道，它的前缀不是‘&’‘#’
就是‘ ’，以及安全通道，它的前缀是‘！’ 。
3.1标准通道
这些通道当地一个用户加入时暗中创建，最后一个用户离开时停止生存。但通道生存
时，任何客户都能够通过通道的名字引用此通道。
创建通道的用户自动变成通道治理员，当然前缀是‘ ’的通道除外，参见第四部分(通
道模式) 。参阅2.4.1部分以获取此主题的更多信息。
为了避免创建两个一样的通道（非凡是当IRC网络由于两个服务器的断连而脱节），通
道名字在通道治理员由于网络断连离开时应该不答应再被用户使用。假如这种情况发生了，
通道名字就是暂时不能使用了。通道持续不可用时间应该在每个IRC网络的基础上做出调
整。需要重点声明的是这样可以防止用同一个名字再创建一个通道，但是不能防止远端用
户重新创建该通道。后者在IRC网络重新连接时非凡轻易发生。很明显，这种机制知识和
与名字以字符‘#’开头的通道，但也可能被名字以字符‘ ’开头的通道使用。这种机制
被普遍称作‘通道延迟’ 。
3.2安全通道
和其他通道不同，“安全通道”不是暗中创建的。希望创建这类通道的用户必须向服
务器发送一个非凡的JOIN命令以申请创建，服务器中的通道标识符（接着就是未知的了）
被字符‘！’替代。此类通道的创建受到严格控制。用户只选择部分通道名字（称为通道
‘短名’），服务器自动将用户提供的名字前面加上五个通道标识符。这两种元素结合而
成的通道名字是唯一的，使通道不会因为网络断连而被滥用。
创建此类通道的用户自动成为‘通道创建者’ 。参阅2.4.2部分(通道创建者)以获得关
于此主题的更多信息。
假如新通道的短名和另一个业已存在的通道的短名相同，又假如另一个具有相同短名
的通道最近存在过而且它的成员由于网络断连离开，那么服务器就禁止这样的通道的创建。
这类通道在最后的成员离开并且最近没有其他成员由于网络断连离开后停止生存。
和5.2.2部分(通道延迟)描述的机制不同的是，在这种情况下通道的名字并不变成不可用的：
这些通道在最后的成员离开后可能继续生存。只有创建通道的用户才变成“通道创建者”，
假如一个存在的空通道的用户并不自动变成“通道创建者”也不变成“通道治理员” 。
为了保证通道名字的唯一性，由服务器创建的通道标识符必须遵循一定的规则。更多的细
节，参阅5.2.1部分（通道标识符）。
4．通道模式
通道能够获取的各种模式如下所示：
0—赋予“通道创建者”地位；
o—赋予/收回“通道治理员”特权；
v—赋予/收回发言特权；
a—转换匿名通道标志；
i—转换invite-only通道标志；
m—转换是否调节通道
n—转换是否答应外部客户发送消息到通道
q—转换安静通道标志；
p—转换私人通道标志
s—转换秘密通道标志
r—转换服务器reop通道标志
t—转换是否只能由通道治理员设置主题
k—设置/删除通道钥匙（密码）；
l—设置/删除通道用户限制
b—设置/删除禁令掩码使用户不能进入
e—设置/删除异常掩码来覆盖禁令掩码；
I—设置/删除邀请掩码来覆盖invite-only标志；
除非在下面非凡声明，所有这些状态都能被“通道治理员”通过MODE命令使用，MODE
命令在“IRCClientProtocol”[IRC-CLIENT]中定义。
4.1成员身份
此域中的模式将通道成员的昵称作为参数并影响赋予成员的特权。
4．1．1“通道创建者”身份
模式‘0’只和“安全通道”结合使用而且不能被用户使用。服务器用它来
给予创建通道的用户“通道创建者”的身份。
4．1．2通道治理员地位
模式‘o’用来转换通道成员的治理员身份。
4．1．3发言特权
模式‘v’用来给予通道成员发言特权和从成员处收回发言特权。具有这种特
权的用户能够在调节过的通道上交谈。（参阅4.2.3部分(ModeratedChannelFlag) 。
4.2通道标志
此域中的模式用来定义影响通道如何治理的属性。
4.2.1匿名标志
通道标志‘a’定义了一个匿名通道。这意味着当一条发送到通道的消息被
服务器发送给用户时，并且它来自用户，那么它就要被屏蔽掉。为了屏蔽掉消息，来源被改
成“anonymous!anonymous@anonymous.”（也就是说，一个别名是“anonymous”，用户名是
“anonymous”的用户，来自叫做“anonymous”的主机）。因为这样，服务器必须禁止别名
为“anonymous”的用户。服务器不能为用户离开这类通道而发送QUIT笑给其他通道的成员，
而是产生一条PART消息。
在以字符‘&’为前缀的通道上，这个标志也许由通道治理员转换，但是在以字符‘！’为前
缀的通道上，这个标志只能由‘通道创建者’设定（但是不能够不设定）。此标志在其它类型
的通道上不能够使用。
在匿名标志已经设定的通道上，对whois,who,和names命令的答复不能够表明通道上其他用
户的存在。
4.2.2InviteOnly标志
当通道标志‘i’设定后，新成员只有当他们的掩码和邀请列表相符（参见4.3.2部
分）或者他们已经被通道治理员邀请。这个标志也对通道治理员限制了INVITE命令的使用
（参见“IRCClientProtocol”[IRC-CLIENT] 。
4.2.3通道已调节标志
通道标志‘m’用来控制谁可以再通道上说话。当它设定时，只有通道治理员，和
被赋予了发言特权的成员才可以向其他通道发送消息。
这个标志只影响用户。
4.2.4不答应通道外客户向通道发送消息
当通道标志‘n’设定时，只有通道成员才可以向通道发送消息。
这个标志只影响用户。
4.2.5安静通道
通道标志‘q’仅供服务器使用。设定时，它限制发送给用户的关于通道操作的数据
类型：其他用户加入，离开和重要的变化都不发送。从用户的观点来看，通道只包含一个用
户。
这经常用于创建非凡的本地通道，这种通道里服务器发送和它的操作相关的通知。它作为一
种更加有效率特富有弹性的方法可以用来取代RFC1459[IRC]里定义的用户状态‘s’ 。
4.2.6私人和秘密的通道
通道标志‘p’用来标志一个通道是私人的，通道标志‘s’用来标志一个通道是秘
密的。两种性质很相似，他们都向其他用户隐藏了通道的存在。
这意味着如够不加入就没有办法从服务器得到通道的名字。换句话说，对whois命令这样的
询问的答复必须将这些通道省略掉。
当一个通道是‘秘密的’的时候，除了上面的限制外，对topic,list,names命令这样的询问，
服务器必须表现得象通道不存在一样。上述规则只有一个例外：服务器会正确地答复mode
命令。最后，当参数指定时，秘密通道没有责任回复lusers命令（参阅“InternetRelay
Chat：ClientProtocol”[IRC—CLIENT]）。
通道标志‘p’和‘s’不能同时设定。假如服务器的MODE消息设定‘p’标志而且通道已
经设定了‘s’，那么这种变化就静静地被忽略掉。这只有在断连恢复期间才能发生。（在“IRC
ServerProtocol”文档中提到）。
4.2.7服务器Reop标志
通道标志‘r’只有在名字以字符‘s’开头的通道中才可用，并且也许只能由‘通道
创建者’来转换。
这个标志用来防止一个通道长期处于无通道治理员的状态。当这个标志设定时，任何失去它
的所有通道治理员超过‘reop延迟’时期的通道将触发促发服务器里的一种机制，将通道内
的一些或所有用户重设为治理员。这种机制在5.2.4部分中有更具体的描述（通道reop机制）。
4.2.8主题
通道标志‘t’用来限制通道治理员topic命令的使用。
4.2.9用户限制
一个用户限制可以用通道标志‘l’在通道上设置。当达到限制人数时，服务器必须
禁止本地用户加入通道。
限制的值可以从服务器对mode询问的答复中获取。
4.3通道访问控制
状态的最后一个域是用来控制通道的访问的，它们将一个掩码作为参数。
为了减小为通道设置的控制访问状态的整体数据库的尺寸，服务器可能对这类状态的设定加
上一个最大值限制。假如想加上这种限制，它必须只能影响用户请求。这种限制对每个IRC
网络来说应该是类似的。
4.3.1通道禁令和异常
当用户请求加入一个通道，它的本地服务器检查用户的地址是否和通道的任何禁令掩
码相符，假如相符，用户请求就被拒绝，除非该地址也和通道的一个异常掩码相符。
服务器不答应通道禁止的成员在通道上发言，除非次成员是通道治理员或者由发言特权。（参
见4.1.3部分（发言特权））。
通道禁止的用户，假如它带有通道治理员发出的邀请，那么就答应加入通道。
4.3.2通道邀请
对那些invite-only标志设置了的通道，任何用户，只要它的地址和通道的邀请掩码
相符，就答应加入通道，即使没有受到邀请。
5．目前的实现
目前这些作为IRC协议一部分的规则的唯一实现是IRC服务器，版本2.10 。
这部分的其他内容涉及对那些希望实现服务器的人来说非凡重要的事情，但是也有些部分
对客户机程序作者很有用。
5.1追踪最近使用过的通道
这种机制一般叫做“通道延迟”，通常用于前缀是字符‘#’的通道（参见3.1部分
（“标准通道”）。
当网络发生断连，服务器必须追踪哪些通道由于断连失去了一个‘通道治理员’ 。这
些通道接着就处于一种非凡的状态，并持续一段时间。在这种非凡状态下，通道不能停
止生存。假如所有通道成员都离开了，通道就变成不可获取的：只要它是空的，本地客
户就不能加入。
一旦一个通道不可获取，当远端用户加入通道（最可能因为网络正在恢复）或延迟
期满（这种情况下通道停止生存，可能重新创建），它都会变成可获取的。通道的死亡推
迟时间的设置需要考虑很多因素，有IRC网络的规模，和网络通常断连的持续时间。对
一个给定的IRC网络来说，这个时间在所有服务器上应该都是一样的。
5.2安全通道
这篇文档介绍“安全通道”的概念。这些通道前缀为字符‘!’，并且尽最大努力避
免此名字空间内的冲突。冲突并不是不可能的，但是一般不会发生。
5.2.1通道标识符
通道标识符是时间的一个函数。当前时间被转换成五个字符的字符串，以
“ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890”为基数（每个字符都有一个十
进制的值,‘A’对应0到‘0’对应35）。
因此通道标识符的周期为36^5秒（大概700天）
5.2.2通道延迟
这些通道必须服从5.1部分描述的“通道延迟”机制。但是，这种机制被稍微改
进以运行得更好。
服务器必须追踪由于网络断连而失去成员的通道，不管失去的用户是不是‘通道治理员’ 。
但是，这些通道从不变的不可获取，即使当它们为空时也可以加入。
5.2.3滥用窗口
因为周期如此之长，对特定通道的攻击要很长时间才发生一次。但是，假如有
运气和耐心的话，用户仍然可能引起通道冲突。为了避免此类事情的发生，服务器必须
‘向长远看’，维持一个通道名字的列表，这些名字的标识符将来要用（比如在未来的几
天里）。这样的列表应该保持小的规模，不应成为服务器要维持的负担，这些列表用来在
比通道延迟更长的时期内避免相同通道的再创建。
最后一个服务器程序可能选择扩展这种程序，禁止短名相同的通道的创建（接着忽略通
道标识符）。
5.2.4保持名字空间内的正常
5.2.2和5.2.3部分描述的机制的结合使用户很难令通道发生冲突。但是，存在
另外一种形式的滥用，就是创建许多有相同短名但是不同标识符的通道。为了防止其发
生，假如通道的短名和目前业已存在的通道相同，服务器就必须禁止这个通道的创建。
5.2.5服务器Reop机制
当一个通道开放时间长于‘reop延迟’时间，并且通道设置了‘r’标志（参见
4.2.7(服务器reop标志)），IRC服务器有责任随机地将通道治理员地位赋给一些成员。
下面描述目前的实现中为这种机制使用的逻辑。服务器可能使用不同的逻辑，但是强烈
建议所有在一个IRC网络上的服务器使用相同的逻辑，以保证一致性和公正性。基于相
同的原因，对一个给定的IRC网络，“reop延迟”的值在所有主机上都应一致。同“通
道延迟”一样，“reop延迟”值的设置也应该考虑很多因素，包括IRC网络的规模，网
络断连通常的持续时间。
a) reop机制在“reop延迟”期满，一段随机时间之后被触发。这样可以限制此机制在
两台分离的服务器上同时触发的可能性。
b) 假如通道规模很小（五个用户或者更少），并且这个通道的“通道延迟”已经期满，
假如至少有一个成员对服务器来说是本地的话，那么就将所有用户重设治理员。
c) 假如通道规模很小（五个用户或者更少），并且这个通道的“通道延迟”已经期
满，“reop延迟”也已期满。接着就将所有用户重设治理员。
d) 对于其他情况，至多将通道上的一个成员重设治理员，以服务器的内建方法为基础。
假如你不将一个成员重设治理员，内建方法应该就是另一个服务器极可能将某个用
户设为治理员。这种方法在整个网络上应该都是一样的。一个好的启发式方法是随
机重设治理员。
（目前的实现实际上是试着选一个服务器的本地成员，这个成员要是没有闲置太久
的，最终推迟行动，因此使其它服务器有机会寻找一个没有太闲置的成员。这太复
杂了，因为服务器只知道本地用户的闲置时间）
6．目前的问题
IRC通道治理方式有一些问题已经被熟悉到了。有一些能直接归因于这篇文档里定义的规
则，其它的是底层的“IRCServerProtocol”的结果。尽管来源于RFC1459[IRC]，这篇文档
试着提出了一些新鲜方法解决一些已知的问题。
6.1标志
这篇文档定义了IRC协议使用的众多标志中的一个。尽管有许多不同的名字空间（给予通
道名字前缀），但是不答应在内部重用他们。目前，有可能不同服务器上的用户采用相同的可
能引起冲突的标志，（只有一个服务器知道的通道除外，这里能够防止冲突）。
6.1.1通道延迟
5.1部分描述的，由前缀是字符‘#’的通道使用的通道延迟机制（追踪最近使用过的
通道）是一个防止冲突发生的简单尝试。经验表明，在通常情况下，它非常有效；但是，很
明显它有很多局限使它不能够解决这里讨论的问题。
6.1.2安全通道
3.2部分（安全通道）描述的“安全通道”是一个较好的防止冲突发生的方法，因为
它避免用户对他们选择的标志拥有完全控制。这种标志明显的缺点是他们对用户不友好。但
是，客户端要改进这一点是相当繁琐的。
6.2状态传播延迟
因为网络引起的延迟，以及每个服务器都要求检查状态变化的正确性（比如，用户存在
且有合适的特权），有时一条状态信息只影响部分网络，经常使服务器上关于通道状态的信息
出现差异。
尽管这个毛病看起来轻易改正（通过让源服务器检查状态变化正确性的方法），但却有各种理
由决定不这样做。一种担心是服务器彼此不能信任，这样发生错误的服务器就轻易检测出来。
这样作业防止了来自各个方向状态信息的不同步对通道造成的巨大影响。
6.3冲突和通道状态
“InternetRelayChat:ServerProtocol”文档[IRC-SERVER]描述了当两台服务器连接时通
道数据是如何交换的。通道冲突（不管是合理的或是不合理的）被认为是内部的事情，意味
着参与的通道都使通道成员优先连接。
类似的，每个服务器发送通道状态给其它服务器。因此，每个服务器也接收这些通道状
态。对一个给定的通道有三种模式：标志，掩码，和数据。前两种轻易处理，因为他们要么
设置要么不设置。假如这样的一种模式在服务器上设置了，由于相连，它必须在另一个服务
器上也进行设置。
由于主题不作为交换的一部分进行发送，他们不成问题。但是，通道模式‘l’和‘k’
参与交换，假如在连接之前它们在双方服务器上都设置了，就没有一种机制来决定这两个值
那个优先。留给用户去调整由此导致的差异。
6.4资源耗尽
4.3部分定义的以掩码为基础的模式使IRC服务器（和网络）轻易草率地滥用系统：一
个通道治理员能够在一个通道上尽可能多地设置不同的掩码。这很轻易导致服务器浪费内存
和网络带宽（因为信息被传播到其它服务器上）。由于此原因，建议象4.3部分提到的那样对
每个通道能设置的掩码数量进行限制。
而且，可能还有更复杂的机制用来避免为相同的通道设置多余的掩码。
7．安全考虑
7.1访问控制
控制对通道的访问的最主要的方法之一就是使用掩码，掩码基于用户连接的用户名
和主机名。只有在IRC服务器有一种精确的鉴别用户连接的方法，并且用户不能够轻易地逃
避这种鉴别的情况下，这种机制才有效率和安全。尽管在理论上可能实现如此严格的鉴别机
制，但是大多数IRC网络（非凡是公共网络）并没有象这样的机制，而且对一个客户连接的
用户名和主机名的准确性只提供了很少的保证。
控制访问的另一种方法是使用通道钥匙，但因为这种钥匙是以纯文本形式发送的，因此中途
很轻易受到攻击。
7.2通道秘密
因为通道冲突被视为内部事件（参见6.3部分），所以有可能用户超越访问控制设置而
加入通道。这种方法很长时间都被个人用来通过非法获取通道治理员地位来“控制”通道。
同样的方法能用来找出通道的精确成员列表，以及接收许多发送给通道的消息。
7.3匿名
匿名通道标志（参见4.2.1部分）能用来向这类通道上所有用户呈递“anonymous”，方
法是使所有发送到这个通道的消息似乎都来自一个昵称为“anonymous”的假用户。这是在客
户—服务器级别上实现的，在服务器—服务器级别上不提供匿名。
对读者来说应该很明显，匿名提供的级别是很低的而且不安全，客户程序应向加入此类
通道的用户出示严重警告
8．目前的支持和获取渠道
MailinglistsforIRCrelateddiscussion:
Generaldiscussion:ircd-users@irc.org
Protocoldevelopment:ircd-dev@irc.org
Softwareimplementations:
FTP://ftp.irc.org/irc/server
ftp://ftp.funet.fi/pub/unix/irc
ftp://coombs.anu.edu.au/pub/irc
Newsgroup:alt.irc
9.感谢
PartsofthisdocumentwerecopiedfromtheRFC1459[IRC]which
firstformallydocumentedtheIRCProtocol.Ithasalsobenefited
frommanyroundsofreviewandcomments.Inparticular,the
followingpeoplehavemadesignificantcontributionstothis
document:
MatthewGreen,MichaelNeumayer,VolkerPaulsen,KurtRoeckx,Vesa
Ruokonen,MagnusTjernstrom,StefanZehl.
10.参考文献
[KEYWordS]Bradner,S.,"KeywordsforuseinRFCstoIndicate
RequirementLevels",BCP14,RFC2119,March1997.
[IRC]Oikarinen,J.andD.Reed,"InternetRelayChat
Protocol",RFC1459,May1993.
[IRC-ARCH]Kalt,C.,"InternetRelayChat:Architecture",RFC2810,
April2000.
[IRC-CLIENT]Kalt,C.,"InternetRelayChat:ClientProtocol",RFC
2812,April2000.
[IRC-SERVER]Kalt,C.,"InternetRelayChat:ServerProtocol",RFC
2813,April2000.
11.作者地址
ChristopheKalt
99TeaneckRd,Apt#117
RidgefieldPark,NJ07660
USA
EMail:kalt@stealth.net