CIP 传输协议( 二 )


>>> x-tagged-index-1; dsi=1.2.752.17.5.10
>>>
>>> updatetype: incremental tagbased
>>> thisupdate: 855938804
>>> lastupdate: 855940000
>>> .
<<< % 200 Good MIME message received
>>> MIME-Version: 1.0
>>> Content-Type: application/index.obj.tagged;
>>> dsi=1.2.752.17.5.10;
>>> base-uri="ldap://ldap.umu.se/dc=umu,dc=se"
>>>
>>> version: x-tagged-index-1
>>> updatetype: incremental
>>> lastupdate: 855940000
>>> thisupdate: 855938804
>>> BEGIN IO-schema
>>> cn: TOKEN
>>> sn: FULL
>>> title: FULL
>>> END IO-Schema
>>> BEGIN Update Block
>>> BEGIN Old
>>> title: 3/testpilot
>>> END Old
>>> BEGIN New
>>> title: 3/chiefpilot
>>> END New
>>> END Update Block
>>> .
<<< % 200 Good MIME message received
{ 发送CIP关闭写套接字 }
<<< % 222 Connection closing in response to sender-CIP shutdown
{ 接收CIP关闭,重新设置状态并等待新的发送CIP连接 }
假如版本不对,则会出现下面的情况:
{ 发送CIP连接到接收CIP }
<<< % 220 Whoisserver ready
>>> # CIP-Version: 3
<<< % 500 Syntax error
{ 服务器关闭连接 }
发送CIP可以会尝试以版本1或2进行连接,而失败的结果会被缓冲以避免以后的失败 。

更多的请看:http://www.QQread.com/windows/2003/index.Html
2.1.1 传输特定的响应码
下面的响应码用于流传输:
Code
描述文本
发送CIP动作
200
MIME请求的接收和处理
无输出,继续会话
201
MIME请求的接收,处理与输出
请入以SMTP格式界定边界的响应
220
紧跟初始服务器标记信息
继续Whois交互,或核对CIP版本
222
关闭连接
完成操作
300
接收请求的CIP版本
在特定的版本下继续操作
400
暂时不能处理请求
过一会儿再试 。可以用于表示服务器现在没有资源接收索引
500
错误的MIME格式
以正确格式重试
501
未知或丢失请求
以正确的命令重试
502
请求没有需要的CIP属性
以正确的属性重试
520
因不明原因中断连接
通知本地治理员
530
请求需要合法的签名
对请求签名,假如可能重试,假如不能则向治理员报告问题
531
无效签名
报告治理员
532
无法检查签名
通知本地治理员,由他和远程的治理员协商处理问题
2.2 以邮件系统进行传输
除了TCP流以外,可以利用现有的邮件系统进行CIP操作 。这样可以减少对叶子服务器的压力,在进行TCP连接时叶子服务器中包括一个数据库和一个检索程序 。这样还可以有效地利用现有的网络技术 。因为使用MIME消息,而MIME也可以用邮件进行传输,这样我们就可以利用与TCP完全不同的方法完成CIP传输 。在使用邮件时基本请求和响应也是支持的 。下面会说明一些特定的情况,在这些情况下,应该对邮件传输CIP对象另加考虑 。通常,所有的邮件协议和邮件格式均可用于CIP邮件传输 。
2.2.1 确定CIP版本
因为在MIME信息中未说明使用的CIP版本,所以要在信件头中包括这一消息 。因此使用邮件传输时,必须包括CIP版本行,它的格式如下:
DIGIT = %x30-39
number = 1*DIGIT
cipversion = "CIP-Version:" number["." number]
2.2.2 返回路径
在双向流中进行CIP操作时,返回响应和错误是隐式的 。使用邮件对于确定接收者就有困难 。因为从信头有时不能确定谁发的信 。CIP要求发送方必须接收一个返回地址,假如没有,CIP服务器将忽略这一请求,只会在日志里记一笔 。接收方不能从信件的其它地方获得返回地址 。假如响应不能返回给请求,发送方应该将地址包括在

推荐阅读