CIP 传输协议
摘要
本文主要说明用于传输CIP请求/响应，索引对象，实现它们在TCP，邮件和HTTP上传输的三个协议。相关的资料请在其它资料中查询。
1. 协议
本节说明用于传输CIP索引对象和维护网结构。本文主要定义定义消息格式，传输机制。CIP协议的设计思想是一种块设计思想。它不依靠于许多于协议定义工具，或文本编码方式，而是利用现有的协议技术进行设计。这样可以使设计和实现简化。这也是利用现有的Internet技术实现应用层服务的方法。
2 MIME消息交换机制
CIP的消息交互是通过交换MIME消息进行的。消息在双向可靠传输的基础上进行。本文利用TCP，HTTP和邮件传输进行消息传输。CIP服务器开始连接，它称为发送CIP，而响应发送CIP的服务器称为接收CIP。
2.1 流传输
CIP在双向TCP连接上通过简单文本协议传输，它的操作可以在任何TCP端口上进行，因此配置信息也包括了主机名和端口号。发送CIP的动作由接收CIP的响应码加以确定。这些码的格式见下文。为了进行向后兼容Whois++服务器， CIPv3发送CIP必须首先确定支持新协议。通过发送下面非法的Whois++系统命令完成上述功能："# CIP-Version: 3"。在现在的Whois++服务器上，假如实现了CIP版本1或2，就会导致500系列的响应，服务器中断连接，假如服务器实现了CIPv3，它会响应300。这个300中的3代表版本3，以后的版本也可以利用这种方法。下面是一个交换的例子：
注重：假如发送CIP能够确定服务器实现了CIPv3，它可以发送"# CIP-Version: 3"串，然后跟一个CIPv3请求，这个优化在已知的同构CIP网结构中是有用的，这样可以避免等待。
一旦发送CIP确定服务器支持CIPv3请求，它可以以MIME格式发送请求，每个请求以""结束。
Cip-Req = Req-Hdrs CRLF Req-Body
Req-Hdrs = *( Version-Hdr Req-Cntnt-Hdr )
Req-Body = Body ; format of request body as in [CIP-MIME]
Body = Data CRLF "." CRLF
Data = ; data with CRLF "." CRLF replaced by CRLF ".." CRLF
Version-Hdr = "Mime-Version:" "1.0" CRLF
Req-Cntnt-Hdr = "Content-Type:" Req-Content CRLF
Req-Content = ; format is specified in [CIP-MIME]
Cip-Rsp = Rsp-Code CRLF [ Rsp-Hdrs CRLF Rsp-Body ] [ Indx-Cntnt-Hdr CRLF Index-Body ]
Rsp-Code = DIGIT DIGIT DIGIT Comment
Comment = ; any chars except CR and LF
Rsp-Hdrs = *( Version-Hdr Rsp-Cntnt-Hdr )
Rsp-Cntnt-Hdr = "Content-Type:" Rsp-Content CRLF
Rsp-Content = ; format is specified in [CIP-MIME]
Rsp-Body = Body ; format of response body as in [CIP-MIME]
Indx-Cntnt-Hdr = "Content-Type:" Indx-Obj-Type CRLF
Indx-Obj-Type = ; any registered index object's MIME-type the format is specified in [RFC2045]
Index-Body = Body ; format defined in each index specifications
CRLF = CR LF ; Internet standard newline
CR = %x0D ; carriage return
LF = %x0A ; linefeed
DIGIT = %x30-39
消息以SMTP形式结束，数据以字节传输，除了看到1*["."]，这种情况下要加一个句号。在数据传输结束时以"."表示。接收方要将结束标记略过。接收方的响应分为200，400和500系列。响应也以SMTP形式的消息界定。在返回响应后，接收CIP必须预备接收下一个请求，将状态返回到发送CIP刚刚确定版本时的状态。假如发送CIP不再发请求，则可以关闭连接。作为响应，接收CIP必须广放弃读入消息，并预备新的发送CIP连接。下面是一个例子，这里的行结束显式给出。中间的空间只为可读性而设置，注释在大括号内。
{ 发送CIP连接到接收CIP }
<<< % 220 Example CIP server ready
>>> # CIP-Version: 3
<<< % 300 CIPv3 OK!
>>> Mime-Version: 1.0
>>> Content-type: application/index.cmd.datachanged; type=
>>> 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 Whois++ server 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服务器将忽略这一请求，只会在日志里记一笔。接收方不能从信件的其它地方获得返回地址。假如响应不能返回给请求，发送方应该将地址包括在<>之内也放在返回地址中。我们不应该利用不能返回使错误信息不能返回，但有时这也是简化系统的一个好方法。
2.3 HTTP传输
HTTP也可用于传输CIP对象，操作可以使用POST方法进行，发送一个application/index.cmd，在HTTP应答中返回application/index.response或application/index.obj。URL是POST的目标，它也是CIP发送者和接收CIP之间配置参数的传输方法。下面是一个例子：
{ 客户打开连接发送POST }
>>> POST / HTTP/1.1
>>> Host: cip.some.corp
>>> Content-type: application/index.cmd.noop
>>> Date: Thu, 6 Jun 1997 18:16:03 GMT
>>> Content-Length: 2
>>> Connection: close
>>>
{ 服务器处理请求 }
<<< HTTP/1.1 204 No Content
{ 服务器关闭连接 }
利用HTTP时可以同时利用它的安全机制和其它属于HTTP的特点。CIP客户可以利用Accept-Charset和Accept-Language HTTP头来指定索引以特定的字符集返回。也可以使用Accept-Encoding来表示它可以处理压缩响应。也可以利用If-Modified-Since来防止在索引未改变的情况下再次传输再来的浪费。CIP服务器可以使用Retry-After要求客户过一会再进行请求。
3. 安全
索引信息有两层安全保护，一层是使用现有的安全MIME对象，另一层是利用现有的安全传输机制。我们上面已经说过了利用三种协议传输CIP对象，那这三个协议中的安全机制对安全传输CIP对象是有用的。
