交换交谈服务器协议

1、交换交谈效劳器协议Request for Comments: 2813April 2000Updates: 1459Category: InformationalInternet交换交谈：效劳器协议(RFC2813Internet Relay Chat: Server Protocol)备忘录的状态：那个备忘录提供了 internet群体的信息.它并没有详细讲明每一种inte rnet的标准.那个备忘录的适用范畴是无拘谨的.版权通告：copyright (c) internet Society (2000). All Rights Reserved.摘要：以客户端一一效劳器为模板,irc协议承

2、诺效劳器连接到另外的有效形 成的网络.本文档定义了效劳器用于互相交流的协议.它原先只是一个客户端协议的超集,然而差不多发展的不同了.正式的出版是在1993年5月作为rfc的一局部.从那时以来,大多数 的为了使协议更加标准的改变都能够在这篇文章中找到.更加标准的协议差不多承诺显现 在万维网中,以使它能够保持持续的更新,同时有不于原先的版本.名目1绪论22. 全球数据库33. 1效劳器34. 2客户端32. 3信道 43. irc效劳器的讲明 43. 1概要 43. 2特点代码 43. 3信息 55. 4数字回复64信息细节 64. 1连线注册74. 2信道操作：116. 3模式信息135.执行细

3、节135. 1连接失效135. 2同意客户端到效劳器的连接135. 3终结一个效劳器到效劳器的连接145. 4中断效劳器与客户端的连接165. 5中断之间的连接165. 6跟踪呢称变化165. 7跟踪最近使用过的用户名175. 8客户端的溢出操纵177. 9无模块查找178. 当前咨询题186 . 1可靠性187 . 2标志 188 . 3运算法那么197.平安考虑197. 1证实 209 . 2完整性2010 有关支持和联接2011 鸣谢：2012 .参考书目：2113 .作者地址2214 .版权讲明22致谢：231绪论这篇文章是为了那些开发irc效劳器的人而做的,但同时对那些以irc 为工

4、具的人也是有用处的.效劳器提供了以?irc：体系?中定义的同时讨论为根底的三项效劳：客户端位置由客户端协议irc客户端定义,信息传递由这篇文章中的效劳器协议 定义,和信道的建设主机与会议协商详细条款请看irc 彳道.2.全球数据库尽管irc协议定义了一些公平的发散式的模式,然而每一个效劳器保持 了一个关于整个irc网络的“全球状态数据库.那个数据库理论上讲对所有效劳器 来讲差不多上独一无二的.2. 1效劳器效劳器能够通过申请一个最长 63个字母的独一无二的名字.查看协议 的语法条款3.3.1来确定那些字母在名字中是能够使用的,那些是不能使用的.每一个效劳器差不多上理论上差不多上被其他效劳器所了

5、解的,然而 有一种可能,定义一个假的主机名字联合其他效劳器使用它的名字.在HOSTMASK的区域里,所有效劳器都有一个和HOSTMASK名字相符的名字,在 HOSTMASK区域外的效劳器, 即使有一个跟HOSTMASK 一样的名字,也不能够登陆到irc中去.而区域外的效劳 器关于区域内的效劳器的状态那么一无所知,相反的,它们被给予一个 HOSTMASK的名字,2. 2客户端关于每一个客户端,所有的效劳器都必须有以下信息：一个网络中专 门的姓名标志它们的形式由客户端来决定,以及一个正在与客户端连接的效劳 器.2. 2. 1用户每一个用户有个专门的最长为9个字母的用户名.查看协议上的语法规那么3.

6、3.1来判定什么是能够使用的,那些不能使用.作为用户名的附加段,每个效劳器都要对用户保留有以下信息：用户正在连接的效劳器名,用户在该效劳器上的用户名,以及效劳器连接的 客户端名.2. 2. 2月艮务每一项效劳都能够通过用户名和效劳器名来区不与其他效劳.用户名最多承诺9个字母.查看协议上的语法规那么3.3.1来判定那些字符能够使用,那 些不行.用来标志服务名称的效劳器名确实是这项效劳连接的效劳器名.作为这项效劳的 补充,所有效劳器必须都了解这种效劳形式.效劳通过它们特有的标志符形式来区不于用户名,然而更多的较重要 的效劳和用户名对效劳器的权限是不同的：效劳能够调用效劳器中保存的局部甚至全部全球数

7、据库中的信息,然而对它们的限制就更加严格详见irc客户端协议同时不承诺 参加信道.最后一点,效劳并不总是服从与防火墙的5.8中有详细表达.2. 3信道就象效劳一样,信道也有它的相应规定irc 彳t道同时没有必要让 所有效劳器了解.当一个信道的存在被一个效劳器所了解,效劳器就一定要记录信 道成员的轨迹和信道模式.3. irc效劳器的讲明3. 1概要那个地点描述的协议是用来给效劳器和效劳器相连接的.关于客户端与效劳器的连接,请看irc客户端协议规那么.然而,关于客户端的连接有比效劳器之间连接更多的规定然而通常 不认为是不可靠的.3. 2特点代码那个地点并没有讲明那些专门的特点代码.协议是以一个由8

8、个字节的代码组成的集合构成的.每一条信息都可能由假设干个这种 8位字节的代码组成.然而, 一些8个字节的代码含义是用来做操纵代码的,就象信息的分割符.不管是什么样的8字节协议,分割符和关键字差不多上协议用来进行 美国ASCII码的终端连接和远程登录连接.由于irc是由北欧方面产生的,某些地区,字母 |八被认为是等 同于小键盘上的 字母.这在确定用户名和信道名是否相同时, 回显现严峻 咨询题.3. 3信息效劳器和客户端发送各自的信息,因此,可能收到回复,也可能没有 回复.大多数效劳器之间的联系不需要回复,由于大多数时候效劳器会为客户端预备好工作进程.每一条irc的信息都由三个要紧局部组成：前缀能

9、够省略,命令, 和命令参数最多15个字符.前缀,命令和所有参数被一个 ASCII码空格0*20 隔开.前缀是以一个ASCII码中的冒号：0*3b来标识的,它必须是信息 的第一个字符.冒号和前缀之间不能够有空格.前缀是效劳器用来标识信息的来 源的.如果信息中的前缀丧失,它就会被默认成是从它刚刚连接并接收到信息的那个效劳器. 客户端自己互相在发送信息时,不应该使用前缀；如果它使用了,唯独有效的前缀确实是 正在使用那个客户端的已经注册过的用户名.当一个效劳器接收信息时,它必须通过前缀来判不信息的来源.如果 在效劳器的中央数据库中找不到前缀,那它一定是被丢弃了,同时如果那个前缀指明的效劳器是一个不知名

10、的效劳器,那么那个信息传来的的连接将被删除.在这种情形下删除连接是有点过分,但是保持网络效劳的严谨与禁止以后可能发生的咨询题却是必要的.另外一种常见的咨询题：前缀指向的信息来源是与实际不同典型情形：来源指向的是另一个连接而不是信息来源.如果信息被效劳器接收,而来源指向客户端,一条删除客户端的信息就会发送到各个效劳器中去.另外一种情形,信息由来的那个连接就应该会在客户端被删除, 同时一定要在效劳器内删除.不管什么情形,这条信息都要被删除.命令一定要是有效的irc命令或者是用ASCII码描述的三位字节.Irc信息通常是以CR-LF 换行和回车为终止的成行的命令,这些信 息的长度不可以超过512个字

11、节,其中包括CR-LF.因此,命令和它的参数最多只 能有510个字节.没有能够用来延长命令行的方法.查看第 5局部能够找到有关当前命令 的执行.3. 3. 1扩展格式的信息有关协议的信息一定要从一系列的 8位字节中提取出来.现在的方法 是标志出两个字符,CR, LF,用来提取信息.空信息通常被默默忽略掉,这就显示出 CR-LF在预防额外咨询题中的作用.有效的信息被分成：假设干局部前缀,命令,和参数表参数.扩展BNF对这方面的表述能够在irc客户端物'议中找到irc-客户 端.附加前缀“！ user “" host决不能够在效劳器之间的连接中使 用,它的使用范畴只有效劳器到客户

12、端的连接,如此,客户端即使不需要额外的疑 咨询而直截了当得到信息的来4. 4数字回复绝大局部发送去效劳器的信息是有一定顺序的.最一般的回复是数字回复,既能够用往返复错误,也能够一般回复.数字回复作为一种信息,一定要包括有前缀,三个阿拉伯数字,和回复的目标对象客户端不承诺发送数字回复,效劳器如果接收到如此的回复,就会自动删除掉.在所有其他关系中,数字回复就象是一个一般的信息,除非它的关键字是用三个阿拉伯数字组成的,而不是字符串.一些另类的数字回复能够在irc客户端协议中找至“irc客户端o4信息细节所有irc的效劳器与客户端认可的信息都在irc-客户端协议中详细介 绍过了.当显现 错误：没有此效

13、劳器时,那就意味着目标信息没有被找到.如 果是命令发生这种错误,效劳器决不能够发送回复.客户端所连接的效劳器要分析整个信息,回复适当的错误.如果效劳 器在分析信息时,遇到一个致命的错误,那么一个错误的回复信息就会被送回,同 时终止分析.致命的错误通常是由错误命令引发的,目标来源关于效劳器来讲可能是未知的效劳器,客户端,信道符合那个类型,也可能是不正确的参数,或者错误的权限.如果全部参数都存在,那么每一个都必须检查它是否能够有效的同时 适宜的送回到客户端.如果信息中使用的参数表是用逗号来做分隔符的,那么就要 发送回复来得到每一条条款.在下面的例子中,有些信息是以完整形式给出的：:姓名命令参数菜单

14、如此的例子是用“姓名来标志信息的,在效劳器间往返的传递,它 的本质是信息的原始发送者的名字,如此,即使远程效劳器也能够找到正确的路径.描述从客户端到效劳器的连接细节的信息在 irc客户端协议中有详 细描述irc 一客户端.下面文章的一些章节确实是对这些文章的应用,它们对那 些只描述效劳器之间连接和信息的执行的信息是个附加.在那个地点介绍的信息差不多上只 用来做效劳器之间连接的.4. 1连线注册那个地点介绍的命令是用来向另外一个irc效劳器连线注册的.4. 1. 1密码信息命令：路径参数： <密码 ><提示信息 ><标志位 >< 选项>PASS路径

15、命令被用来设置一个连接密码.密码一定要在连线注册前设 定.这就意味着在PASS命令一定要在任何效劳器命令之前.只有第一个PASS命 令会被连接认可.如果是从客户端接收到的信息,那么最后的三个参数就会被忽略 e g效劳器的一个用户.只有当它们是从效劳器发送来得时候,它们才相互关联.变量参数至少要有四个字节,最多有十四个字节.开始的四个字节一 定要是阿拉伯数字,简要讲明协议中的变量,确实是已被效劳器获知的那些信息. 这篇文章所描述确实实是2.1.0版本的协议,通常被标志成“ 0210.剩下的可供选择的字母是执 行时所要依靠的,并且需要描述软件的版本号.标志位参数是一个字符串,最长能够包括 100个

16、字符.它是由两个副 串组成的,中间以一个“ |分开x7c.如果是现在,那么这第一个副字符串一 定要是执行的名字.涉及到的执行请看第8局部,当前的支持与可靠性使用irc字符串. 如果要写另外一个执行命令,就需要一个标志符,同时那个标志符应该是在RFC上已注册的.两个副串是可选择的,然而字符“ |是必须的.那个字符不能够显现在任何一个副串 中.最后,最后的参数, 选项,是用来做连接设置的.协议定义过的唯独 选项,连接压缩使用字母“ Z,和一个误差保护位使用字母“ P.参看5.3 1.1 压缩的效劳器与效劳器连接, 自动保护位,分不相对与这些选项 的更多信息.数字回复：错误需要更多参数

17、错误已注册例子：PASS 更多的密码字数 0210010000 irc |abgh$z4. 1. 2效劳器信息命令：效劳器参数：效劳器名期望数值标记信息这条命令是用来注册一个新的效劳器用的,新的连接中,它作为以一 个效劳器的身份向它的同行介绍自己.那个命令也能够用来在整个网络中传递效劳 器的信息.当一个新的效劳器连接到网上,它的有关信息就一定要遍告整个网络.信息参数能够包含空格符期望数值是用来告知效劳器其他效劳器在那儿,距离多远.当地 的效劳器会被赋为0,每通过一个,值就增加.用一个完整的效劳器列表,你能够建 立一个完整的效劳器树型网络图,因此,如果有 HOSTMASK建立的话,这就行不通了.

18、标志参数是效劳器用来做标志的无符号数.那个标志符后来被用 来表示一个服务器,在传递效劳器之间的用户名和效劳信息时.效劳器的标志符只有在点对点的效劳器之间连接时才有效,同时关于那个连接是专门的.并不是全球通用的.效劳器信息只有在连接注册时才被承诺,或者是连接到其他效劳器, 在那种情形下,效劳器信息是介绍一个新效劳器.大多数错误差不多上在效劳器信息返回时发生的,缘故确实是终端服务器中断了连接目标效劳器.由于这种事件的严峻性,错误回复通常是返回“错误命 令,而不是数字回复.如果效劳器信息被分析,同时它试图向一个差不多了解了的效劳器介 绍效劳器时,那么那个连接,从消息收到的那方,就一定要被关闭根据正规

19、的顺序, 由于一条通往那个效劳器的路线差不多形成,同时会破坏差不多形成的 irc树型网络.在 一些情形下,也能够由发送消息的那一方停止信息.必须声明的是：这种错误也可能由于效劳器的第二次启动产生,协议中产生了这种咨询题是不可能修复的,通常需要人类的参与.这种错误是专门阴险的,因为只要irc效劳器中一个被孤立,就会产生这种错误.如果两个效劳器 中的一个被孤立,那么连接就不能连接.数字回复：错误一一已注册举例SERVER test.oulu.fi 1 1 :Experimental server ; New servertest.oulu.fi确实是在介绍效劳器本身,同时试图注册.:tolsun.

20、oulu.fi SERVER 5 34 :BU Central Server ; Servertolsun.oulu.fi 是至U 5 步远的 连接. 当连接至U 时,参数34将被tolsun.oulu.fi调用,来介绍新的用户或效劳.5. 1. 3呢称命令：呢称参数： 呢称 期望值 用户名 主机效劳器token模式 真实姓名这种形式的呢称一定可不能被使用者接收.然而,它能够作为呢称/使用者的替代,来向其他效劳器介绍新的使用者,刚刚参加irc中的.那个信息是由三条不同的信息组合成的：呢称,用户,模式irc 客期望值那个参数是效劳器用

21、来描述使用者距离效劳器主机距离的.本 地的连接期望值是0.每次通过一个效劳器,期望值就增加.效劳器代码那个参数替代了原先的用户中的参数效劳器名.查看4c1.2能够找到更多资料例子：NICK syrk 5 kalt 34 +i :Christophe Kalt新的使用者有那个呢称“syrk,用户名“ kalt,从主机连接到效劳器34 "根据前一个例子.:krys NICK syrk:呢称信息的另外一种形式,就象irc客户端协议中定义的一样.在效劳器之间使用：用户krys把他的名字改为syrk.4. 1. 4效劳信息命令：效劳参数： 效劳名称效劳代码分类类型期望值 信

22、息效劳命令是用来介绍一条新效劳.这种形式的效劳信息不能够被客户 端同意不管有没有注册.然而,它一定要使用于效劳器通告于其他效劳器,有新信息如果irc网络效劳效劳代码是用来鉴不效劳连接到的效劳器.详情请看4.1.2关于服 务器代码期望值参数是被效劳器用来测量,效劳与效劳器之间距离的.当地连 接的期望值是0.每经过一个效劳器,期望值就加一.分类参数被用来指定效劳的明显度.效劳只被有着与分类参数相符的 效劳器了解.由于与之相匹配的效劳器了解了这条效劳,在效劳器与提供效劳的效劳器之间 的路径,一定要能够分解成效劳器名.没有任何限制时,就使用符号'*'.类型参数现在储存下来是为了今后使用

23、.数字回复：ERR_ALREADYREGISTREDERR_NEEDMOREPARAMSERR_ERRONEUSNICKNAMERPL_YOURESERVICERPL_YOURHOSTRPL_MYINFO例子：效劳dirirc.fr 9*.fr 0 1:法文r在效劳器9中注册,在通知其他效劳 器.这条效劳只有效劳器的名字里有fr时才有效.4. 1. 5退出命令：退出参数：客户端的会议通常是以一个退出命令作为终止的.如果客户端发送出退出信息,那么效劳器一定要终止跟客户端的连接.如果退出信息发送出,那个就会被发送出,用来取代默认的信息,通常是用户名或者效劳名.当网络中断详情请看4.1.6发生时,退

24、出信息是由有关的两个服 务器的名字组成的,中间用一个空格分开.第一个名字,是还在连接的那个效劳器的名字,第二个是差不多断开的效劳器名字,或者是那个客户端连接到的效劳器.<Quit Message> = ":" servername SPACE servername由于"quit message对“netsplits来讲有一个专门意义,效劳器不承诺客户端使用“ quitmessage,用上面的形式.如果,由于某些缘故,在还没有任何“ quit message客户端连接被终 止了客户端停止,或者是发生断线,效劳器需要用一些信息来填补退出信息,这些信息 导致

25、了中断的发生.比拟常见的,通常报告系统专门错误.数字回复：例子：:WiZ QUIT :Gone to have lunch ; Preferred messageformat4. 1. 6效劳器退出信息命令：SQUIT参数： 效劳器 注释 它有两种用法：第一详情请看Internet Relay Chat: Client Protocol承诺操作员断开 当地的或者远程的连接.这种形式的信息也是效劳器用来断开连接的最后手段.第二种用法被用来通知其他效劳器,当网络中断发生时.换句话,确 实是告诉其他效劳器有那些效劳器坏了.如果一个效劳器想终止与其他效劳器的连接,它就必 须向其他效劳器发送SQUIT信

26、息,用其他效劳器名做参数,确实是它想关闭连接的哪个.注释通常用来存放那些能够放错误或者是相似信息的效劳器.被断开的两端的效劳器都需要发出一个 SQUIT信息给所有与它们连 接的效劳器,给那些连接背后的效劳器.同样的,QUIT信息可能被发送给其他还连接的效劳器,为了所有连接的客户端.作为补充,这条差不多缺失了一个成员的信道上的所有成员,都必须发送一个退出 信息.信息是由这些成员的效劳器发出的.如果一个效劳器的连接断开了另外一端的效劳器死机了,那么监测 到那个断开的效劳器就需要通知其他网络,连接已断开同时用恰当的文字填充注释.当客户端由于SQUIT被中断,效劳器就要把那个客户端的呢称参加已 断开的

27、名单,预防发生呢称冲突.详情看5.7 跟踪最近使用的呢称.数字回复：ERR_NOPRIVILEGESERR_NOSUCHSERVERERR_NEEDMOREPARAMS例子：SQUIT tolsun.oulu.fi :Bad Link ?;效劳器 tolsun.Oulu.fi 由 于错误连接被中断.:Trillian SQUIT Server out of control ;A trillian 发送出的信息由于效劳器失去操纵而被中断.4. 2信道操作：这组信息和操作信道有关,他们的道具信道模式,同时他们的内容典型用户.在这些道具中,大量的关于信道状态是不可幸

28、免的,专门是当使用者对反对 断开作出连接的时候.同时,它需要效劳器保存一个呢称记录,来确定呢称在那儿使用过,只要资料一更换,效劳器就会检测历史记录.4.1.1 参加信息命令：JOIN参数：<channel> %x7 <modes> * "," <channel> %x7 <modes> JOIN命令是客户端用来参加一个专门信道时使用的.客户端是否被承诺参加,就只由当地的效劳器鉴定产生结果：其他效劳器只是单纯的填加那个用户,当它 们收到这条信息时.通常,用户在信道上的状态信道模式0, o, v能够加在信道名后面,用g分隔开.如果

29、这种信息不是被效劳器接收到,那么这种数据通常是被忽略的.这种格式也不能够发送给客户端,它只能用在效劳器之间传输,同时应该被排除.JOIN命令一定要通知所有效劳器,因此效劳器才明白如何找到信道上 的用户.它承诺理想的PRIVMSG和NOTICE信息在信道上传输.数字回复：ERR_NEEDMOREPARAMSDFROMCHANERR_INVITEONLYCHANANNELKEYERR_CHANNELISFULLHANMASKERR_NOSUCHCHANNELANYCHANNELSERR_TOOMANYTARGETSAILRESOURCERPL_TOPICERR_BANNEERR_BADCHERR_

30、BADCERR_TOOMERR_UNAV:WiZ JOIN #Twilight_zoneWIZ的JOIN信息例子：4. 2. 2N参加信息命令：NJOIN参数：channel <nickname>*( "," "" / "" "+" <nickname> )NJOIN命令只用在效劳器之间.如果同意到这种信息是从客户端发送 的,信息就会被忽略.它要紧用于效劳器之间交换用户及信道信息.尽管如此,同样的函数用JOIN也能够完成,但这条信息能够用来取代 JOIN,同时比它更有效.前缀“说明用户是信道

31、的制造者,符号“ 说明了信道 的操作者,符号“ +说明用户有权发声.数字回复：ERR_NEEDMOREPARAMSERR_NOSUCHCHANNELERR_ALREADYREGISTRED例子： NJOIN #Twilight_zone :WiZ,+syrk,avalon从发送来的NJION信息讲明用户正在参加#Twilight_zon e channel: WiZ 同时表明了信道操作者的状态,syrk有发声权益,而avalon没有.5. 3模式信息MODEL信息是irc中双重意义的命令.它承诺用户名和信道的模式改 变.当解析MODEL信息时,建议先解析完整的信息,然后在进行改变.那个地点需要

32、效劳器来改变信道模式,因此“ channel creator和“ch annel operator'者B能够建立.5.执行细节在写入时,那个协议当前执行确实实是irc效劳器,version 2.1.0. 早期的版本也能够执行这篇文档中介绍的这些命令,但要注意数字回复的位置都改变了.不 幸的是：估量向后兼容,然而这篇文章中的某些操作在老版本中会被认为是不规那么的.一个专 门明显的不同：*信息中显现的LF和CR都标志着这条信息的终止.取代了原先的C RLF文章余下的局部关于那些想要运行效劳器的人来讲相当重要,但当中 的某些局部对效劳器一样适用.5. 1连接失效想要监测什么时候一个连接差不多

33、中断,效劳器一定要检测它的每一 个连接.命令PING 看irc客户端协议能够被使用,如果其他效劳器没有在指定时刻回复信如果一个连接没有及时回复,那么那个连接就会被用适当的程序终止5. 2同意客户端到效劳器的连接6. 2. 1用户如果效劳器成功的注册了一个用户的连接,那么它就需要发送一条关 于用户的明确的状态信息：用户特点,被用来注册的那个RPLWELCOME,效劳器名 字和版本号RPL-HOST,效劳器产生信息RPLCREATED,能够信任的用户 和信道模式RPLMYINFO,同时能够发送任何被认为是合理的信息.专门的,效劳器应该发送当前的用户/效劳/效劳器的值作为每一个L USER的回复,最

34、后加上MOTD 如果有的话,作为 MOTD的回复.注册完成后,效劳器一定要向其他效劳器发送刚刚注册好的用户名NICK信息,以及其他信息USER信息就象它自己的一样,同时象效劳器觉察的那样从DNS效劳器发出.效劳器不能够发送这种信息,成对的 USER和NICK信息就象irc一 - CLIENT中定义的那样,然而一定要用扩展的NICK来替代,就象4.1.3中定义的那 样.5. 2. 2效劳在成功的注册了一个效劳器的连接之后,效劳器关于用户来讲,就象是必须的.效劳那么有些须不同,只有下面的信息被发送：RPL_YOURESERVICE, RPL_YOURHOST, RPL_MYINFO处理完那个,效劳

35、器一定要向其他效劳器发送信息SERVICE信息, 要紧是效劳的名字和其他提供的信息SERVICE信息,还有效劳器能够觉察的从 D NS效劳器.5. 3终结一个效劳器到效劳器的连接终结一个效劳器到效劳器的连接是有危险的,由于这中间可能发生错 误的地点太多了,一一最起码也会有信道状态咨询题.当效劳器接收到一个连接跟随着一个 PASS/SERVER被认为是能够信 任的,效劳器就会回复它自己的PASS/SERVER的信息,作为对那条信息的回复,就象是下 面描述的一样.当开始的效劳器接收到一个PASS/SERVER信息时,在确认那个效劳器 的连接是否可信之前,要先检测那个效劳器的回复是否合理.5. 3.

36、 1连接设置效劳器连接是以一个一般的协议为根底的这篇文章中定义的,然而 关于专门的连接,就会有专门的设置,用PASS信息请看. 3. 1. 1压缩的效劳器到效劳器的连接如果效劳器想中断与其他效劳器之间的连接,它就必须设置Z符号在PASS信息的参数前.如果两个效劳器需要压缩,同时两个效劳器都能够初始化压缩串,那 么剩余的连接都能够被压缩.如果其中一个效劳器不能初始化,那就会发送一个不能初始化 的错误信息给另外一个效劳器,同时切断连接用于压缩的数据形式在IRC 1950 (ZLIP), IRC 1951 (DEFLA TE), IRC 1952(GZIP)中描述的那样.5. 3. 1

37、. 2反对滥用保护大多数效劳器执行各式各样的保护,来反对可能滥用的行为(典型用 户).在一些网络工作中,这些保护是必不可少的,但在其他工作中,那么是余外的.为了所有效劳器都能够执行,同时以如此的形式来完成网络效劳.“P标志位通常在两个效劳器连 接中使用.如果那个标志位现在存在,就讲明效劳器的保护是激活的,同时那个效劳器需 要所有与它相连的效劳器都激活此项.建立一般的保护在5.7中描述(跟踪当前用户的呢称)和 5.8 (客户 端的防火墙).5. 3. 2在连接是改变状态信息在效劳器之间改变状态信息的顺序是必需的.格式如下：* 众所周知的效劳器* 众所周知的客户端信息* 众所周知的信道信息关于效劳

38、器的信息是被额外的效劳器信息发送的,客户端信息包括了 呢称和效劳,信道信息包括NJOIN/MODE信息也一起被发送.注意：信道标题在那个地点不能够被改变,由于标题会覆盖掉所有旧 的标题信息,因此,最起码要效劳器两端一起修改.通过一开始就传输的有关效劳器的状态信息,任何差不多显现的有关效劳器的冲突就会发生,在呢称冲突由于另外的效劳器也有相同的呢称之前.归功于 IRC网络效劳只能够以非循环图的形式表现,因此也有可能网络效劳在其他的地点差不多从新 连接过了.在处理这种事情时,效劳器冲突发生的地点,就以为这网络要分裂了.5. 4中断效劳器与客户端的连接当一个客户端连接出乎意料的中断了,效劳器就会在客户

39、端上产生一个QUIT信息.其他的命令都不用.5. 5中断之间的连接如果效劳器到效劳器之间的连接被中断了,不管是SQUIT或者“NATRUAL缘故,乘U下的IRC网络效劳就一定由检测到中断的那个效劳器来休正.中断的那个就要发送一个SQUIT清单.给那个连接之后的每一个效劳器一个请看. 6跟踪呢称变化所有IRC效劳器都必须储存一份记录,有关呢称改变的.这专门重要, 专门是关于效劳器可以在呢称改变是,用适当的命令来与它们保持联系.跟踪的信息：* KILL 该呢称断线* MODE+/- o,v on channels* KICK 该呢称被从信道上排除了其他命令不需要检查呢称改变.在上述情

40、形中,效劳器要先检测现有的呢称,然后查看历史记录,那 个呢称现在属于谁？这就降低了出错的可能性,然而它依旧会在效劳器终止一个错误的客户 端是发生.当实现一个改变对上述命令的跟踪时,建议限定历史的时刻范畴,太旧的记录能 够被忽略.关于一个合情合理的历史记录,效劳器就应该储存客户端往常的名称, 如果它们想改变名称的话.这种状况会有其他因素制约.例如经历体,等等5. 7跟踪最近使用过的用户名这种体制通常被认为是“ NICK DELAY,它差不多被证实,能够减少 用户名冲突的数量,就是那些要紧由网络分裂和再登陆引起的.保持跟踪呢称的改变,效劳器要随时跟踪最近使用过的用户,同时随 时开释那些被网络分裂和

41、KILL信息加载过的用户名.这些呢称就会变成不可信的,关于效劳 器当地的客户端.并且在一端特定的时刻里不能被使用.呢称不可使用的时刻限制,是受许多因素阻碍的,这些因素大多与IRC网络效劳和一般的网络分裂的时刻有关.关于所有效劳器来讲,这是个规矩.5. 8客户端的溢出操纵由于太多的网络效劳连接IRC效劳器上,关于每一个客户端来讲,提 供连穿的信息是专门容易的,不仅仅是溢出,同时也会降低对其他效劳器效劳的级不.不是 对每个受害人都提供保护,溢出保护被写进效劳器,被应用到客户端,除了效劳.当前采 纳的法那么运确实是如此的："佥查客户端的信息记时器比当前的时刻少设置成相等看看是否相 同.*

42、从客户端读取信息* 如果记时器比当前的少10秒,分析当前信息,然后把每个信息都向 后2秒.* 附加处分可能用来一些专门的信息,能够产生专门多通过网络传输的 输入.5. 9无模块查找在一个真实时刻的环境里,所必须的是,效劳器进程做最少时刻的等待,因此所有客户端服务差不多上平等的.专门明显,这就需要在读 /写操作上执行无模块的IO.关于那些一般的效劳器连接,这并不难,然而还有些其他有关的操作,可能会导致效劳器停 止例如读盘.在那些可能的地点,这种行为可能会导致时刻超标.5. 9. 1主机名查询DNS使用标准的Berkeley伯克利资料库,或者其他的资料库,就意味着在 某些情况中会产生大量的中断,而

43、且会显现回复暂停.为了预防这种情况发生,一个独立的DNS程序被写入了为了当前的执行.程序被安装,连同当地的高速缓冲储藏器一起,就 能够到达无模块化的IO操作,然后就能够被拖进主效劳器IO回路.5. 9. 2用户名IDENT查询尽管有专门多用户名资料库执行见证协定IDENT,能够使用,同 时包含了专门多的其他的程序,这就导致了咨询题的发生,由于它们以相同的方式操作,同时 导致了专门多频繁的延迟.同样,解决方法确实是写一个程序,它能够同其他效劳器连接,同时能够使用NON-BLOCKINGIO.6.当前咨询题那个协议中公认的咨询题就有专门多,所有的咨询题都期待着能在不 久的今后被解决.现在,这项工作

44、差不多在进行中了.6. 1可靠性广泛认同：如果协议在一个专门大的地区使用,那它就不能专门好的 工作.最大的咨询题确实是效劳器需要了解所有其他效劳器和客户端的信息,只要它们一改变,就随 之改变.保持效劳器数量低也是个有效的方法,只要如此,两点之间的距离就可不能太长, 生成的树型网络也就有效的多.7. 2标志当前的IRC协议有四个类型的标志：用户呢称,信道名,效劳器名, 效劳名.每一个都有自己的使用范畴,同时在自己的范畴里,没有复本.当前,如果用户 把其中一个当作另外三个,就会引起冲突.广泛的认同：这项操作需要重新设计,有如此一 个打算：每一个标志有它们自己的专门的名字,就象解决循环树咨询题一样.

45、8. 2. 1呢称IRC中关于呢称的方法关于用户来讲,是专门方便的,专门是在信道 外谈天时.然而,储藏呢称的空间是有限的,同时一直存在,几个人用一个名字是不能够的 如果两个人选了一个名字,那么其中的一个,或者两个人一起,会被 KILL命令删除.详 情请看3.7.1IRC客户端协议IRC客户端9. 2. 2信道当前的信道规那么：所有效劳器都要明白所有信道,它们的位置和特性.由于执行不是专门好,不被干扰的情况依旧需要担忧的.信道冲突被看作是集体冲突信道上两个网中的人有着一样的名字被认为是信道中的成员,而不是象呢称冲突一样的单一事 件.协议定义了 "平安信道",这种信道不太可能发

46、生信道冲突.其他信道模 式储存下来为了向后的兼容性.10. 3运算法那么效劳器代码中的某些地点,不能够不用 N2如此的法那么,由于要检测 信道上的客户端.在当前效劳器的版本中,只有少数数据库包含了检测方法,现在大多 数效劳器,每一个都只能假想周边的效劳器是正确的.这就为大量咨询题翻开了大门,如果 一个连接中效劳器有咨询题,或者它正向网络中散发病毒.当前,由于缺少独一无二的中央处理器和全球范畴的标志,多种多样 的咨询题都差不多显现.这种情形大多是由咨询题引发的,由于它们需要时刻来传播信息,同时 作用于网络.即使把它们更换成独一无二的标志,也依旧会产生咨询题,使信道连接中断.7.平安考虑7. 1证

47、实效劳器通常只有两种方法来鉴不参加的连接：检测密码和DNS查找.尽管这种方法是脆弱的同时被公认为不够平安,它们的合并差不多在过去被证实了：*公共的网络只需要对用户进行专门少的限制和约定,不需要专门严格 的测试.*在操纵环境下的私人网络,经常使用 HOME-GROWN鉴定装置,然 而在INTERNET上是不可信的：只有在某些效劳器上IDENT,或者其他私有的效劳器上才 是可用的.同样的果断应用与IRC操作员的鉴定.同样也会注意：确实是那儿有专门多年不需要更强的鉴定,不需要更 大的努力提供更好的鉴不用户,当前的协议提供了足够的额外的鉴不方法,以客户端信息为根底, 同时服从于效劳器连接,：效劳器名,

48、用户名,密码.11. 2完整性路径和操作信息被发送进空白的文档,串层加密装置,象TLS协议, 能够用来保护这些操作.12. 关支持和联接IRC 有关讨论：主论区：ircd_协议开发：ircd_软件操作：/irc/serverftp:/ftp.funet.fi/pub/unix/irc.au/pub/irc新闻组：alt.irc13. 谢：这篇文章局部是从RFC-1459IRC,是第一次正式的公布IRC协议.它中意于专门多的观点和内容.专门是下面的对本书作出极大奉献：Matthew

49、Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Ve saRuokonen, Magnus Tjernstrom, Stefan Zehl.14. 参考书目：KEYWORDS Bradner, S., "Key words for use in RFCs to In dicateRequirement Levels", BCP 14, RFC 2119, March 1997.ABNF Crocker, D. and P. Overell, "Augmented BNF for SyntaxSpecifi

50、cations: ABNF", RFC 2234, November 1997.IRCOikarinen, J. and D. Reed, "Internet Relay ChatProtocol", 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", R FC2812

51、, April 2000.IRC-CHAN Kalt, C., "Internet Relay Chat: Channel Managem ent", RFC2811, April 2000.ZLIBDeutsch, P. and J-L. Gailly, "ZLIB Compressed DataFormat Specification version 3.3", RFC 1950, May 1996.DEFLATE Deutsch, P., "DEFLATE Compressed Data FormatSpecification version 1.3", RFC 1951, May 1996.GZIP Deutsch, P., "GZIP file format specification version4.3", RFC 1952, May 1996.IDENTSt. Johns, M., "The Identification Protocol", RFC1413,Febr