直接因特网消息封装格式(DIME)(摘)

转载 2012年03月25日 20:55:06

原文地址:http://www.ibm.com/developerworks/cn/webservices/ws-dime/index.html#Ref8



简介: 直接因特网消息封装(Direct Internet Message Encapsulation,DIME)是一个轻量级二进制消息格式,可用于把任意类型和大小的一个或多个由应用程序定义的有效负载封装到单个消息构造中。每个有效负载用一个类型、一个长度和一个可选的标识符来描述。同时支持 URI 和 MIME 媒体类型构造作为类型标识符。有效负载的长度是一个整数,指出有效负载有多少个八位元。可选的有效负载标识符是一个 URI,通过它,有效负载之间可以进行交叉引用。DIME 有效负载在生成数据时可能包括嵌套的 DIME 消息或一串串链接在一起的未知长度的记录块。DIME 只是一种消息格式:它不提供连接或逻辑回路(logical circuit)的概念,它也没解决行首问题。

2.1. DIME 封装构造

2.1.1. 消息

一条 DIME 消息是由一条或多条 DIME 记录组成的。消息中的第一条记录是通过将 MB(Message Begin,消息开始)标记置位来表示的,消息中的最后一条记录是通过将 ME(消息结束)置位来标记的(请参阅第 3.2.1 和 3.2.3 节)。最短的消息长度是只有一条记录,这可以通过置位同一条记录中的 MB 和 ME 标志来标记。注意,要编码一个分块有效负载,至少需要两个记录块(请参阅第 2.1.3 节)。DIME 消息中可以携带的最大 DIME 记录条数不限。

DIME 消息绝不可以交迭;也就是说,绝不可以用 MB 和 ME 标志来嵌套 DIME 消息。通过使用“application/dime”类型在 DIME 记录内携带一条完整的 DIME 消息可以对 DIME 消息进行嵌套(请参阅第 6 节)。


图 1 

图 1:带一组记录的 DIME 消息示例。消息头在左,尾在右,逻辑记录索引为 t > s > r > 1。在第一条记录中(索引 1)将 MB(消息开始)标志置位,在最后一条记录中(索引 t)将 ME(消息结束)标志置位。

注意:实际的 DIME 记录并不带索引号;记录顺序是由序列化记录的顺序隐式给出的。

2.1.2. 记录

一条记录就是用来传送 DIME 消息内一个有效负载的单位。每个有效负载都用它自己的一组参数来描述(请参阅第 2.3 节)。

2.1.3. 记录块

记录块就是包含有效负载块的 DIME 记录。分块有效负载可以用于把动态生成的内容或非常大的实体分成多个连续的记录块,这些记录块在同一条 DIME 消息中被序列化。

分块不是一种用来将多路复用引入到 DIME 中的机制。它是一种在生成端限制出站缓冲需要的机制。它与 HTTP/1.1 [11] 中定义的消息分块机制类似。

一条 DIME 消息可以包含零个或多个分块有效负载。分块有效负载被编码为一个初始记录块,后跟零个或多个中间记录块,最后跟一个终止记录块。每个记录块都是用下列编码规则编码的:

  1. 初始记录块是一条 DIME 记录,并置位 CF(块标志)标志(请参阅第 3.2.4 节)。整个分块有效负载的类型必须在 TYPE 字段中指出,不管 DATA_LENGTH 字段的值是零还是非零。ID 字段可以用于携带整个分块有效负载的标识符。DATA_LENGTH 字段指出 DATA 字段中携带的数据的长度(请参阅第 2.3.1 节)。

  2. 每个中间记录块都是一条 DIME 记录,并置位 CF 标志,用来指出这个记录块包含相同类型数据的下一个块,并且它的标识符与初始记录块的标识符相同。TYPE_LENGTH 和 ID_LENGTH 字段的值必须为零,TYPE_T 字段的值必须为 0x00(请参阅第 3.2.8 节)。DATA_LENGTH 字段指出 DATA 字段中携带的数据的长度(请参阅第 2.3.1 节)。

  3. 终止记录块是一条 DIME 记录,它的 CF 标志被清零,表明这条记录块包含相同类型数据的最后一个块,并且它的标识符与初始记录块的标识符相同。与中间记录块一样,TYPE_LENGTH 和 ID_LENGTH 字段的值必须为零,TYPE_T 字段的值必须为 0x00(请参阅第 3.2.8 节)。DATA_LENGTH 字段指出 DATA 字段中携带的数据的大小(请参阅第 2.3.1 节)。

一个分块有效负载必须整个封装在一条 DIME 消息中。也就是,一个分块有效负载绝不可以跨越多条 DIME 消息。结果,初始记录块和中间记录块都不能将其 ME(消息结束)标志置位。

3. DIME 规范

3.1. 数据传输顺序

本文档中描述的 DIME 记录的传输顺序设定到八位元级。对于显示一组八位元的图表,那些八位元的传输顺序是先从左到右,然后再自上而下,正如英文的阅读顺序一样。例如,在图 2 的图表中,按照八位元的编号顺序对它们进行传输。


图 2:DIME 八位元排序
图 2 

只要八位元表示的是一个数量,那么图表中最左边的位就是高阶位,或者说是最重要的位。也就是说,标号为 0 的位是最重要的位。

对于 DIME 定义的每个表示数量的多八位元字段,整个字段的最左边的位是最重要的位。这种数量以大尾数法的方式传输,先传最重要的八位元。

3.2. 记录布局

DIME 记录的长度可变,常用格式如图 3 所示。在下面几节中,将更详细地描述各个记录字段。


图 3: DIME 记录布局。使用“/”表明一个字段的长度是 4 个八位元的倍数。
图 3 

3.2.1. 版本

一个指出 DIME 记录格式的 5 位的无符号整数(请参阅第 2.2 节)。这个文档定义了版本 1(0x01)。一个遵守本规范的 DIME 生成器必须生成 VERSION 字段值为 0x01 的 DIME 消息。一个遵守本规范的 DIME 解析器必须验证 VERSION 字段的值是否为 0x01。

3.2.2. MB(消息开始)

MB 标志是一个 1 位字段,当它被置位时,表明 DIME 消息的开始(请参阅第 2.1.1 节)。

3.2.3. ME(消息结束)

ME 标志是一个 1 位字段,当它被置位时,表明 DIME 消息的结束(请参阅第 2.1.1 节)。注意,对于分块有效负载,只在最后一个分块有效负载的终止记录块中将 ME 标志置位(请参阅第 2.1.3 节)。

3.2.4. CF(块标志)

CF 标志是一个 1 位字段,用来指出这是分块有效负载的第一个记录块还是中间记录块(关于如何对分块有效负载进行编码的描述,请参阅第 2.1.3 节)。

3.2.5. TYPE_T

TYPE_T 字段的值指出 TYPE 字段值的结构和格式(请参阅第 2.3.2 节看一下关于 TYPE 字段的描述,并参阅第 4 节看一下有关 TYPE 字段的国际化问题的描述)。TYPE_T 字段是一个 4 位的字段,下表中定义了它的值:


表 1:DIME TYPE_T 字段的值。
表 1 

必须在分块有效负载所使用的所有中间记录块和终止记录块中使用值 0x00(不变,Unchanged)(请参阅第 2.1.3 节)。它绝不可以用在任何其它记录中。在使用这个值时,TYPE_LENGTH 字段的值必须为零。

值 0x01(媒体类型,media-type)指出 TYPE 字段包含一个值,该值遵守 RFC 2616 [11] 定义的“media-type”BNF 构造(请参阅第2.3.2 节)。

值 0x02(绝对 URI,absoluteURI)指出 TYPE 字段包含一个值,该值遵守 CRF 2396 [10] 定义的“absoluteURI”BNF 构造(请参阅第2.3.2 节)。

值 0x03(未知,Unknown)应该被用来指出有效负载的类型是未知的。这与 MIME [7] 定义的“application/octet-stream”媒体类型相似。在使用这个值时,TYPE_LENGTH 字段的值必须为零。关于实现,“建议”接收这种类型 DIME 记录的 DIME 解析器提供一种机制来存储但不是处理这种有效负载(请参阅第 5 节)。

值 0x04(无,None)指出没有与这个记录相关的类型或有效负载。在使用这个值时,TYPE_LENGTH 和 DATA_LENGTH 字段的值必须为零。只要需要空记录,就可以使用这个 TYPE_T 值,例如,为终止一条 DIME 消息(在该消息中用户应用程序没有定义任何有效负载),就可以使用这个 TYPE_T 值。

TYPE_T 字段没有缺省值。保留的(Reserved)TYPE_T 字段值是供将来使用的,现在绝不可以使用。一个 DIME 解析器如果接收到一条带未知 TYPE_T 字段值的 DIME 记录,那么这个解析器应该把有效负载当作已经用值 0x03(未知)做了标记一样。注意:在这种情况下不要求 TYPE_LENGTH 为零。

3.2.6. RESRVD

RESRVD 字段是保留以供将来使用的字段,必须将其设置为 0x00。如果一个 DIME 解析器接收到一条 DIME 记录,而该记录的 RESRVD 字段值不是 0x00,那么这个解析器必须将这条消息作为错误的消息废弃。

3.2.7. OPTIONS_LENGTH

一个 16 位的无符号整数,它以八位元为单位指定 OPTIONS 字段的长度,这个长度不包括用于对齐 OPTIONS 字段的 4 个八位元的任何填充部分(请参阅第 2.4 节)。

3.2.8. ID_LENGTH

一个 16 位的无符号整数,它以八位元为单位指定 ID 字段的长度,这个长度不包括用于对齐 ID 字段的 4 个八位元的任何填充部分(请参阅第 2.3.3 节)。

3.2.9. TYPE_LENGTH

一个 16 位的无符号整数,它以八位元为单位指定 TYPE 字段的长度,这个长度不包括用于对齐 TYPE 字段的 4 个八位元的任何填充部分(请参阅第 2.3.2 节)。

3.2.10. DATA_LENGTH

DATA_LENGTH 字段是一个 32 位无符号整数,它以八位元为单位指定 DATA 字段的长度,这个长度不包括用于对齐 TYPE 字段的 4 个八位元的任何填充部分(请参阅第 2.3.1 节)。

允许有效负载的大小为 0 个八位元。通过使用分块有效负载可以容许有效负载大于 2^32-1 个八位元(请参阅第 2.1.3 节)。

3.2.11. OPTIONS

OPTIONS 字段包含零个或多个选项元素,其中每个元素都遵守图 4 中的布局(请参阅第 2.4 节,看一下选项元素的描述)。


图 4:DIME 选项元素的布局。使用“/”表明一个字段的长度是 4 个八位元的倍数。
图 4 

所有的 DIME 记录都可以有一个非零的 OPTIONS 字段。DIME 解析器在接收到一条 DIME 记录,而该记录的选项元素类型无法识别时应该忽略该元素(请参阅第 6.2 节了解关于新选项元素类型的 IANA 注册指南)。

每个元素的长度不必一定是 4 个八位元的倍数,在元素间没有填充部分。但 OPTIONS 字段的大小必须是 4 个八位元的倍数。如果所有元素的长度之和不是 4 个八位元的倍数,那么生成器必须用全零八位元填充 OPTIONS 字段的值。填充部分不包括在 OPTIONS_LENGTH 字段中(请参阅第 3.2.7 节)。

DIME 生成器绝不可以用超过 3 个的八位元填充 OPTIONS 字段。DIME 解析器必须忽略填充的八位元。

3.2.12. ID

ID 字段的值是一个标识符,以 URI [10] 的形式出现(请参阅第 2.3.3 和 3.3 节)。消息标识符必需的唯一性由生成器来保证。这里的 URI 可以是相对 URI,也可以是绝对 URI;DIME 并不定义基本 URI,这意味着使用相对 URI 的用户应用程序必须提供一个实际的或虚拟的基本 URI(请参阅 [10])。

除后续的记录块(请参阅第 2.1.3 节)外,所有的记录都可以有非零的 ID 字段。

ID 字段的长度必须是 4 个八位元的倍数。如果有效负载 id 值的长度不是 4 个八位元的倍数,那么生成器必须用全零八位元填充该值。填充部分并不包括在 ID_LENGTH 字段中(请参阅第 3.2.8 节)。

DIME 生成器绝不可以用超过 3 个的八位元填充 ID 字段。DIME 解析器必须忽略填充的八位元。

3.2.13. TYPE

TYPE 字段的值是一个标识符,它描述有效负载的类型(请参阅第 2.3.2 节)。TYPE 字段的值必须遵守 TYPE_T 字段的值所暗示的结构(请参阅第 3.2.5 节)。

TYPE 字段的长度必须是 4 个八位元的倍数。如果有效负载类型值的长度不是 4 个八位元的倍数,那么生成器必须用全零八位元填充该值。填充部分并不包括在 TYPE_LENGTH 字段中(请参阅第 3.2.9 节)。

DIME 生成器绝不可以用超过 3 个的八位元填充 TYPE 字段。DIME 解析器必须忽略填充的八位元。

如果一个 DIME 解析器接收到一条 DIME 记录,而该记录的 TYPE_T 字段值已知但 TYPE 字段值未知,那么这个解析器在解释这条记录的类型标识符时,应该把 TYPE_T 的字段值当作 0x03(未知)。

强烈推荐:标识符应该是全局唯一的,并且一直用稳定的、定义良好的语义维护。

3.2.14. DATA

DATA 字段携带用于 DIME 用户应用程序的有效负载。DATA 字段内携带的数据的内部结构对 DIME 是不透明的。

DATA 字段的长度必须是 4 个八位元的倍数。如果有效负载的长度不是 4 个八位元的倍数,那么生成器必须用全零八位元填充该值。填充部分并不包括在 DATA_LENGTH 字段中(请参阅第 3.2.10 节)。

DIME 生成器绝不可以用超过 3 个的八位元填充 DATA 字段。DIME 解析器必须忽略填充的八位元。


相关文章推荐

【Linux网络编程】因特网的IP协议是不可靠无连接的,那为什么当初不直接把它设计为可靠的?

因特网使用的IP协议是无连接的,因此其传输是不可靠的。这样容易使人们感到因特网很不可靠,那为什么当初不直接把它设计为可靠的? 先打一个比方。邮局寄送的平信很像无连接的IP数据报。每封...

因特网的IP协议是不可靠无连接的,那为什么当初不直接把它设计为可靠的?

因特网使用的IP协议是无连接的,因此其传输是不可靠的。这样容易使人们感到因特网很不可靠,那为什么当初不直接把它设计为可靠的? 先打一个比方。邮局寄送的平信很像无连接的IP数据报。每封平信可能走...

因特网的IP协议是不可靠无连接的,那为什么当初不直接把它设计为可靠的?

因特网使用的IP协议是无连接的,因此其传输是不可靠的。这样容易使人们感到因特网很不可靠,那为什么当初不直接把它设计为可靠的? 先打一个比方。邮局寄送的平信很像无连接的IP数据报。每封平信可能走不同...

jsr180 sip格式消息封装

  • 2009-03-19 10:02
  • 3.50MB
  • 下载

SDK中CreateWindow直接发送消息至WindowProc/vs2008项目转换成vs2005项目

先上经典例子:

data类型的Url格式:把小数据直接嵌入到Url中

原文地址:   data类型的Url格式:把小数据直接嵌入到Url中 所谓"data"类型的Url格式,是在RFC2397中提出的,目的对于一些“小”的数据,可以在网页中直接...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

(最多只允许输入30个字)