因特网延迟交谈:体系结构( 三 )


器或两者兼备 。在一个包含客户机和服务器的大型网络上,一条消息就能引起大量
堵塞,因为它会努力被发送到所有想达到的目的地 。
对某些种类的消息来说,没有其它选择只有向所有服务器广播,这样才能保持各个
服务器保存的状态信息之间的一致性 。
5.3.1客户机向客户机
没有哪种消息能够导致来自单一客户机的消息发送给所有其它客户机 。
5.3.2客户机向服务器
大部分引起状态信息(比如频道成员人数,频道状态,客户机状态等等)改变的命令
必须缺省地向所有服务器发送,而且这种分发不应被客户机改变 。
5.3.3服务器向服务器
尽管大多数服务器之间的消息都向所有其它服务器分发,但只有当消息影响客户机,
频道或服务器时才有必要 。因为在IRC里有一些基本的条目,因此几乎所有的来自
服务器的消息都向其它相连的服务器广播 。
6当前的问题
这个协议有一些公认的问题,这个部分仅仅讲述那些和协议体系有关的问题 。
6.1可用范围
当大范围应用时,此协议用得不太好,这一点已经得到广泛认同 。主要原因是所有服务器
都必须知道其它服务器,客户机和频道并且关于它们的信息必须及时更新 。
6.2可靠性
因为IRC服务器唯一答应的网络结构是生成树,因此两个服务器之间的连接是明显的而
且很轻易断连 。这个问题在“Internet延迟交谈:服务器协议”[IRC-SERVER]中有更加详
细的描述 。
6.3网络拥塞
生成树结构引起的问题除了可用范围和可靠性两个问题之外,还有就是使IRC极轻易导
致网络拥塞 。这个问题是区域性的,直到下一代才能解决:假如拥塞和高流量导致两个
服务器之间的连接失败,不仅这种失败导致网络拥塞,而且它们之间的重连也将导致更
加严重的网络拥塞 。
为了使这个问题的影响减到最小,服务器最好不要自动地太快地尝试重新连接,以避免
使情况恶化 。
6.4保密问题
除了不能很好地适用大范围,以及服务器必须知道其它实体的所有信息外,优先级问题
也是引人注目的问题 。非凡是对频道,
7.保密
除了6.4节提到的保密问题外,安全和这个文档不相关 。
8.目前的支持和获取渠道
IRC相关讨论邮件列表:
一般讨论:irce-user@irc.org
协议开发:ircd-dev@irc.org
实现软件:FTP://ftp.irc.org/irc/server
ftp://ftp.funet.fi/pub/unix/irc
ftp://coombs.anu.edu.au/pub/irc
新闻组:alt.irc
9.感谢
这篇文档部分拷贝自第一次正式发布的IRC协议RFC1459[IRC],它也受益于许多评论
和讨论 。非凡是以下人对这篇文档作出了重要贡献:
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-CLIENT]Kalt,C.,"InternetRelayChat:ClientProtocol",RFC
2812,April2000.
[IRC-SERVER]Kalt,C.,"InternetRelayChat:ServerProtocol",RFC
2813,April2000.
[IRC-CHAN]Kalt,C.,"InternetRelayChat:ChannelManagement",RFC
2811,April2000.
11.作者地址
ChristopheKalt
99TeaneckRd,Apt#117
RidgefieldPark,NJ07660
USA
EMail:kalt@stealth.net
12.完整版权说明
Copyright(C)TheInternetSociety(2000).AllRightsReserved.
Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING

推荐阅读