ICE Manual(Documentation for Ice 3.5)---The Ice Protocol（与IIOP对比)

对Ice 的协议及编码和CORBA 的Inter-ORB Interoperability Protocol(IIOP) 及Common Data Representation (CDR) 编码进行对比，是一件有意思的事情。Ice 协议及编码在许多重要方面都与IIOP 及CDR 不同：

• 数据类型更少

CORBA IDL 的有些数据类型在Ice 中没有提供，比如字节和宽字符、定点数、数组 、联合，这些数据类型都需要有自己的编码规则。显然，因为Ice 的数据类型更少，所以它比CORBA 更高效，复杂度也更低。

• 固定的字节序整编

CDR 既支持"big-endian" 编码，也支持"little-endian" 编码，并且提供了一种“由接收者负责使其正确”的字节序处理方法。其优点是，如果发送者和接收者的字节序是一样的，那么两端都不需要调整数据的次序。但是，其缺点是这种方案会在整编逻辑中制造额外的复杂性。而且，如果消息要通过许多中间节点进行转发，这种方案会付出严重的性
能代价，因为消息可能需要反复进行解编、调整次序，重整编( 封装数据可以避免这个问题，但遗憾的是，IIOP 没有封装大多数本可以由此获益的数据)。
Ice 编码使用的是固定的"little-endian" 数据布局，从而避免了付出复杂性和性能方面的代价。

• 不进行填充

CDR 有一组复杂的规则，用于把对齐字节插入数据流中，让数据以某种方式进行对齐，从而适应底层应用的原生数据布局。遗憾的是，由于一些原因，这种做法有严重的缺陷：
• CDR 填充规则实际上并没有获得任何自然的字边界布局。例如，取决于同样的结构值在它所属的数据流中的位置，这个值的尺寸可能会发生变化，并最多填充七个字节。在现有的硬件平台中，没有一种具有与此类似的布局规则。结果，除了浪费带宽，所插入的填充字节没有任何用处。
• 在使用“由接收者负责使其正确”方案时，如果到达的数据的字节序不正确，接收者要负责调整数据的次序。这意味着，对大约一半的接收者而言，数据的对齐（即使是正确的）是没有用的，因为调整数据的次序无论如何都需要复制所有数据。
• 取决于硬件平台以及编译器的不同，填充和对齐规则也有所不同（例如，为了让开发者平衡时间和空间开销，许多编译器都提供了一些选项，用以改变数据在内存中的打包方式）。这意味着，即使是最好的布局规则，也只适合少数平台。
• 数据对齐规则使得数据转发变得十分复杂。例如，如果某个数据项的接收者想要把它转发给另一个下游接收者，它不能简单地把接收到的数据块复制到它的传送缓冲区中，因为数据的填充方式会因它在所属字节流中的位置而发生变化，如果你进行块复制，很可能会产生非法的编码。通过在字节边界上对齐所有数据， Ice 避免了所有这些复杂性（以
及后继的低效）。

•更紧凑的编码

CDR 编码会浪费带宽，特别是在对短数据项的序列进行编码时。例如，使用CDR 编码，一个空串会占用八个字节：四个字节存储串长，一个字节用于结尾的NUL 字节，再加上三个填充字节。表18.19 对比了使用CDR 和Ice、对100 个长度不同的串的序列进行编码 的编码尺寸。小结构也能获得类似的节省。取决于结构成员的次序和类型， CDR
填充字节可能会使结构尺寸几乎翻倍，在发送这样的结构的序列时，这样的翻倍影响重大。

• 简单的代理编码

由于CORBA 供应商无法就对象引用（Ice 代理的等价物）的编码达成一致， CORBA 对象引用的内部结构很复杂，部分进行了标准化，部分是不透明的，这样，供应商才能够给对象引用添加私有信息。此外，为了避免对象引用变得太大，支持多种传输机制的引用使用了一种方案，在若干传输机制间共享对象标识，而不是携带同一标识的多个副本。支持所有这些机制所需的编码相当复杂，结果在交换大量对象引用时（例如，在使用trading 服务的情况下），整编性能极其低下。与此相反， Ice 代理的整编简单、直截了当，不会造成这样的性能下降。

• 适当的版本磋商

IIOP 和CDR 的版本机制从未得到适当设计，造成的结果是， IIOP中的版本磋商完成无法工作。特别地， CDR 封装没有携带单独的版本号。结果，封装的数据有可能会传送到不能正确解码封装的内容的接收者那里，而在协议级没有机制可用于检测该问题。多年来，缺少正确的版本机制一直是CORBA 的一个问题，而在历史上，这个问题的处理办
法一直是，假装它并不存在（也就是说，在许多情况下，不同的CORBA 版本不能进行互操作）。Ice 协议和编码有着明确定义的版本规则，能够避免这样的问题，从而使得协议和编码都能够进行扩展，并且能可靠地检测版本失配。

• 消息类型更少

IIOP 的消息类型比Ice 要多。例如， IIOP 既有取消请求消息，也有消息错误消息。取消请求的用途是取消正在执行的调用，但那当然无法做到，因为没有什么办法能中止正在服务器中执行的调用。取消请求最多能让服务器不要再整编调用的结果发回客户。但是，这并不值得在协议中引入那么多额外的复杂性（而且，无论如何，应用开发者既无法
发送取消请求， run time 也不能自行决定何时发送取消请求才合适；尽管如此，每一个遵从标准的CORBA 实现都要承受负担，正确地响应一个无用的请求）。IIOP 的消息错误消息也有类似的负担：接收到有问题的消息的接收者有义务在关闭其连接之前、发送一个消息错误消息作为响应。但是，
这种消息没有携带有用的信息，而且，由于TCP/IP 实现的本质，常常
会丢失，而不是到达对端。这意味着，一个遵从标准的CORBA 实现会
被迫发送一条无用的消息（它本应该简单地关闭连接），在大多数情况
下，这条消息不会被收到。
在Ice 协议中没有这样的负担：所用的消息都的确是有用的。
• 批请求
IIOP 没有批请求的概念。对于像IceStorm ( 参见第26 章) 这样的事
件转发机制，以及为许多属性提供修改器操作的细粒度接口，批请求的
好处特别值得一提。对于这样的应用，批请求能够显著地降低网络开
销。