组织：中国互动出版网（http://www.china-pub.com/）<br />
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）<br />
E-mail：ouyang@china-pub.com<br />
译者：（）<br />
译文发布时间：2001-12-28<br />
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须<br />
保留本文档的翻译及版权信息。<br />
<br />
<br />
<br />
<br />
Network&nbsp;Working&nbsp;Group&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;C.&nbsp;Kalt<br />
Request&nbsp;for&nbsp;Comments:&nbsp;2813&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;April&nbsp;2000<br />
Updates:&nbsp;1459<br />
Category:&nbsp;Informational<br />
<br />
<br />
Internet&nbsp;交换交谈：服务器协议<br />
(RFC2813——Internet&nbsp;Relay&nbsp;Chat:&nbsp;Server&nbsp;Protocol)<br />
<br />
备忘录的状态：<br />
这个备忘录提供了internet群体的信息。它并没有详细说明每一种internet的标准。这个备<br />
忘录的适用范围是无拘束的。<br />
版权通告：<br />
copyright（c）internet&nbsp;Society&nbsp;(2000).&nbsp;&nbsp;All&nbsp;Rights&nbsp;Reserved.<br />
摘要：<br />
以客户端——服务器为模板，irc协议允许服务器连接到另外的有效形成的网络。<br />
本文档定义了服务器用于互相交流的协议。它原来只是一个客户端协议的超集，但是已经发<br />
展的不同了。<br />
正式的出版是在1993年5月作为rfc的一部分。从那时以来，大多数的为了使协议更加标<br />
准的改变都可以在这篇文章中找到。更加标准的协议已经允许出现在万维网中，以使它可以<br />
保持不断的更新，并且有别于原来的版本。<br />
<br />
目录<br />
1绪论	2<br />
2．全球数据库	3<br />
2．1服务器	3<br />
2．2客户端	3<br />
2．3信道	4<br />
3．irc服务器的说明	4<br />
3．1概要	4<br />
3．2&nbsp;特征代码	4<br />
3．3信息	5<br />
3．4数字回复	6<br />
4信息细节	6<br />
4．1连线注册	7<br />
4．2信道操作：	11<br />
4．3模式信息	13<br />
5．执行细节	13<br />
5．1连接失效	13<br />
5．2接受客户端到服务器的连接	13<br />
5．3终结一个服务器到服务器的连接	14<br />
5．4中断服务器与客户端的连接	16<br />
5．5中断之间的连接	16<br />
5．6跟踪呢称变化	16<br />
5．7跟踪最近使用过的用户名	17<br />
5．8客户端的溢出控制	17<br />
5．9无模块查找	17<br />
6．当前问题	18<br />
6．1可靠性	18<br />
6．2标志	18<br />
6．3运算法则	19<br />
7．安全考虑	19<br />
7．1证明	20<br />
7．2完整性	20<br />
8．相关支持和联接	20<br />
9.鸣谢：	20<br />
10．参考书目：	21<br />
11．作者地址	22<br />
12．版权说明	22<br />
致谢：	23<br />
<br />
1绪论<br />
<br />
这篇文章是为了那些开发irc服务器的人而做的，但同时对那些以irc为工具的人也<br />
是有用处的。<br />
<br />
服务器提供了以《irc：体系》中定义的同时讨论为基础的三项服务：客户端位置（由<br />
客户端协议[irc客户端]定义），信息传递（由这篇文章中的服务器协议定义），和信道的建设<br />
主机与会议协商（详细条款请看[irc——信道]）。<br />
<br />
2．全球数据库<br />
<br />
尽管irc协议定义了一些公平的发散式的模式，但是每一个服务器保持了一个关于整<br />
个irc网络的“全球状态数据库”。这个数据库理论上说对所有服务器来说都是独一无二的。<br />
<br />
2．1服务器<br />
<br />
服务器可以通过申请一个最长63个字母的独一无二的名字。查看协议的语法条款[3。<br />
3。1]来确定那些字母在名字中是可以使用的，那些是不能使用的。<br />
<br />
每一个服务器都是理论上都是被其他服务器所了解的，但是有一种可能，定义一个<br />
假的主机名字联合其他服务器使用它的名字。在HOSTMASK的区域里，所有服务器都有一<br />
个和HOSTMASK名字相符的名字，在HOSTMASK区域外的服务器，即使有一个跟<br />
HOSTMASK一样的名字，也不可以登陆到irc中去。而区域外的服务器对于区域内的服务<br />
器的状态则一无所知，相反的，它们被赋予一个HOSTMASK的名字。<br />
<br />
2．2客户端<br />
<br />
对于每一个客户端，所有的服务器都必须有以下信息：一个网络中独特的姓名标志<br />
（它们的形式由客户端来决定），以及一个正在与客户端连接的服务器。<br />
<br />
2．2．1用户<br />
<br />
每一个用户有个独特的最长为9个字母的用户名。查看协议上的语法规则[3。3。1]<br />
来判断什么是能够使用的，那些不能使用。作为用户名的附加段，每个服务器都要对用户保<br />
留有以下信息：用户正在连接的服务器名，用户在该服务器上的用户名，以及服务器连接的<br />
客户端名。<br />
<br />
2．2．2服务<br />
<br />
每一项服务都可以通过用户名和服务器名来区别与其他服务。用户名最多允许9个<br />
字母。查看协议上的语法规则[3。3。1]来判断那些字符可以使用，那些不行。用来标志服<br />
务名称的服务器名就是这项服务连接的服务器名。作为这项服务的补充，所有服务器必须都<br />
了解这种服务形式。<br />
<br />
服务通过它们特有的标志符形式来区别于用户名，但是更多的较重要的服务和用户<br />
名对服务器的权限是不同的：服务可以调用服务器中保留的部分甚至全部全球数据库中的信<br />
息，但是对它们的限制就更加严格（详见irc客户端协议）并且不允许加入信道。最后一点，<br />
服务并不总是服从与防火墙的5。8中有详细叙述。<br />
<br />
2．3信道<br />
<br />
就象服务一样，信道也有它的相应规定[irc&nbsp;——信道]并且没有必要让所有服务器了<br />
解。当一个信道的存在被一个服务器所了解，服务器就一定要记录信道成员的轨迹和信道模<br />
式。<br />
<br />
3．irc服务器的说明<br />
<br />
3．1概要<br />
<br />
这里描述的协议是用来给服务器和服务器相连接的。关于客户端与服务器的连接，<br />
请看irc——客户端协议规则。<br />
<br />
但是，对于客户端的连接有比服务器之间连接更多的规定（但是通常别认为是不可<br />
靠的）。<br />
<br />
3．2&nbsp;特征代码<br />
<br />
这里并没有说明那些特殊的特征代码。协议是以一个由8个字节的代码组成的集合<br />
构成的。每一条信息都可能由若干个这种8位字节的代码组成。但是，一些8个字节的代码<br />
含义是用来做控制代码的，就象信息的分割符。<br />
<br />
不管是什么样的8字节协议，分割符和关键字都是协议用来进行美国——ASCII码<br />
的终端连接和远程登录连接。<br />
<br />
因为irc是由北欧方面产生的，某些地区，字母{&nbsp;&nbsp;}&nbsp;&nbsp;|&nbsp;&nbsp;^被认为是等同于小键盘上<br />
的{&nbsp;&nbsp;}&nbsp;&nbsp;\&nbsp;&nbsp;~字母。这在确定用户名和信道名是否相同时，回出现严重问题。<br />
<br />
3．3信息<br />
<br />
服务器和客户端发送各自的信息，当然，可能收到回复，也可能没有回复。大多数<br />
服务器之间的联系不需要回复，因为大多数时候服务器会为客户端准备好工作进程。<br />
<br />
每一条irc的信息都由三个主要部分组成：前缀（可以省略），命令，和命令参数（最<br />
多15个字符）。前缀，命令和所有参数被一个ASCII码空格（0*20）隔开。<br />
<br />
前缀是以一个ASCII码中的冒号（：&nbsp;0*3b）来标识的，它必须是信息的第一个字<br />
符。冒号和前缀之间不可以有空格。前缀是服务器用来标识信息的来源的。如果信息中的前<br />
缀丢失，它就会被默认成是从它刚刚连接并接收到信息的那个服务器。客户端自己互相在发<br />
送信息时，不应该使用前缀；如果它使用了，唯一有效的前缀就是正在使用这个客户端的已<br />
经注册过的用户名。<br />
<br />
当一个服务器接收信息时，它必须通过前缀来判别信息的来源。如果在服务器的中<br />
央数据库中找不到前缀，那它一定是被丢弃了，并且如果这个前缀指明的服务器是一个不知<br />
名的服务器，那么这个信息传来的的连接将被删除。在这种情况下删除连接是有点过分，但<br />
是保持网络服务的严谨与制止未来可能发生的问题却是必要的。另外一种常见的问题：前缀<br />
指向的信息来源是与实际不同（典型情况：来源指向的是另一个连接而不是信息来源。）如<br />
果信息被服务器接收，而来源指向客户端，一条删除客户端的信息就会发送到各个服务器中<br />
去。另外一种情况，信息由来的那个连接就应该会在客户端被删除，并且一定要在服务器内<br />
删除。不管什么情况，这条信息都要被删除。<br />
<br />
命令一定要是有效的irc命令或者是用ASCII码描述的三位字节。<br />
<br />
Irc信息通常是以CR-LF（换行和回车）为结束的成行的命令，这些信息的长度不可<br />
以超过512个字节，其中包括CR-LF。因此，命令和它的参数最多只能有510个字节。没<br />
有可以用来延长命令行的方法。查看第5部分可以找到有关当前命令的执行。<br />
<br />
3．3．1扩展格式的信息<br />
<br />
有关协议的信息一定要从一系列的8位字节中提取出来。现在的办法是标志出两个<br />
字符，CR，LF，用来提取信息。空信息通常被默默忽略掉,这就显示出CR-LF在预防额外<br />
问题中的作用。<br />
<br />
有效的信息被分成：若干部分（前缀），（命令），和参数表（参数）。<br />
<br />
扩展BNF对这方面的表述可以在irc——客户端协议中找到[irc--客户端]。<br />
<br />
附加前缀（[“！”user“@”host]）决不可以在服务器之间的连接中使用，它的使用<br />
范围只有服务器到客户端的连接，这样，客户端即使不需要额外的疑问而直接得到信息的来<br />
源。<br />
<br />
3．4数字回复<br />
<br />
绝大部分发送去服务器的信息是有一定顺序的。最普通的回复是数字回复，既可以<br />
用来回复错误，也可以普通回复。数字回复作为一种信息，一定要包括有前缀，三个阿拉伯<br />
数字，和回复的目标对象客户端不允许发送数字回复，服务器如果接收到这样的回复，就会<br />
自动删除掉。在所有其他关系中，数字回复就象是一个普通的信息，除非它的关键字是用三<br />
个阿拉伯数字组成的，而不是字符串。一些另类的数字回复可以在irc——客户端协议中找<br />
到[irc——客户端]。<br />
<br />
4信息细节<br />
<br />
所有irc的服务器与客户端认可的信息都在irc---客户端协议中详细介绍过了。<br />
<br />
当出现&nbsp;错误：没有此服务器时，那就意味着目标信息没有被找到。如果是命令发<br />
生这种错误，服务器决不可以发送回复。<br />
<br />
客户端所连接的服务器要分析整个信息，回复适当的错误。如果服务器在分析信息<br />
时，遇到一个致命的错误，那么一个错误的回复信息就会被送回，并且终止分析。致命的错<br />
误通常是由错误命令引发的，目标来源对于服务器来说可能是未知的（服务器，客户端，信<br />
道符合这个类型），也可能是不正确的参数，或者错误的权限。<br />
<br />
如果全部参数都存在，那么每一个都必须检查它是否能够有效的并且合适的送回到<br />
客户端。如果信息中使用的参数表是用逗号来做分隔符的，那么就要发送回复来得到每一条<br />
条款。<br />
<br />
在下面的例子中，有些信息是以完整形式给出的：<br />
<br />
：姓名&nbsp;命令参数菜单<br />
<br />
这样的例子是用“姓名”来标志信息的，在服务器间来回的传递，它的本质是信息<br />
的原始发送者的名字，这样，即使远程服务器也可以找到正确的路径。<br />
<br />
描述从客户端到服务器的连接细节的信息在irc——客户端协议中有详细描述[irc—<br />
—客户端]。下面文章的一些章节就是对这些文章的应用，它们对那些只描述服务器之间连<br />
接和信息的执行的信息是个附加。在这里介绍的信息都是只用来做服务器之间连接的。<br />
<br />
4．1连线注册<br />
<br />
这里介绍的命令是用来向另外一个irc服务器连线注册的。<br />
<br />
4．1．1密码信息<br />
<br />
命令：路径<br />
参数：&lt;密码&gt;&lt;提示信息&gt;&lt;标志位&gt;[&lt;选项&gt;]<br />
<br />
PASS路径命令被用来设置一个连接密码。密码一定要在连线注册前设定。这就意<br />
味着在PASS命令一定要在任何服务器命令之前。只有第一个PASS命令会被连接认可。<br />
<br />
如果是从客户端接收到的信息，那么最后的三个参数就会被忽略（e。g服务器的一<br />
个用户）。只有当它们是从服务器发送来得时候，它们才相互关联。<br />
<br />
变量参数至少要有四个字节，最多有十四个字节。开始的四个字节一定要是阿拉伯<br />
数字，简要说明协议中的变量，就是已被服务器获知的那些信息。这篇文章所描述的就是2。<br />
1。0版本的协议，通常被标志成“0210”。剩下的可供选择的字母是执行时所要依靠的，并<br />
且需要描述软件的版本号。<br />
<br />
标志位参数是一个字符串，最长可以包括100个字符。它是由两个副串组成的，中<br />
间以一个“|”分开（%x7c）。如果是现在，那么这第一个副字符串一定要是执行的名字。涉<br />
及到的执行（请看第8部分，当前的支持与可靠性）使用irc字符串。如果要写另外一个执<br />
行命令，就需要一个标志符，并且这个标志符应该是在RFC上已注册的。两个副串是可选<br />
择的，但是字符“|”是必须的。这个字符不可以出现在任何一个副串中。<br />
<br />
最后，最后的参数，&lt;选项&gt;,是用来做连接设置的。协议定义过的唯一选项，连接压<br />
缩（使用字母“Z”），和一个误差保护位（使用字母“P”）。参看5。3。1。1（压缩的服务<br />
器与服务器连接），5。3。1。2（自动保护位），分别相对与这些选项的更多信息。<br />
<br />
数字回复：<br />
&nbsp;<br />
错误&nbsp;需要更多参数&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;错误&nbsp;已注册<br />
<br />
例子：<br />
<br />
PASS&nbsp;更多的密码字数&nbsp;&nbsp;0210010000&nbsp;&nbsp;irc&nbsp;|abgh$z<br />
<br />
4．1．2服务器信息<br />
<br />
命令：服务器<br />
参数：〈服务器名〉〈希望数值〉〈标记〉〈信息〉<br />
<br />
这条命令是用来注册一个新的服务器用的，新的连接中，它作为以一个服务器的身<br />
份向它的同行介绍自己。这个命令也可以用来在整个网络中传递服务器的信息。当一个新的<br />
服务器连接到网上，它的相关信息就一定要遍告整个网络。<br />
<br />
〈信息〉参数可以包含空格符。<br />
<br />
〈希望数值〉是用来告知服务器其他服务器在那里，距离多远。当地的服务器会被<br />
赋为0，每经过一个，值就增加。用一个完整的服务器列表，你可以建立一个完整的服务器<br />
树型网络图，当然，如果有HOSTMASK建立的话，这就行不通了。<br />
<br />
〈标志〉参数是服务器用来做标志的无符号数。这个标志符后来被用来表示一个服<br />
务器，在传递服务器之间的用户名和服务信息时。服务器的标志符只有在点对点的服务器之<br />
间连接时才有效，并且对于那个连接是独特的。并不是全球通用的。<br />
<br />
服务器信息只有在连接注册时才被允许，或者是连接到其他服务器，在那种情况下，<br />
服务器信息是介绍一个新服务器。<br />
<br />
大多数错误都是在服务器信息返回时发生的，原因就是终端服务器中断了连接（目<br />
标服务器）。由于这种事件的严重性，错误回复通常是返回“错误”命令，而不是数字回复。<br />
<br />
如果服务器信息被分析，并且它试图向一个已经了解了的服务器介绍服务器时，那<br />
么这个连接，从消息收到的那方，就一定要被关闭（按照正规的顺序）。因为一条通往那个<br />
服务器的路线已经形成，并且会破坏已经形成的irc树型网络。在一些情况下，也可以由发<br />
送消息的那一方停止信息。必须声明的是：这种错误也可能由于服务器的第二次启动产生，<br />
协议中产生了这种问题是不可能修复的，通常需要人类的参与。这种错误是非常阴险的，因<br />
为只要irc服务器中一个被孤立，就会产生这种错误。如果两个服务器中的一个被孤立，那<br />
么连接就不能连接。<br />
<br />
数字回复：<br />
<br />
错误——已注册<br />
<br />
举例<br />
SERVER&nbsp;test.oulu.fi&nbsp;1&nbsp;1&nbsp;:Experimental&nbsp;server&nbsp;;&nbsp;New&nbsp;server<br />
test.oulu.fi就是在介绍服务器本身，并且试图注册。<br />
:tolsun.oulu.fi&nbsp;SERVER&nbsp;csd.bu.edu&nbsp;5&nbsp;34&nbsp;:BU&nbsp;Central&nbsp;Server&nbsp;;&nbsp;Server<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;tolsun.oulu.fi是到5步远的csd.bu.edu连接。当连接到csd.bu.edu<br />
时，参数34将被tolsun.oulu.fi调用，来介绍新的用户或服务。<br />
<br />
4．1．3呢称<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;命令：呢称<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;参数：&lt;呢称&gt;&lt;希望值&gt;&lt;用户名&gt;&lt;主机&gt;&lt;服务器token&gt;&lt;模式&gt;&lt;真实姓名&gt;<br />
<br />
这种形式的呢称一定不会被使用者接收。但是，它可以作为呢称/使用者的替代，来<br />
向其他服务器介绍新的使用者，刚刚加入irc中的。<br />
<br />
这个信息是由三条不同的信息组合成的：呢称，用户，模式[irc——客户]。<br />
<br />
希望值这个参数是服务器用来描述使用者距离服务器主机距离的。本地的连接希望值<br />
是0。每次通过一个服务器，希望值就增加。<br />
<br />
服务器代码这个参数替代了原来的用户中的参数服务器名。（查看4。1。2可以找到<br />
更多资料）<br />
<br />
&nbsp;&nbsp;例子：<br />
&nbsp;&nbsp;NICK&nbsp;syrk&nbsp;5&nbsp;kalt&nbsp;millennium.stealth.net&nbsp;34&nbsp;+i&nbsp;:Christophe&nbsp;Kalt<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;新的使用者有这个呢称“syrk”，用户名“kalt”，<br />
从主机millennium.stealth.net连接到服务器&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
34&nbsp;("csd.bu.edu"&nbsp;根据前一个例子).<br />
<br />
：krys&nbsp;NICK&nbsp;syrk&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;：呢称信息的另外一种形式，就象irc客户端协<br />
议中定义的一样。在服务器之间使用：用户<br />
krys把他的名字改为syrk。<br />
<br />
4．1．4服务信息<br />
&nbsp;<br />
命令：服务<br />
参数：&lt;服务名称&gt;&lt;服务代码&gt;&lt;分类&gt;&lt;类型&gt;&lt;希望值&gt;〈信息〉<br />
<br />
服务命令是用来介绍一条新服务。这种形式的服务信息不可以被客户端接受（不管有没有注<br />
册）。但是，它一定要使用于服务器通告于其他服务器，有新信息假如irc网络服务。<br />
<br />
服务代码是用来鉴别服务连接到的服务器。（详情请看4。1。2关于服务器代码）<br />
<br />
希望值参数是被服务器用来测量，服务与服务器之间距离的。当地连接的希望值是0。每经<br />
过一个服务器，希望值就加一。<br />
<br />
分类参数被用来指定服务的明显度。服务只被有着与分类参数相符的服务器了解。因为与之<br />
相匹配的服务器了解了这条服务，在服务器与提供服务的服务器之间的路径，一定要可以分<br />
解成服务器名。没有任何限制时，就使用符号‘*’。<br />
<br />
类型参数现在保存下来是为了将来使用。<br />
<br />
数字回复：ERR_ALREADYREGISTRED&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ERR_NEEDMOREPARAMS<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ERR_ERRONEUSNICKNAME<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;RPL_YOURESERVICE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;RPL_YOURHOST<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;RPL_MYINFO<br />
例子：<br />
服务&nbsp;dir@irc.fr&nbsp;9*.fr&nbsp;0&nbsp;1:法文r在服务器9中注册，在通知其他服务器。这条服务只有服务<br />
器的名字里有fr时才有效。<br />
<br />
4．1．5退出<br />
命令：退出<br />
参数：<br />
<br />
客户端的会议通常是以一个退出命令作为结束的。如果客户端发送出退出信息，那么服务器<br />
一定要终止跟客户端的连接。如果退出信息发送出，这个就会被发送出，用来取代默认的信<br />
息，通常是用户名或者服务名。<br />
<br />
当网络中断（详情请看4。1。6）发生时，退出信息是由相关的两个服务器的名字组成的，<br />
中间用一个空格分开。第一个名字，是还在连接的那个服务器的名字，第二个是已经断开的<br />
服务器名字，或者是那个客户端连接到的服务器。<br />
&lt;Quit&nbsp;Message&gt;&nbsp;=&nbsp;&nbsp;":"&nbsp;servername&nbsp;SPACE&nbsp;servername<br />
<br />
由于"quit&nbsp;message"对“netsplits”来说有一个特殊意义，服务器不允许客户端使用“quit&nbsp;<br />
message”，用上面的形式。<br />
<br />
如果，由于某些原因，在还没有任何“quit&nbsp;message”客户端连接被终止了（客户端停止，<br />
或者是发生断线），服务器需要用一些信息来填补退出信息，这些信息导致了中断的发生。<br />
比较常见的，通常报告系统特殊错误。<br />
<br />
数字回复：<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;无。<br />
<br />
例子：:WiZ&nbsp;QUIT&nbsp;:Gone&nbsp;to&nbsp;have&nbsp;lunch&nbsp;&nbsp;&nbsp;;&nbsp;Preferred&nbsp;message&nbsp;format<br />
<br />
4．1．6服务器退出信息<br />
<br />
命令：SQUIT<br />
参数：&lt;服务器&gt;&lt;注释&gt;<br />
它有两种用法：：<br />
<br />
第一（详情请看Internet&nbsp;Relay&nbsp;Chat:&nbsp;Client&nbsp;Protocol）允许操作员断开当地的或者远程的连接。<br />
这种形式的信息也是服务器用来断开连接的最后手段。<br />
<br />
第二种用法被用来通知其他服务器，当网络中断发生时。换句话，就是告诉其他服务器有那<br />
些服务器坏了。如果一个服务器想终止与其他服务器的连接，它就必须向其他服务器发送<br />
SQUIT信息，用其他服务器名做参数，就是它想关闭连接的哪个。<br />
<br />
注释通常用来存放那些可以放错误或者是相似信息的服务器。<br />
<br />
被断开的两端的服务器都需要发出一个SQUIT信息（给所有与它们连接的服务器），给那些<br />
连接背后的服务器。<br />
<br />
同样的，QUIT信息可能被发送给其他还连接的服务器，为了所有连接的客户端。作为补充，<br />
这条已经损失了一个成员的信道上的所有成员,都必须发送一个退出信息。信息是由这些成<br />
员的服务器发出的。<br />
<br />
如果一个服务器的连接断开了（另外一端的服务器死机了），那么监测到这个断开的服务器<br />
就需要通知其他网络，连接已断开并且用恰当的文字填充注释。<br />
<br />
当客户端由于SQUIT被中断，服务器就要把这个客户端的呢称加入已断开的名单，防止发<br />
生呢称冲突。详情看5。7（跟踪最近使用的呢称）。<br />
<br />
数字回复：<br />
ERR_NOPRIVILEGES&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ERR_NOSUCHSERVER<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ERR_NEEDMOREPARAMS<br />
例子：SQUIT&nbsp;tolsun.oulu.fi&nbsp;:Bad&nbsp;Link&nbsp;?&nbsp;&nbsp;;服务器tolsun。Oulu。fi由于错误连接被中断。<br />
:Trillian&nbsp;SQUIT&nbsp;cm22.eng.umd.edu：Server&nbsp;out&nbsp;of&nbsp;control&nbsp;;从trillian发送出的信息由于<br />
服务器失去控制而被中断。<br />
<br />
4．2信道操作：<br />
<br />
这组信息和操作信道有关，他们的道具（信道模式），并且他们的内容（典型用户）。在这些<br />
道具中，大量的关于信道状态是不可避免的，尤其是当使用者对反对断开作出连接的时候。<br />
同时，它需要服务器保留一个呢称记录，来确定呢称在那里使用过，只要资料一更改，服务<br />
器就会检测历史记录。<br />
<br />
4．2．1加入信息<br />
命令：JOIN<br />
参数：&lt;channel&gt;[&nbsp;%x7&nbsp;&lt;modes&gt;&nbsp;]<br />
*(&nbsp;","&nbsp;&lt;channel&gt;[&nbsp;%x7&nbsp;&lt;modes&gt;&nbsp;]&nbsp;)<br />
JOIN命令是客户端用来加入一个特殊信道时使用的。客户端是否被允许加入，就只由当地<br />
的服务器鉴定产生结果：其他服务器只是单纯的填加这个用户，当它们收到这条信息时。<br />
<br />
通常，用户在信道上的状态（信道模式0，o，v）可以加在信道名后面，用g分隔开。如果<br />
这种信息不是被服务器接收到，那么这种数据通常是被忽略的。这种格式也不可以发送给客<br />
户端，它只能用在服务器之间传输，并且应该被消除。<br />
<br />
JOIN命令一定要通知所有服务器，因此服务器才知道如何找到信道上的用户。它允许理想<br />
的PRIVMSG和NOTICE信息在信道上传输。<br />
<br />
数字回复：&nbsp;ERR_NEEDMOREPARAMS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ERR_BANNEDFROMCHAN<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ERR_INVITEONLYCHAN&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ERR_BADCHANNELKEY<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ERR_CHANNELISFULL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ERR_BADCHANMASK<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ERR_NOSUCHCHANNEL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ERR_TOOMANYCHANNELS<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ERR_TOOMANYTARGETS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ERR_UNAVAILRESOURCE<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;RPL_TOPIC<br />
例子：<br />
&nbsp;&nbsp;&nbsp;:WiZ&nbsp;JOIN&nbsp;#Twilight_zone&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;WIZ的JOIN&nbsp;信息<br />
<br />
4．2．2N加入信息<br />
命令：NJOIN<br />
参数：&lt;channel&nbsp;&lt;nickname&gt;<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*(&nbsp;","&nbsp;[&nbsp;"@@"&nbsp;/&nbsp;"@"&nbsp;]&nbsp;[&nbsp;"+"&nbsp;]&nbsp;&lt;nickname&gt;&nbsp;)<br />
<br />
NJOIN命令只用在服务器之间。如果接受到这种信息是从客户端发送的，信息就会被忽略。<br />
它主要用于服务器之间交换用户及信道信息。<br />
<br />
尽管如此，同样的函数用JOIN也可以完成，但这条信息可以用来取代JOIN，并且比它更<br />
有效。前缀“@@”表明用户是信道的创造者，符号“@”表明了信道的操作者，符号“+”<br />
表明用户有权发声。<br />
<br />
数字回复：ERR_NEEDMOREPARAMS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ERR_NOSUCHCHANNEL<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ERR_ALREADYREGISTRED<br />
例子：:ircd.stealth.net&nbsp;NJOIN&nbsp;#Twilight_zone&nbsp;:@WiZ,+syrk,avalon<br />
从ircd.stealth.net发送来的NJION信息说明用户正在加入#Twilight_zone&nbsp;channel:&nbsp;WiZ并且表<br />
明了信道操作者的状态，syrk有发声权利，而avalon没有。<br />
<br />
4．3模式信息<br />
MODEL信息是irc中双重意义的命令。它允许用户名和信道的模式改变。<br />
<br />
当解析MODEL信息时，建议先解析完整的信息，然后在进行改变。<br />
<br />
这里需要服务器来改变信道模式，所以“channel&nbsp;creator”和“channel&nbsp;operator”都可以建立。<br />
<br />
5．执行细节<br />
<br />
在写入时，这个协议当前执行的就是irc服务器，version&nbsp;2。1。0。早期的版本也可以执行<br />
这篇文档中介绍的这些命令，但要注意数字回复的位置都改变了。不幸的是：预计向后兼容，<br />
但是这篇文章中的某些操作在老版本中会被认为是不规则的。一个很明显的不同：<br />
*信息中出现的LF和CR都标志着这条信息的结束。（取代了原来的CRLF）<br />
<br />
文章余下的部分对于那些想要运行服务器的人来说相当重要，但当中的某些部分对服务器一<br />
样适用。<br />
<br />
5．1连接失效<br />
<br />
想要监测什么时候一个连接已经中断，服务器一定要检测它的每一个连接。命令PING（看<br />
irc客户端协议）可以被使用，如果其他服务器没有在指定时间回复信息。<br />
<br />
如果一个连接没有及时回复，那么这个连接就会被用适当的程序终止。<br />
<br />
5．2接受客户端到服务器的连接<br />
<br />
5．2．1用户<br />
<br />
如果服务器成功的注册了一个用户的连接，那么它就需要发送一条关于用户的明确的状态信<br />
息：用户特征，被用来注册的那个（RPL——WELCOME），服务器名字和版本号（RPL—<br />
—HOST），服务器产生信息（RPL——CREATED），可以信赖的用户和信道模式（RPL——<br />
MYINFO），并且可以发送任何被认为是合理的信息。<br />
<br />
特别的，服务器应该发送当前的用户/服务/服务器的值（作为每一个LUSER的回复），最后<br />
加上MOTD（如果有的话，作为MOTD的回复）。<br />
<br />
注册完成后，服务器一定要向其他服务器发送刚刚注册好的用户名（NICK&nbsp;信息），以及其<br />
他信息（USER&nbsp;信息）就象它自己的一样，并且象服务器发现的那样（从DNS服务器发出）。<br />
服务器不可以发送这种信息，成对的USER和NICK信息（就象irc——CLIENT中定义的<br />
那样），但是一定要用扩展的NICK来替代，就象4。1。3中定义的那样。<br />
<br />
5．2．2服务<br />
<br />
在成功的注册了一个服务器的连接之后，服务器对于用户来说，就象是必须的。服务则有些<br />
须不同，只有下面的信息被发送：<br />
RPL_YOURESERVICE,&nbsp;RPL_YOURHOST,&nbsp;RPL_MYINFO<br />
<br />
处理完这个，服务器一定要向其他服务器发送信息（SERVICE&nbsp;信息），主要是服务的名字<br />
和其他提供的信息（SERVICE&nbsp;信息），还有服务器可以发觉的（从DNS服务器）。<br />
<br />
5．3终结一个服务器到服务器的连接<br />
<br />
终结一个服务器到服务器的连接是有危险的，因为这中间可能发生错误的地方太多了，——<br />
最起码也会有信道状态问题。<br />
<br />
当服务器接收到一个连接跟随着一个PASS/SERVER，被认为是可以信赖的，服务器就会回<br />
复它自己的PASS/SERVER的信息，作为对那条信息的回复，就象是下面描述的一样。<br />
<br />
当开始的服务器接收到一个PASS/SERVER信息时，在确认那个服务器的连接是否可信之<br />
前，要先检测那个服务器的回复是否合理。<br />
<br />
5．3．1连接设置<br />
<br />
服务器连接是以一个普通的协议为基础的（这篇文章中定义的），但是对于特殊的连接，就<br />
会有特殊的设置，用PASS信息（请看4。1。2）。<br />
<br />
5．3．1．1压缩的服务器到服务器的连接<br />
<br />
如果服务器想中断与其他服务器之间的连接，它就必须设置Z符号在PASS信息的参数前。<br />
如果两个服务器需要压缩，并且两个服务器都能够初始化压缩串，那么剩余的连接都可以被<br />
压缩。如果其中一个服务器不能初始化，那就会发送一个不能初始化的错误信息给另外一个<br />
服务器，并且切断连接。<br />
<br />
用于压缩的数据形式在IRC——1950（ZLIP），IRC——1951（DEFLATE），IRC——1952<br />
（GZIP）中描述的那样。<br />
<br />
5．3．1．2反对滥用保护<br />
<br />
大多数服务器执行各式各样的保护，来反对可能滥用的行为（典型用户）。在一些网络工作<br />
中，这些保护是必不可少的，但在其他工作中，则是多余的。为了所有服务器都能够执行，<br />
并且以这样的形式来完成网络服务。“P”标志位通常在两个服务器连接中使用。如果这个<br />
标志位现在存在，就说明服务器的保护是激活的，并且那个服务器需要所有与它相连的服务<br />
器都激活此项。<br />
<br />
建立普通的保护在5。7中描述（跟踪当前用户的呢称）和5。8（客户端的防火墙）。<br />
<br />
5．3．2在连接是改变状态信息<br />
<br />
在服务器之间改变状态信息的顺序是必需的。格式如下：<br />
*众所周知的服务器<br />
*众所周知的客户端信息<br />
*众所周知的信道信息<br />
<br />
关于服务器的信息是被额外的服务器信息发送的，客户端信息包括了呢称和服务，信道信息<br />
包括NJOIN/MODE信息也一起被发送。<br />
<br />
注意：信道标题在这里不可以被改变，因为标题会覆盖掉所有旧的标题信息，所以，最起码<br />
要服务器两端一起修改。<br />
<br />
通过一开始就传输的有关服务器的状态信息，任何已经出现的有关服务器的冲突就会发生，<br />
在呢称冲突（由于另外的服务器也有相同的呢称）之前。归功于IRC网络服务只可以以非<br />
循环图的形式表现，所以也有可能网络服务在其他的地方已经从新连接过了。在处理这种事<br />
情时，服务器冲突发生的地方，就以为这网络要分裂了。<br />
<br />
5．4中断服务器与客户端的连接<br />
<br />
当一个客户端连接出乎意料的中断了，服务器就会在客户端上产生一个QUIT&nbsp;信息。其他<br />
的命令都不用。<br />
<br />
5．5中断之间的连接<br />
<br />
如果服务器到服务器之间的连接被中断了，不管是SQUIT或者“NATRUAL”原因，剩下<br />
的IRC网络服务就一定由检测到中断的那个服务器来休正。中断的那个就要发送一个SQUIT<br />
清单。（给这个连接之后的每一个服务器一个）（请看4。1。6）。<br />
<br />
5．6跟踪呢称变化<br />
<br />
所有IRC服务器都必须保存一份记录，有关呢称改变的。这很重要，尤其是对于服务器可<br />
以在呢称改变是，用适当的命令来与它们保持联系。跟踪的信息：<br />
<br />
*KILL（该呢称断线）<br />
*MODE(+/-&nbsp;o,v&nbsp;on&nbsp;channels)<br />
*KICK（该呢称被从信道上消除了）<br />
<br />
其他命令不需要检查呢称改变。<br />
<br />
在上述情况中，服务器要先检测现有的呢称，然后查看历史记录，那个呢称现在属于谁？这<br />
就降低了出错的可能性，但是它还是会在服务器终止一个错误的客户端是发生。当实现一个<br />
改变对上述命令的跟踪时，建议限定历史的时间范围，太旧的记录可以被忽略。<br />
<br />
对于一个合情合理的历史记录，服务器就应该保存客户端以前的名称，如果它们想改变名称<br />
的话。这种状况会有其他因素制约。（比如记忆体，等等）<br />
<br />
5．7跟踪最近使用过的用户名<br />
<br />
这种体制通常被认为是“NICK&nbsp;DELAY”，它已经被证实，可以减少用户名冲突的数量，就<br />
是那些主要由网络分裂和再登陆引起的。<br />
<br />
保持跟踪呢称的改变，服务器要随时跟踪最近使用过的用户，并且随时释放那些被网络分裂<br />
和KILL信息加载过的用户名。这些呢称就会变成不可信的，对于服务器当地的客户端。并<br />
且在一端特定的时间里不能被使用。<br />
<br />
呢称不可使用的时间限制，是受许多因素影响的，这些因素大多与IRC网络服务和普通的<br />
网络分裂的时间有关。对于所有服务器来说，这是个规矩。<br />
<br />
5．8客户端的溢出控制<br />
<br />
由于太多的网络服务连接IRC&nbsp;服务器上，对于每一个客户端来说，提供连穿的信息是非常<br />
容易的，不仅仅是溢出,同时也会降低对其他服务器服务的级别。不是对每个受害人都提供<br />
保护，溢出保护被写进服务器，被应用到客户端，除了服务。当前采用的法则运算是这样的：<br />
<br />
*检查客户端的信息记时器比当前的时间少（设置成相等看看是否相同）。<br />
<br />
*从客户端读取信息<br />
<br />
*如果记时器比当前的少10秒，分析当前信息，然后把每个信息都向后2秒。<br />
<br />
*附加处罚可能用来一些特殊的信息，可以产生很多通过网络传输的输入。<br />
<br />
5．9无模块查找<br />
<br />
在一个真实时间的环境里，所必须的是，服务器进程做最少时间的等待，所以所有客户端服<br />
务都是平等的。很明显，这就需要在读/写操作上执行无模块的IO。对于那些普通的服务器<br />
连接，这并不难，但是还有些其他相关的操作，可能会导致服务器停止（比如读盘）。在那<br />
些可能的地方，这种行为可能会导致时间超标。<br />
<br />
5．9．1主机名查询（DNS）<br />
<br />
使用标准的Berkeley伯克利资料库，或者其他的资料库，就意味着在某些事情中会产生大<br />
量的中断，而且会出现回复暂停。为了防止这种事情发生，一个独立的DNS程序被写入了<br />
为了当前的执行。程序被安装，连同当地的高速缓冲存储器一起，就可以达到无模块化的<br />
IO操作，然后就可以被拖进主服务器IO回路。<br />
<br />
5．9．2用户名（IDENT）查询<br />
<br />
尽管有很多用户名资料库（执行见证协定[IDENT]），可以使用，并且包含了很多的其他的<br />
程序，这就导致了问题的发生，因为它们以相同的方式操作，并且导致了很多频繁的延迟。<br />
同样，解决方法就是写一个程序，它可以同其他服务器连接，并且可以使用NON-BLOCKING&nbsp;<br />
IO。<br />
<br />
6．当前问题<br />
<br />
这个协议中公认的问题就有很多，所有的问题都期待着能在不久的将来被解决。现在，这项<br />
工作已经在进行中了。<br />
<br />
6．1可靠性<br />
<br />
广泛认同：如果协议在一个很大的地区使用，那它就不能很好的工作。最大的问题就是服务<br />
器需要了解所有其他服务器和客户端的信息，只要它们一改变，就随之改变。保持服务器数<br />
量低也是个有效的办法，只要如此，两点之间的距离就不会太长，生成的树型网络也就有效<br />
的多。<br />
<br />
6．2标志<br />
<br />
当前的IRC协议有四个类型的标志：用户呢称，信道名，服务器名，服务名。每一个都有<br />
自己的使用范围，并且在自己的范围里，没有复本。当前，如果用户把其中一个当作另外三<br />
个，就会引起冲突。广泛的认同：这项操作需要重新设计，有这样一个计划：每一个标志有<br />
它们自己的特殊的名字，就象解决循环树问题一样。<br />
<br />
6．2．1呢称<br />
<br />
IRC中关于呢称的方法对于用户来说，是非常方便的，尤其是在信道外聊天时。但是，存储<br />
呢称的空间是有限的，并且一直存在，几个人用一个名字是不可以的。如果两个人选了一个<br />
名字，那么其中的一个，或者两个人一起，会被KILL命令删除。（详情请看3。7。1IRC客<br />
户端协议[IRC客户端]）<br />
<br />
6．2．2信道<br />
<br />
当前的信道规则：所有服务器都要知道所有信道，它们的位置和特性。由于执行不是很好，<br />
不被干扰的事情还是需要担心的。信道冲突被看作是集体冲突（信道上两个网中的人有着一<br />
样的名字被认为是信道中的成员），而不是象呢称冲突一样的单一事件。<br />
<br />
协议定义了"安全信道"，这种信道不太可能发生信道冲突。其他信道模式保存下来为了向后<br />
的兼容性。<br />
<br />
6．3运算法则<br />
<br />
服务器代码中的某些地方，不可以不用N^2这样的法则，因为要检测信道上的客户端。<br />
<br />
在当前服务器的版本中，只有少数数据库包含了检测方法，现在大多数服务器，每一个都只<br />
能假想周边的服务器是正确的。这就为大量问题打开了大门，如果一个连接中服务器有问题，<br />
或者它正向网络中散发病毒。<br />
<br />
当前，由于缺少独一无二的中央处理器和全球范围的标志，多种多样的问题都已经出现。这<br />
种情况大多是由问题引发的，因为它们需要时间来传播信息，并且作用于网络。即使把它们<br />
更改成独一无二的标志，也还是会产生问题，使信道连接中断。<br />
<br />
7．安全考虑<br />
<br />
7．1证明<br />
<br />
服务器通常只有两种方法来鉴别加入的连接：检测密码和DNS查找。尽管这种方法是脆弱<br />
的并且被公认为不够安全，它们的合并已经在过去被证实了：<br />
<br />
*公共的网络只需要对用户进行很少的限制和约定，不需要很严格的测试。<br />
<br />
*在控制环境下的私人网络，经常使用HOME-GROWN鉴定装置，但是在INTERNET上是<br />
不可信的：只有在某些服务器上[IDENT]，或者其他私有的服务器上才是可用的。<br />
<br />
同样的坚定应用与IRC&nbsp;操作员的鉴定。<br />
<br />
同样也会注意：就是那里有很多年不需要更强的鉴定，不需要更大的努力提供更好的鉴别用<br />
户，当前的协议提供了足够的额外的鉴别方法，以客户端信息为基础，并且服从于服务器连<br />
接，：服务器名，用户名，密码。<br />
<br />
7．2完整性<br />
<br />
路径和操作信息被发送进空白的文档，串层加密装置，（象TLS协议），可以用来保护这些<br />
操作。<br />
<br />
8．相关支持和联接<br />
<br />
IRC相关讨论：主论区：ircd_users@irc.org<br />
协议开发：ircd_dev@irc.org<br />
软件操作：<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ftp://ftp.irc.org/irc/server<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ftp://ftp.funet.fi/pub/unix/irc<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ftp://coombs.anu.edu.au/pub/irc<br />
新闻组：alt.irc<br />
<br />
9．鸣谢：<br />
这篇文章部分是从RFC-1459[IRC]，是第一次正式的公布IRC协议。它得意于很多的观点和<br />
内容。特别是下面的对本书作出极大贡献：<br />
Matthew&nbsp;Green,&nbsp;Michael&nbsp;Neumayer,&nbsp;Volker&nbsp;Paulsen,&nbsp;Kurt&nbsp;Roeckx,&nbsp;Vesa<br />
&nbsp;&nbsp;&nbsp;Ruokonen,&nbsp;Magnus&nbsp;Tjernstrom,&nbsp;Stefan&nbsp;Zehl.<br />
<br />
10．参考书目：<br />
<br />
<br />
&nbsp;&nbsp;&nbsp;[KEYWORDS]&nbsp;&nbsp;&nbsp;Bradner,&nbsp;S.,&nbsp;"Key&nbsp;words&nbsp;for&nbsp;use&nbsp;in&nbsp;RFCs&nbsp;to&nbsp;Indicate<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Requirement&nbsp;Levels",&nbsp;BCP&nbsp;14,&nbsp;RFC&nbsp;2119,&nbsp;March&nbsp;1997.<br />
<br />
&nbsp;&nbsp;&nbsp;[ABNF]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Crocker,&nbsp;D.&nbsp;and&nbsp;P.&nbsp;Overell,&nbsp;"Augmented&nbsp;BNF&nbsp;for&nbsp;Syntax<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Specifications:&nbsp;ABNF",&nbsp;RFC&nbsp;2234,&nbsp;November&nbsp;1997.<br />
<br />
&nbsp;&nbsp;&nbsp;[IRC]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Oikarinen,&nbsp;J.&nbsp;and&nbsp;D.&nbsp;Reed,&nbsp;"Internet&nbsp;Relay&nbsp;Chat<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Protocol",&nbsp;RFC&nbsp;1459,&nbsp;May&nbsp;1993.<br />
<br />
&nbsp;&nbsp;&nbsp;[IRC-ARCH]&nbsp;&nbsp;&nbsp;Kalt,&nbsp;C.,&nbsp;"Internet&nbsp;Relay&nbsp;Chat:&nbsp;Architecture",&nbsp;RFC&nbsp;2810,<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;April&nbsp;2000.<br />
<br />
&nbsp;&nbsp;&nbsp;[IRC-CLIENT]&nbsp;Kalt,&nbsp;C.,&nbsp;"Internet&nbsp;Relay&nbsp;Chat:&nbsp;Client&nbsp;Protocol",&nbsp;RFC<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2812,&nbsp;April&nbsp;2000.<br />
<br />
&nbsp;&nbsp;&nbsp;[IRC-CHAN]&nbsp;&nbsp;&nbsp;Kalt,&nbsp;C.,&nbsp;"Internet&nbsp;Relay&nbsp;Chat:&nbsp;Channel&nbsp;Management",&nbsp;RFC<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2811,&nbsp;April&nbsp;2000.<br />
<br />
&nbsp;&nbsp;&nbsp;[ZLIB]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Deutsch,&nbsp;P.&nbsp;and&nbsp;J-L.&nbsp;Gailly,&nbsp;"ZLIB&nbsp;Compressed&nbsp;Data<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Format&nbsp;Specification&nbsp;version&nbsp;3.3",&nbsp;RFC&nbsp;1950,&nbsp;May&nbsp;1996.<br />
<br />
&nbsp;&nbsp;&nbsp;[DEFLATE]&nbsp;&nbsp;&nbsp;&nbsp;Deutsch,&nbsp;P.,&nbsp;"DEFLATE&nbsp;Compressed&nbsp;Data&nbsp;Format<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Specification&nbsp;version&nbsp;1.3",&nbsp;RFC&nbsp;1951,&nbsp;May&nbsp;1996.<br />
<br />
&nbsp;&nbsp;&nbsp;[GZIP]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Deutsch,&nbsp;P.,&nbsp;"GZIP&nbsp;file&nbsp;format&nbsp;specification&nbsp;version<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.3",&nbsp;RFC&nbsp;1952,&nbsp;May&nbsp;1996.<br />
<br />
&nbsp;&nbsp;&nbsp;[IDENT]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;St.&nbsp;Johns,&nbsp;M.,&nbsp;"The&nbsp;Identification&nbsp;Protocol",&nbsp;RFC&nbsp;1413,<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;February&nbsp;1993.<br />
<br />
&nbsp;&nbsp;&nbsp;[TLS]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Dierks,&nbsp;T.&nbsp;and&nbsp;C.&nbsp;Allen,&nbsp;"The&nbsp;TLS&nbsp;Protocol",&nbsp;RFC&nbsp;2246,<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;January&nbsp;1999.<br />
<br />
11．作者地址<br />
<br />
Christophe&nbsp;Kalt<br />
&nbsp;&nbsp;&nbsp;99&nbsp;Teaneck&nbsp;Rd,&nbsp;Apt&nbsp;#117<br />
&nbsp;&nbsp;&nbsp;Ridgefield&nbsp;Park,&nbsp;NJ&nbsp;07660<br />
&nbsp;&nbsp;&nbsp;USA<br />
<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;kalt@stealth.net<br />
<br />
12．版权说明<br />
<br />
<br />
&nbsp;&nbsp;&nbsp;Copyright&nbsp;(C)&nbsp;The&nbsp;Internet&nbsp;Society&nbsp;(2000).&nbsp;&nbsp;All&nbsp;Rights&nbsp;Reserved.<br />
<br />
&nbsp;&nbsp;&nbsp;This&nbsp;document&nbsp;and&nbsp;translations&nbsp;of&nbsp;it&nbsp;may&nbsp;be&nbsp;copied&nbsp;and&nbsp;furnished&nbsp;to<br />
&nbsp;&nbsp;&nbsp;others,&nbsp;and&nbsp;derivative&nbsp;works&nbsp;that&nbsp;comment&nbsp;on&nbsp;or&nbsp;otherwise&nbsp;explain&nbsp;it<br />
&nbsp;&nbsp;&nbsp;or&nbsp;assist&nbsp;in&nbsp;its&nbsp;implementation&nbsp;may&nbsp;be&nbsp;prepared,&nbsp;copied,&nbsp;published<br />
&nbsp;&nbsp;&nbsp;and&nbsp;distributed,&nbsp;in&nbsp;whole&nbsp;or&nbsp;in&nbsp;part,&nbsp;without&nbsp;restriction&nbsp;of&nbsp;any<br />
&nbsp;&nbsp;&nbsp;kind,&nbsp;provided&nbsp;that&nbsp;the&nbsp;above&nbsp;copyright&nbsp;notice&nbsp;and&nbsp;this&nbsp;paragraph&nbsp;are<br />
&nbsp;&nbsp;&nbsp;included&nbsp;on&nbsp;all&nbsp;such&nbsp;copies&nbsp;and&nbsp;derivative&nbsp;works.&nbsp;&nbsp;However,&nbsp;this<br />
&nbsp;&nbsp;&nbsp;document&nbsp;itself&nbsp;may&nbsp;not&nbsp;be&nbsp;modified&nbsp;in&nbsp;any&nbsp;way,&nbsp;such&nbsp;as&nbsp;by&nbsp;removing<br />
&nbsp;&nbsp;&nbsp;the&nbsp;copyright&nbsp;notice&nbsp;or&nbsp;references&nbsp;to&nbsp;the&nbsp;Internet&nbsp;Society&nbsp;or&nbsp;other<br />
&nbsp;&nbsp;&nbsp;Internet&nbsp;organizations,&nbsp;except&nbsp;as&nbsp;needed&nbsp;for&nbsp;the&nbsp;purpose&nbsp;of<br />
&nbsp;&nbsp;&nbsp;developing&nbsp;Internet&nbsp;standards&nbsp;in&nbsp;which&nbsp;case&nbsp;the&nbsp;procedures&nbsp;for<br />
&nbsp;&nbsp;&nbsp;copyrights&nbsp;defined&nbsp;in&nbsp;the&nbsp;Internet&nbsp;Standards&nbsp;process&nbsp;must&nbsp;be<br />
&nbsp;&nbsp;&nbsp;followed,&nbsp;or&nbsp;as&nbsp;required&nbsp;to&nbsp;translate&nbsp;it&nbsp;into&nbsp;languages&nbsp;other&nbsp;than<br />
&nbsp;&nbsp;&nbsp;English.<br />
<br />
&nbsp;&nbsp;&nbsp;The&nbsp;limited&nbsp;permissions&nbsp;granted&nbsp;above&nbsp;are&nbsp;perpetual&nbsp;and&nbsp;will&nbsp;not&nbsp;be<br />
&nbsp;&nbsp;&nbsp;revoked&nbsp;by&nbsp;the&nbsp;Internet&nbsp;Society&nbsp;or&nbsp;its&nbsp;successors&nbsp;or&nbsp;assigns.<br />
<br />
&nbsp;&nbsp;&nbsp;This&nbsp;document&nbsp;and&nbsp;the&nbsp;information&nbsp;contained&nbsp;herein&nbsp;is&nbsp;provided&nbsp;on&nbsp;an<br />
&nbsp;&nbsp;&nbsp;"AS&nbsp;IS"&nbsp;basis&nbsp;and&nbsp;THE&nbsp;INTERNET&nbsp;SOCIETY&nbsp;AND&nbsp;THE&nbsp;INTERNET&nbsp;ENGINEERING<br />
&nbsp;&nbsp;&nbsp;TASK&nbsp;FORCE&nbsp;DISCLAIMS&nbsp;ALL&nbsp;WARRANTIES,&nbsp;EXPRESS&nbsp;OR&nbsp;IMPLIED,&nbsp;INCLUDING<br />
&nbsp;&nbsp;&nbsp;BUT&nbsp;NOT&nbsp;LIMITED&nbsp;TO&nbsp;ANY&nbsp;WARRANTY&nbsp;THAT&nbsp;THE&nbsp;USE&nbsp;OF&nbsp;THE&nbsp;INFORMATION<br />
&nbsp;&nbsp;&nbsp;HEREIN&nbsp;WILL&nbsp;NOT&nbsp;INFRINGE&nbsp;ANY&nbsp;RIGHTS&nbsp;OR&nbsp;ANY&nbsp;IMPLIED&nbsp;WARRANTIES&nbsp;OF<br />
&nbsp;&nbsp;&nbsp;MERCHANTABILITY&nbsp;OR&nbsp;FITNESS&nbsp;FOR&nbsp;A&nbsp;PARTICULAR&nbsp;PURPOSE.<br />
<br />
致谢：<br />
&nbsp;&nbsp;&nbsp;Funding&nbsp;for&nbsp;the&nbsp;RFC&nbsp;Editor&nbsp;function&nbsp;is&nbsp;currently&nbsp;provided&nbsp;by&nbsp;the<br />
&nbsp;&nbsp;&nbsp;Internet&nbsp;Society.<br />
<br />
<br />
<br />
<br />
RFC2813——Internet&nbsp;Relay&nbsp;Chat:&nbsp;Server&nbsp;Protocol&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Internet&nbsp;交换交谈：服务器协议<br />
<br />
<br />
1<br />
RFC文档中文翻译计划<br />