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]描述了当两台服务器连接时通
道数据是如何交换的 。通道冲突(不管是合理的或是不合理的)被认为是内部的事情,意味
着参与的通道都使通道成员优先连接 。
类似的,每个服务器发送通道状态给其它服务器 。因此,每个服务器也接收这些通道状
态 。对一个给定的通道有三种模式:标志,掩码,和数据 。前两种轻易处理,因为他们要么
设置要么不设置 。假如这样的一种模式在服务器上设置了,由于相连,它必须在另一个服务
器上也进行设置 。
推荐阅读
- Internet邮件从Just-Send-8到8bit-SMTP/MIME的转换
- 从垃圾邮件现象看Internet的技术劣根性
- Internet 网关要求 - 起草
- Internet组管理协议 IGMP报文及协议
- 因特网子网
- IOTP Internet开放贸易协议HTTP 补充
- Internet电子邮件保密增强:Part1-消息编码和鉴别过程
- 什么是WINS解析
- 3360用户初步评测 完美解决全屏手写延迟
- 如何解决收款语音提醒延迟