Table of Contents Previous Next
Logo
The Ice Protocol : 34.6 A Comparison with IIOP
Copyright © 2003-2008 ZeroC, Inc.

34.6 A Comparison with IIOP

It is interesting to compare the Ice protocol and encoding with CORBA’s Inter-ORB Interoperability Protocol (IIOP) and Common Data Representation (CDR) encoding. The Ice protocol and encoding differ from IIOP and CDR in a number of important respects:
• Fewer data types
CORBA IDL has data types that are not provided by Ice, such as characters and wide characters, fixed-point numbers, arrays, and unions, each of which require a separate set of encoding rules.
Obviously, fewer data types makes the Ice encoding more efficient and less complex than CDR.
• Fixed byte-order marshaling
CDR supports both big-endian and little-endian encoding and provides a "receiver-makes-it-right" approach to byte ordering. The advantage of this is that, if sender and receiver have matching byte order, no reordering of the data is required at either end. However, the disadvantage is the additional complexity this creates in the marshaling logic. Moreover, the "receiver-makes-it-right" scheme carries a severe performance penalty if messages are to be forwarded via a number of intermediaries because this can require repeated unmarshaling, reordering, and remarshaling of messages. (Encapsulating the data would avoid this problem but, unfortunately, IIOP does not encapsulate most of the data that would benefit from it.)
The Ice encoding uses fixed little-endian data layout and avoids both the complexity and performance penalty.
• No padding
CDR has a complex set of rules for inserting alignment bytes into a data stream in an attempt to keep data aligned in a way that suits the native data layout of the underlying hardware. Unfortunately, this approach is severely flawed for a number of reasons:
The CDR padding rules actually do not achieve any layout on natural word boundaries. For example, depending on its relative position in the enclosing data stream, the same structure value can differ in size and padding by up to seven bytes. There is not a single hardware platform in existence whose layout rules are the same as those of CDR. As a result, the padding bytes that are inserted serve no purpose other than to waste bandwidth.
With "receiver-makes-it-right", the receiver is obliged to re-order data if it arrives in the incorrect byte order anyway. This means that any alignment of the data (even if it were correct) is useless to, on average, half of all receivers because re-ordering of the data requires copying all of the data anyway.
Padding and alignment rules differ depending on the hardware platform as well as the compiler. (For example, many compilers provide options that change the way data is packed in memory, to allow the developer to control the time-versus-space trade-off.) This means that even the best set of layout rules can suit only a minority of platforms.
Data alignment rules greatly complicate data forwarding. For example, if the receiver of a data item wants to forward that data item to another down-stream receiver, it cannot just block-copy the received data into its transmit buffer because the padding of the data is sensitive to its relative position in the enclosing byte stream and a block copy would most likely result in an illegal encoding.
Ice avoids all the complexity (and concomitant inefficiency) by aligning all data on byte boundaries.
• More compact encoding
CDR encoding rules are wasteful of bandwidth, especially for sequences of short data items. For example, with CDR encoding, an empty string occupies eight bytes: four bytes to store the string length, plus a single terminating NUL byte, plus three bytes of padding. Table 34.20 compares the encoding sizes of CDR and the Ice encoding for sequences of 100 strings for different string lengths.
Sequence of 100 Strings of Length
Similar savings are achieved for small structures. Depending on the order and type of the structure members, CDR padding bytes can almost double the structure size, which becomes significant when sending sequences of such structures.
• Simple proxy encoding
Due to the inability of CORBA vendors to agree on a common encoding for object references (the equivalent of Ice proxies), CORBA object references have a complex internal structure that is partially standardized and partially opaque, allowing vendors to add proprietary information to object references. In addition, to avoid object references getting too large, references that support more than one transport have a scheme for sharing the object identity among several transports instead of carrying multiple copies of the same identity. The encoding that is required to support all this machinery is quite complex and results in extremely poor marshaling performance when large number of object references are exchanged (for example, when using a trading service).
In contrast, Ice proxies are simple and straight-forward to marshal and do not incur this loss of performance.
• Proper version negotiation
Versioning for IIOP and CDR was never designed properly, with the result that version negotiation in IIOP simply does not work. In particular, CDR encapsulations do not carry a separate version number. As a result, it is possible for data in encapsulations to travel to receivers that cannot decode the contents of the encapsulation, with no mechanism at the protocol level to detect the problem. Lack of correct versioning has been an ongoing problem with CORBA for years and the problem has historically been dealt with by pretending that it does not exist (meaning that different CORBA versions cannot interoperate with each other in many circumstances).
The Ice protocol and encoding have well-defined versioning rules that avoid such problems, allow both protocol and encoding to be extended, and reliably detect version mismatches.
• Fewer message types
IIOP has more message types than Ice. For example, IIOP has both a cancel request and a message error message. The cancel request is meant to cancel an invocation in progress but, of course, cannot do that because there is no way to abort an executing invocation in the server. At best, a cancel request allows the server to avoid marshaling the results of an invocation back to the client. However, the additional complexity introduced into the protocol is not worth the saving. (And, at any rate, neither is there a way for an application developer to send a cancel request, nor can the run time decide on its own when it would be appropriate to send one; despite that, every compliant CORBA implementation is burdened by the need to correctly respond to a useless request.)
IIOP’s message error message constitutes similar baggage: the receiver of a malformed message is obliged to respond with a message error message before closing its connection. However, the message carries no useful information and, due to the nature of TCP/IP implementations, is usually lost instead of being delivered. This means that a compliant CORBA implementation is forced to send a useless message that will not be received in most cases when, instead, it should simply close the connection.
Ice avoids any such baggage in its protocol: the messages that are used actually serve a useful purpose.
• Request batching
IIOP has no notion of request batching. The advantages of request batching are particularly noticeable for event forwarding mechanisms, such as IceStorm (see Chapter 41), as well as for fine-grained interfaces that provide modifier operations for a number of attributes. Request batching significantly reduces networking overhead for such applications.
• Reliable connection establishment
IIOP is vulnerable to connection loss during connection establishment. In particular, when a client opens a connection to a server, the client has no way of knowing whether the server is about to shut down and will not be able to process an incoming request. This means that the client has no choice but to send a request on a newly-established connection in the hope that the request will actually be processed by the server. If the server can process the request, there is no problem. However, if the server cannot process the request because it is on its way down, the client is confronted with a broken connection and cannot re‑issue the request because that might violate at‑most-once semantics.
Ice does not have this problem because the validate connection message ensures that the client will not send a request to a server that is about to shut down. Moreover, any requests with outstanding replies can safely be re‑issued by the client without violating at‑most-once semantics.
• Reliable endpoint resolution
Indirect binding (see page 15) in IIOP relies on a locate forward reply. Briefly, endpoint resolution is transparent to clients using IIOP. If an object reference uses indirect binding, the client issues the request as usual and receives a locate forward reply containing the endpoint of the actual server. In response to that reply, the client issues the request a second time to contact the actual server. There are a number of problems with this scheme:
The physical address of the location service is written into each indirectly bound object reference. This makes it impossible to move the location service without invalidating all the references held by clients.1
Ice does not have this problem because the location service is known to clients through configuration. If the location service is moved, clients can be updated by changing their configuration and there is no need to track down a potentially unlimited number of proxies that might be out of date. Moreover, there is typically no need to move the location service. Instead, it is possible to construct federated location services that work similar to the Internet Domain Name Service (DNS) and internally forward requests to the correct resolver.
In order to get a location forward message, clients send the actual request to the location service. This is expensive if the request parameters are large because they are marshaled twice: once to the location service and once to the actual server. IIOP adds a locate request message that allows a client to explicitly resolve the location of a server. However, CORBA object references carry no indication as to whether they are bound directly or indirectly. This means that, no matter what the client does, it is wrong some of the time: if the client always uses a locate request with a directly bound reference, it ends up incurring the cost of two remote messages instead of one; if the client sends the request directly with an indirectly bound reference, it incurs the cost of marshaling the parameters twice instead of once.
Ice makes location resolution a step that is explicitly visible to the client-side run time because proxies either carry endpoint information (for direct proxies) or symbolic information (for indirect proxies). This allows the client-side run time to select the correct resolution mechanism without having to play guessing games and to avoid the overhead incurred by location forwarding.
With IIOP, location resolution is built into the protocol itself. This complicates the protocol with two additional message types and (until 2002, when additional APIs were added to CORBA) made it impossible to implement a location service using standard APIs.
With Ice, no special protocol support is required for location resolution. Instead, the location service is an ordinary Ice server that defines an interface as usual and is contacted using operation invocations like any other server.
• No codeset negotiation
IIOP uses a codeset negotiation feature that (supposedly) permits use of arbitrary character encodings for transmission of wide characters and strings, provided sender and receiver have at least one codeset in common. Unfortunately, this feature was never properly thought through and has repeatedly led to interoperability problems. (Every single version of the CORBA specification, including the latest 3.0 version, has made corrections to the way codeset negotiation is supposed to work. Whether the latest set of corrections will succeed in dealing with the problem remains to be seen. Regardless, many pages of complexity (and many lines of ORB source code) are devoted to this (mis)feature.)
The UTF‑8 encoded Unicode used by Ice avoids all these problems without losing any functionality.
• No fragmentation
IIOP provides a fragment message whose purpose is to reduce memory overhead in the server during marshaling of the results of an operation invocation. Unfortunately, the feature is quite complex (having been mis-specified and mis-implemented repeatedly in the past). The savings to be gained through fragmentation are quite limited, yet every client-side ORB implementation is forced to provide support for the feature. (In other words, the cure is worse than the disease.)
Ice does not use a fragmentation scheme, avoiding both the complexity and the resulting code bloat.
• Support for connection-less transports
In 2001, the OMG adopted a multi-cast specification. To the best of our knowledge, as of early 2003, no implementations of that specification are available.
Ice offers UDP as an alternative to TCP/IP. For messaging services, such as IceStorm, the performance benefits of UDP are considerable, allowing the service to scale well beyond what could be achieved with TCP/IP.

1
IIOP version 1.2 supported a message to indicate permanent location forwarding. That message was meant to ease migration of location services. However, the semantics of that message broke the object model elsewhere, with the result that IIOP version 1.3 has deprecated that message again. (Unfortunately, reversals such as this are all too common in OMG specifications.)

Table of Contents Previous Next
Logo