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这样的事件转发机制，以及为许多属性提供修改器操作的细粒度接口，批请求的好处特别值得一提。对于这样的应用，批请求能够显著地降低网络开销。

• 可靠的连接建立

IIOP 很容易受到连接建立过程中发生的连接丢失的影响。特别地，当客户打开一个通向服务器的连接时，客户无法知道服务器是否正要关闭、将无法处理进入的请求。这意味着，客户别无选择，只能在新建立的连接上发送一个请求，希望这个请求能被服务器实际处理。如果服务器能够处理该请求，没有问题；但如果服务器因为正在关闭而无法处理
该请求，客户面临的就是一个坏掉的连接，并且不能再重发该请求，因为那可能会违反“最多一次”语义。Ice 没有这个问题，因为验证连接消息保证了客户不会把请求发给正
要关闭的服务器。而且，客户可以安全地重发任何没有得到答复的请求，而不会违反“最多一次”语义。

• 可靠的端点解析

IIOP 中的间接绑定依赖于定位转发答复。简要地说，端点解析对于使用IIOP 的客户而言是透明的。如果对象引用使用了间接绑定，客户像平常一样发出请求，将收到一个定位转发答复，其中含有实际服务器的端点。客户对该请求作出响应，再次发出请求，联系实际的服务器。这种方案有一些问题：
• 定位服务的物理地址是写在每个间接绑定的对象引用中的。这样，如果定位服务的地址变了，客户持有的所有引用都会失效3。Ice 没有这样的问题，因为客户是通过配置获得定位服务器的地址的。如果定位服务的地址变了，可以通过改变客户的配置来更新客户，无需去追踪那些可能已失效的、数目不定的代理。而且，定位服务通常没有必要改变地址，你可以构造与Internet Domain Name Service(DNS) 类似的定位服务联盟，在内部把请求转发给正确的解析器。
• 为了获得定位转发消息，客户要把实际的请求发送给定位服务。如果请求参数很多，这就会很昂贵，因为这些参数会被整编两次：一次是给定位服务，一次是给实际的服务器。IIOP 增加了一个定位请求消息，允许客户显式地解析服务器的地址。但是， CORBA 对象引用没有携带什么指示，说明它们是直接绑定的，还是间接绑定的。这意味着，不管客户做什么，总有一些时候是错的：如果在使用直接绑定的引用时，客户总是使用定位请求，它最后就会付出发送两个、而不是一个远地消息的代价；如果在使用间接绑定的引用时，客户总是直接发送请求，它就会付出两次、而不是一次整编参数的代价。Ice 让定位解析变成了客户端run time 可以明确看到的一个步骤，因为代理不是携带了端点信息( 直接代理)，或者携带了适配器名( 间接代理)。这样，客户端run time 就能够选择正确的解析机制，而不必进行猜测游戏，从而避免定位转发所造成的开销。
• 在IIOP 中，定位解析被构建进协议自身之中。这使得协议变复杂了，多了两种消息类型，而且，也造成实现者不可能使用标准API 来实现定位服务（直到2002 年， CORBA 增加了另外的API 之后，这一局面才改变）。在Ice 中，定位解析无需特殊的支持。相反，定位服务是一个普通的Ice 服务器，和其他服务器一样，它定义了一个接口，要访问它也是使用操作调用。
【IIOP 1.2 版支持一种指示永久的定位转发的消息。这种消息意在使定位服务的迁移变得轻松一点。但是，该消息的语义在别处破坏了对象模型，致使IIOP 1.3 版不赞成使用该消息( 遗憾的是，像这样的反复无常在OMG 规范中太常见了)。】

• 没有代码集磋商

IIOP 使用了一种代码集磋商机制，（大概）允许 开发者使用任意的字符编码来传送宽字符和宽串，前提是发送者和接收者至少拥有一个共同的 代码集。遗憾的是，这种特性从未得到过适当的思考，而且反复地造成了各种互操作问题（CORBA 规范的每一个版本，包括最新的3.0 版，都对字符集磋商的工作方式进行了更正。最新的更正是否能成功处理那些问题，还有待于时间来证明。无论如何，为了这个（成问题的）特性， CORBA 规范用了许多页复杂的文档（以及许多行ORB源码）来加以处理。Ice 使用的以UTF-8 方式编码的Unicode 避免了所有这些问题，而且没有损失任何功能。

• 没有分段

IIOP 提供了一个分段消息，其目的是，在整编操作调用的结果的过程中，降低服务器的内存开销。遗憾的是，这个特性相当复杂（在过去被反复地错误规定和实现）。通过分段所节省的内存相当有限，而每一个客户端ORB 实现都被迫为这个特性提供支持（换句话说，治疗比疾病还要糟）。Ice 没有使用分段方案，既避免了复杂性，也避免了代码膨胀。

• 支持无连接的传输机制

在2001 年， OMG 采用了一种多播规范。就我们所知，到2003 年初，还没有该规范的实现可用。Ice 支持UDP，作为TCP/IP 的替代品。对于像IceStorm 这样的消息服务而言， UDP 在性能上的优越性相当可观，所以这样的服务的可伸缩性可以远远超过TCP/IP。