交换交谈服务器协议.docx
- 文档编号:28280970
- 上传时间:2023-07-10
- 格式:DOCX
- 页数:32
- 大小:33.33KB
交换交谈服务器协议.docx
《交换交谈服务器协议.docx》由会员分享,可在线阅读,更多相关《交换交谈服务器协议.docx(32页珍藏版)》请在冰豆网上搜索。
交换交谈服务器协议
交换交谈服务器协议
RequestforComments:
2813April2000
Updates:
1459
Category:
Informational
Internet交换交谈:
服务器协议
(RFC2813——InternetRelayChat:
ServerProtocol)
备忘录的状态:
那个备忘录提供了internet群体的信息。
它并没有详细讲明每一种internet的标准。
那个备
忘录的适用范畴是无拘谨的。
版权通告:
copyright(c)internetSociety(2000).AllRightsReserved.
摘要:
以客户端——服务器为模板,irc协议承诺服务器连接到另外的有效形成的网络。
本文档定义了服务器用于互相交流的协议。
它原先只是一个客户端协议的超集,然而差不多发
展的不同了。
正式的出版是在1993年5月作为rfc的一部分。
从那时以来,大多数的为了使协议更加标
准的改变都能够在这篇文章中找到。
更加标准的协议差不多承诺显现在万维网中,以使它能够
保持持续的更新,同时有不于原先的版本。
名目
1绪论2
2.全球数据库3
2.1服务器3
2.2客户端3
2.3信道4
3.irc服务器的讲明4
3.1概要4
3.2特点代码4
3.3信息5
3.4数字回复6
4信息细节6
4.1连线注册7
4.2信道操作:
11
4.3模式信息13
5.执行细节13
5.1连接失效13
5.2同意客户端到服务器的连接13
5.3终结一个服务器到服务器的连接14
5.4中断服务器与客户端的连接16
5.5中断之间的连接16
5.6跟踪呢称变化16
5.7跟踪最近使用过的用户名17
5.8客户端的溢出操纵17
5.9无模块查找17
6.当前咨询题18
6.1可靠性18
6.2标志18
6.3运算法则19
7.安全考虑19
7.1证明20
7.2完整性20
8.有关支持和联接20
9.鸣谢:
20
10.参考书目:
21
11.作者地址22
12.版权讲明22
致谢:
23
1绪论
这篇文章是为了那些开发irc服务器的人而做的,但同时对那些以irc为工具的人也
是有用处的。
服务器提供了以《irc:
体系》中定义的同时讨论为基础的三项服务:
客户端位置(由
客户端协议[irc客户端]定义),信息传递(由这篇文章中的服务器协议定义),和信道的建设
主机与会议协商(详细条款请看[irc——信道])。
2.全球数据库
尽管irc协议定义了一些公平的发散式的模式,然而每一个服务器保持了一个关于整
个irc网络的“全球状态数据库”。
那个数据库理论上讲对所有服务器来讲差不多上独一无二的。
2.1服务器
服务器能够通过申请一个最长63个字母的独一无二的名字。
查看协议的语法条款[3。
3。
1]来确定那些字母在名字中是能够使用的,那些是不能使用的。
每一个服务器差不多上理论上差不多上被其他服务器所了解的,然而有一种可能,定义一个
假的主机名字联合其他服务器使用它的名字。
在HOSTMASK的区域里,所有服务器都有一
个和HOSTMASK名字相符的名字,在HOSTMASK区域外的服务器,即使有一个跟
HOSTMASK一样的名字,也不能够登陆到irc中去。
而区域外的服务器关于区域内的服务
器的状态则一无所知,相反的,它们被给予一个HOSTMASK的名字。
2.2客户端
关于每一个客户端,所有的服务器都必须有以下信息:
一个网络中专门的姓名标志
(它们的形式由客户端来决定),以及一个正在与客户端连接的服务器。
2.2.1用户
每一个用户有个专门的最长为9个字母的用户名。
查看协议上的语法规则[3。
3。
1]
来判定什么是能够使用的,那些不能使用。
作为用户名的附加段,每个服务器都要对用户保
留有以下信息:
用户正在连接的服务器名,用户在该服务器上的用户名,以及服务器连接的
客户端名。
2.2.2服务
每一项服务都能够通过用户名和服务器名来区不与其他服务。
用户名最多承诺9个
字母。
查看协议上的语法规则[3。
3。
1]来判定那些字符能够使用,那些不行。
用来标志服
务名称的服务器名确实是这项服务连接的服务器名。
作为这项服务的补充,所有服务器必须都
了解这种服务形式。
服务通过它们特有的标志符形式来区不于用户名,然而更多的较重要的服务和用户
名对服务器的权限是不同的:
服务能够调用服务器中保留的部分甚至全部全球数据库中的信
息,然而对它们的限制就更加严格(详见irc客户端协议)同时不承诺加入信道。
最后一点,
服务并不总是服从与防火墙的5。
8中有详细叙述。
2.3信道
就象服务一样,信道也有它的相应规定[irc——信道]同时没有必要让所有服务器了
解。
当一个信道的存在被一个服务器所了解,服务器就一定要记录信道成员的轨迹和信道模
式。
3.irc服务器的讲明
3.1概要
那个地点描述的协议是用来给服务器和服务器相连接的。
关于客户端与服务器的连接,
请看irc——客户端协议规则。
然而,关于客户端的连接有比服务器之间连接更多的规定(然而通常不认为是不可
靠的)。
3.2特点代码
那个地点并没有讲明那些专门的特点代码。
协议是以一个由8个字节的代码组成的集合
构成的。
每一条信息都可能由若干个这种8位字节的代码组成。
然而,一些8个字节的代码
含义是用来做操纵代码的,就象信息的分割符。
不管是什么样的8字节协议,分割符和关键字差不多上协议用来进行美国——ASCII码
的终端连接和远程登录连接。
因为irc是由北欧方面产生的,某些地区,字母{}|^被认为是等同于小键盘上
的{}\~字母。
这在确定用户名和信道名是否相同时,回显现严峻咨询题。
3.3信息
服务器和客户端发送各自的信息,因此,可能收到回复,也可能没有回复。
大多数
服务器之间的联系不需要回复,因为大多数时候服务器会为客户端预备好工作进程。
每一条irc的信息都由三个要紧部分组成:
前缀(能够省略),命令,和命令参数(最
多15个字符)。
前缀,命令和所有参数被一个ASCII码空格(0*20)隔开。
前缀是以一个ASCII码中的冒号(:
0*3b)来标识的,它必须是信息的第一个字
符。
冒号和前缀之间不能够有空格。
前缀是服务器用来标识信息的来源的。
如果信息中的前
缀丢失,它就会被默认成是从它刚刚连接并接收到信息的那个服务器。
客户端自己互相在发
送信息时,不应该使用前缀;如果它使用了,唯独有效的前缀确实是正在使用那个客户端的已
经注册过的用户名。
当一个服务器接收信息时,它必须通过前缀来判不信息的来源。
如果在服务器的中
央数据库中找不到前缀,那它一定是被丢弃了,同时如果那个前缀指明的服务器是一个不知
名的服务器,那么那个信息传来的的连接将被删除。
在这种情形下删除连接是有点过分,但
是保持网络服务的严谨与禁止以后可能发生的咨询题却是必要的。
另外一种常见的咨询题:
前缀
指向的信息来源是与实际不同(典型情形:
来源指向的是另一个连接而不是信息来源。
)如
果信息被服务器接收,而来源指向客户端,一条删除客户端的信息就会发送到各个服务器中
去。
另外一种情形,信息由来的那个连接就应该会在客户端被删除,同时一定要在服务器内
删除。
不管什么情形,这条信息都要被删除。
命令一定要是有效的irc命令或者是用ASCII码描述的三位字节。
Irc信息通常是以CR-LF(换行和回车)为终止的成行的命令,这些信息的长度不可
以超过512个字节,其中包括CR-LF。
因此,命令和它的参数最多只能有510个字节。
没
有能够用来延长命令行的方法。
查看第5部分能够找到有关当前命令的执行。
3.3.1扩展格式的信息
有关协议的信息一定要从一系列的8位字节中提取出来。
现在的方法是标志出两个
字符,CR,LF,用来提取信息。
空信息通常被默默忽略掉,这就显示出CR-LF在预防额外
咨询题中的作用。
有效的信息被分成:
若干部分(前缀),(命令),和参数表(参数)。
扩展BNF对这方面的表述能够在irc——客户端协议中找到[irc--客户端]。
附加前缀([“!
”user“@”host])决不能够在服务器之间的连接中使用,它的使用
范畴只有服务器到客户端的连接,如此,客户端即使不需要额外的疑咨询而直截了当得到信息的来
源。
3.4数字回复
绝大部分发送去服务器的信息是有一定顺序的。
最一般的回复是数字回复,既能够
用来回复错误,也能够一般回复。
数字回复作为一种信息,一定要包括有前缀,三个阿拉伯
数字,和回复的目标对象客户端不承诺发送数字回复,服务器如果接收到如此的回复,就会
自动删除掉。
在所有其他关系中,数字回复就象是一个一般的信息,除非它的关键字是用三
个阿拉伯数字组成的,而不是字符串。
一些另类的数字回复能够在irc——客户端协议中找
到[irc——客户端]。
4信息细节
所有irc的服务器与客户端认可的信息都在irc---客户端协议中详细介绍过了。
当显现错误:
没有此服务器时,那就意味着目标信息没有被找到。
如果是命令发
生这种错误,服务器决不能够发送回复。
客户端所连接的服务器要分析整个信息,回复适当的错误。
如果服务器在分析信息
时,遇到一个致命的错误,那么一个错误的回复信息就会被送回,同时终止分析。
致命的错
误通常是由错误命令引发的,目标来源关于服务器来讲可能是未知的(服务器,客户端,信
道符合那个类型),也可能是不正确的参数,或者错误的权限。
如果全部参数都存在,那么每一个都必须检查它是否能够有效的同时合适的送回到
客户端。
如果信息中使用的参数表是用逗号来做分隔符的,那么就要发送回复来得到每一条
条款。
在下面的例子中,有些信息是以完整形式给出的:
:
姓名命令参数菜单
如此的例子是用“姓名”来标志信息的,在服务器间来回的传递,它的本质是信息
的原始发送者的名字,如此,即使远程服务器也能够找到正确的路径。
描述从客户端到服务器的连接细节的信息在irc——客户端协议中有详细描述[irc—
—客户端]。
下面文章的一些章节确实是对这些文章的应用,它们对那些只描述服务器之间连
接和信息的执行的信息是个附加。
在那个地点介绍的信息差不多上只用来做服务器之间连接的。
4.1连线注册
那个地点介绍的命令是用来向另外一个irc服务器连线注册的。
4.1.1密码信息
命令:
路径
参数:
<密码><提示信息><标志位>[<选项>]
PASS路径命令被用来设置一个连接密码。
密码一定要在连线注册前设定。
这就意
味着在PASS命令一定要在任何服务器命令之前。
只有第一个PASS命令会被连接认可。
如果是从客户端接收到的信息,那么最后的三个参数就会被忽略(e。
g服务器的一
个用户)。
只有当它们是从服务器发送来得时候,它们才相互关联。
变量参数至少要有四个字节,最多有十四个字节。
开始的四个字节一定要是阿拉伯
数字,简要讲明协议中的变量,确实是已被服务器获知的那些信息。
这篇文章所描述的确实是2。
1。
0版本的协议,通常被标志成“0210”。
剩下的可供选择的字母是执行时所要依靠的,并
且需要描述软件的版本号。
标志位参数是一个字符串,最长能够包括100个字符。
它是由两个副串组成的,中
间以一个“|”分开(%x7c)。
如果是现在,那么这第一个副字符串一定要是执行的名字。
涉
及到的执行(请看第8部分,当前的支持与可靠性)使用irc字符串。
如果要写另外一个执
行命令,就需要一个标志符,同时那个标志符应该是在RFC上已注册的。
两个副串是可选
择的,然而字符“|”是必须的。
那个字符不能够显现在任何一个副串中。
最后,最后的参数,<选项>,是用来做连接设置的。
协议定义过的唯独选项,连接压
缩(使用字母“Z”),和一个误差爱护位(使用字母“P”)。
参看5。
3。
1。
1(压缩的服务
器与服务器连接),5。
3。
1。
2(自动爱护位),分不相对与这些选项的更多信息。
数字回复:
错误需要更多参数错误已注册
例子:
PASS更多的密码字数0210010000irc|abgh$z
4.1.2服务器信息
命令:
服务器
参数:
〈服务器名〉〈期望数值〉〈标记〉〈信息〉
这条命令是用来注册一个新的服务器用的,新的连接中,它作为以一个服务器的身
份向它的同行介绍自己。
那个命令也能够用来在整个网络中传递服务器的信息。
当一个新的
服务器连接到网上,它的有关信息就一定要遍告整个网络。
〈信息〉参数能够包含空格符。
〈期望数值〉是用来告知服务器其他服务器在那儿,距离多远。
当地的服务器会被
赋为0,每通过一个,值就增加。
用一个完整的服务器列表,你能够建立一个完整的服务器
树型网络图,因此,如果有HOSTMASK建立的话,这就行不通了。
〈标志〉参数是服务器用来做标志的无符号数。
那个标志符后来被用来表示一个服
务器,在传递服务器之间的用户名和服务信息时。
服务器的标志符只有在点对点的服务器之
间连接时才有效,同时关于那个连接是专门的。
并不是全球通用的。
服务器信息只有在连接注册时才被承诺,或者是连接到其他服务器,在那种情形下,
服务器信息是介绍一个新服务器。
大多数错误差不多上在服务器信息返回时发生的,缘故确实是终端服务器中断了连接(目
标服务器)。
由于这种事件的严峻性,错误回复通常是返回“错误”命令,而不是数字回复。
如果服务器信息被分析,同时它试图向一个差不多了解了的服务器介绍服务器时,那
么那个连接,从消息收到的那方,就一定要被关闭(按照正规的顺序)。
因为一条通往那个
服务器的路线差不多形成,同时会破坏差不多形成的irc树型网络。
在一些情形下,也能够由发
送消息的那一方停止信息。
必须声明的是:
这种错误也可能由于服务器的第二次启动产生,
协议中产生了这种咨询题是不可能修复的,通常需要人类的参与。
这种错误是专门阴险的,因
为只要irc服务器中一个被孤立,就会产生这种错误。
如果两个服务器中的一个被孤立,那
么连接就不能连接。
数字回复:
错误——已注册
举例
SERVERtest.oulu.fi11:
Experimentalserver;Newserver
test.oulu.fi确实是在介绍服务器本身,同时试图注册。
:
tolsun.oulu.fiSERVERcsd.bu.edu534:
BUCentralServer;Server
tolsun.oulu.fi是到5步远的csd.bu.edu连接。
当连接到csd.bu.edu
时,参数34将被tolsun.oulu.fi调用,来介绍新的用户或服务。
4.1.3呢称
命令:
呢称
参数:
<呢称><期望值><用户名><主机><服务器token><模式><真实姓名>
这种形式的呢称一定可不能被使用者接收。
然而,它能够作为呢称/使用者的替代,来
向其他服务器介绍新的使用者,刚刚加入irc中的。
那个信息是由三条不同的信息组合成的:
呢称,用户,模式[irc——客户]。
期望值那个参数是服务器用来描述使用者距离服务器主机距离的。
本地的连接期望值
是0。
每次通过一个服务器,期望值就增加。
服务器代码那个参数替代了原先的用户中的参数服务器名。
(查看4。
1。
2能够找到
更多资料)
例子:
NICKsyrk5kalt34+i:
ChristopheKalt
新的使用者有那个呢称“syrk”,用户名“kalt”,
从主机连接到服务器
34("csd.bu.edu"按照前一个例子).
:
krysNICKsyrk:
呢称信息的另外一种形式,就象irc客户端协
议中定义的一样。
在服务器之间使用:
用户
krys把他的名字改为syrk。
4.1.4服务信息
命令:
服务
参数:
<服务名称><服务代码><分类><类型><期望值>〈信息〉
服务命令是用来介绍一条新服务。
这种形式的服务信息不能够被客户端同意(不管有没有注
册)。
然而,它一定要使用于服务器通告于其他服务器,有新信息如果irc网络服务。
服务代码是用来鉴不服务连接到的服务器。
(详情请看4。
1。
2关于服务器代码)
期望值参数是被服务器用来测量,服务与服务器之间距离的。
当地连接的期望值是0。
每经
过一个服务器,期望值就加一。
分类参数被用来指定服务的明显度。
服务只被有着与分类参数相符的服务器了解。
因为与之
相匹配的服务器了解了这条服务,在服务器与提供服务的服务器之间的路径,一定要能够分
解成服务器名。
没有任何限制时,就使用符号‘*’。
类型参数现在储存下来是为了今后使用。
数字回复:
ERR_ALREADYREGISTREDERR_NEEDMOREPARAMS
ERR_ERRONEUSNICKNAME
RPL_YOURESERVICERPL_YOURHOST
RPL_MYINFO
例子:
服务dir@irc.fr9*.fr01:
法文r在服务器9中注册,在通知其他服务器。
这条服务只有服务
器的名字里有fr时才有效。
4.1.5退出
命令:
退出
参数:
客户端的会议通常是以一个退出命令作为终止的。
如果客户端发送出退出信息,那么服务器
一定要终止跟客户端的连接。
如果退出信息发送出,那个就会被发送出,用来取代默认的信
息,通常是用户名或者服务名。
当网络中断(详情请看4。
1。
6)发生时,退出信息是由有关的两个服务器的名字组成的,
中间用一个空格分开。
第一个名字,是还在连接的那个服务器的名字,第二个是差不多断开的
服务器名字,或者是那个客户端连接到的服务器。
"servernameSPACEservername
由于"quitmessage"对“netsplits”来讲有一个专门意义,服务器不承诺客户端使用“quit
message”,用上面的形式。
如果,由于某些缘故,在还没有任何“quitmessage”客户端连接被终止了(客户端停止,
或者是发生断线),服务器需要用一些信息来填补退出信息,这些信息导致了中断的发生。
比较常见的,通常报告系统专门错误。
数字回复:
无。
例子:
:
WiZQUIT:
Gonetohavelunch;Preferredmessageformat
4.1.6服务器退出信息
命令:
SQUIT
参数:
<服务器><注释>
它有两种用法:
:
第一(详情请看InternetRelayChat:
ClientProtocol)承诺操作员断开当地的或者远程的连接。
这种形式的信息也是服务器用来断开连接的最后手段。
第二种用法被用来通知其他服务器,当网络中断发生时。
换句话,确实是告诉其他服务器有那
些服务器坏了。
如果一个服务器想终止与其他服务器的连接,它就必须向其他服务器发送
SQUIT信息,用其他服务器名做参数,确实是它想关闭连接的哪个。
注释通常用来存放那些能够放错误或者是相似信息的服务器。
被断开的两端的服务器都需要发出一个SQUIT信息(给所有与它们连接的服务器),给那些
连接背后的服务器。
同样的,QUIT信息可能被发送给其他还连接的服务器,为了所有连接的客户端。
作为补充,
这条差不多缺失了一个成员的信道上的所有成员,都必须发送一个退出信息。
信息是由这些成
员的服务器发出的。
如果一个服务器的连接断开了(另外一端的服务器死机了),那么监测到那个断开的服务器
就需要通知其他网络,连接已断开同时用恰当的文字填充注释。
当客户端由于SQUIT被中断,服务器就要把那个客户端的呢称加入已断开的名单,防止发
生呢称冲突。
详情看5。
7(跟踪最近使用的呢称)。
数字回复:
ERR_NOPRIVILEGESERR_NOSUCHSERVER
ERR_NEEDMOREPARAMS
例子:
SQUITtolsun.oulu.fi:
BadLink?
;服务器tolsun。
Oulu。
fi由于错误连接被中断。
:
TrillianSQUITcm22.eng.umd.edu:
Serveroutofcontrol;从trillian发送出的信息由于
服务器失去操纵而被中断。
4.2信道操作:
这组信息和操作信道有关,他们的道具(信道模式),同时他们的内容(典型用户)。
在这些
道具中,大量的关于信道状态是不可幸免的,专门是当使用者对反对断开作出连接的时候。
同时,它需要服务器保留一个呢称记录,来确定呢称在那儿使用过,只要资料一更换,服务
器就会检测历史记录。
4.2.1加入信息
命令:
JOIN
参数:
*(","
JOIN命令是客户端用来加入一个专门信道时使用的。
客户端是否被承诺加入,就只由当地
的服务器鉴定产生结果:
其他服务器只是单纯的填加那个用户,当它们收到这条信息时。
通常,用户在信道上的状态(信道模式0,o,v)能够加在信道名后面,用g分隔开。
如果
这种信息不是被服务器接收到,那么这种数据通常是被忽略的。
这种格式也不能够发送给客
户端,它只能用在服务器之间传输,同时应该被排除。
JOIN命令一定要通知所有服务器,因此服务器才明白如何找到信道上的用户。
它承诺理想
的PRIVMSG和NOTICE信息在信道上传输。
数字回复:
ERR_NEEDMOREPARAMSERR_BANNEDFROMCHAN
ERR_INVITEONLYCHANERR_BADCHANNELKEY
ERR_CHANNELISFULLERR_BADCHANMASK
ERR_NOSUCHCHANNELERR_TOOMANYCHANNELS
ERR_TOOMANYTARGETSERR_UNAVAILRESOURCE
RPL_TOPIC
例子:
:
WiZJOIN#Twilight_zoneWIZ的JOIN信息
4.2.2N加入信息
命令:
NJOIN
参数:
*(","["@@"/"@"]["+"]
NJOIN命令只用在服务器之间。
如果同意到这种信息是从客户端发送的,信息就会被忽略。
它要紧用于服务器之间交换用户及信道信息。
尽管如此,同样的函数用JOIN也能够完成,但这条信息能够用来取代JOIN,同时比它更
有效。
前缀“@@”表明用户是信道的制造者,符号“@”表明了信道的操作者,符号“+”
表明用户有权发声。
数字回复:
ERR_NEEDMOREPARAMSERR_NOSUCHCHANNEL
ERR_ALREADYREGISTRED
例子:
:
NJOIN#Twilight_zone:
@WiZ,+syrk,avalon
从发送来的NJION信息讲明用户正在加入#Twilight_zonechannel:
WiZ同时表
明了信道操作者的状态,syrk有发声权益,而avalon没有。
4.3模式信息
MODEL信息是irc中双重意义的命令。
它承诺用户名和信道的模式改变。
当解析MODEL信息时,建议先解析完整的信息,然后在进行改变。
那个地点需要服务器来改变
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 交换 交谈 服务器 协议