ICE Manual(Documentation for Ice 3.5)---The Ice Protocol（Protocol and Encoding Versions)

Version Flexibility

As we saw in the preceding sections, both the Ice protocol and encoding have separate major and minor version numbers. Separate versioning of protocol and encoding has the advantage that neither depends on the other: any version of the Ice protocol can be used with any version of the encoding, so they can evolve independently. For example, you could send a request with Ice protocol version 1.1, and encode the parameters with encoding version 2.3.

The Ice versioning mechanism provides the maximum possible amount of interoperability between clients and servers that use different versions of the Ice run time. In particular, older deployed clients can communicate with newer deployed servers and vice versa, provided that the message contents use types that are understandable to both sides. Intermediary servers, such as a Glacier2 router, do not and should not check the contents of the requests and responses they forward; this way, an older intermediary server can forward messages encoded with a newer encoding that it does not understand.

Due to a bug, a Glacier2 router prior to version 3.5 can only forward messages encoded using the 1.0 encoding.

Ice 3.5 introduced a new encoding, encoding version 1.1, in support of several new features such as the ability to define optional parameters in operations. In order to send a request with an optional parameter, you need to use encoding 1.1 or greater.

Ice 3.5 is capable of marshaling and unmarshaling messages with both the 1.0 and 1.1 encodings (it uses the 1.1 encoding by default). This allows interoperability to the maximum extent possible:

Client Ice Version

Server Ice Version

Encoding Version

Operation without Optional Parameter

Operation with Optional Parameter

3.4 or earlier

3.4 or earlier

1.0

Yes

No

3.4 or earlier

3.5

1.0

Yes

No

3.5

3.4 or earlier

1.0

Yes

No

3.5

3.5

1.1

Yes

Yes

When an Ice 3.5 client sends a request to an Ice 3.4 server, it must naturally use the 1.0 encoding. This is achieved by setting correctly (and often automatically) the encoding version on the proxy used. If this proxy is received by the client through a response using the 1.0 encoding, the decoded proxy will automatically have the desired 1.0 encoding (all proxies in a 1.0-encoded message implicitly have 1.0 as their encoding version and 1.0 as their protocol version). If this proxy is created with stringToProxy or propertyToProxy, the client will need to set this proxy's encoding version to 1.0 through one of the following methods:

• with -e 1.0 in the source stringified proxy
• by creating a new proxy with the desired encoding version, by calling ice_encodingVersion("1.0") on the proxy
• by setting Ice.Default.EncodingVersion to 1.0.   

Version Ground Rules

For versioning of the protocol and encoding to be possible, all versions (present and future) of the Ice run time adhere to a few ground rules:

1. Encapsulations always have a six-byte header; the first four bytes are the size of the encapsulation (including the size of the header), followed by two bytes that indicate the major and minor version. How to interpret the remainder of the encapsulation depends on the major and minor version.
2. The first eight bytes of a message header always contain the magic number 'I', 'c', 'e', 'P', followed by four bytes of version information (two bytes for the protocol major and minor number, and two bytes for the encoding major and minor number). How to interpret the remainder of the header and the message body depends on the major and minor version.

These ground rules ensure that all current and future versions of the Ice run time can at least identify the version and size of an encapsulation and a message. This is particularly important for message switches such as IceStorm; by keeping the version and size information in a fixed format, it is possible to forward messages that are, for example, at version 2.0, even though the message switch itself may still be at version 1.0.

版本兼容规则

要想确定某个协议版本是否与另一个协议版本兼容( 或某个编码版本是否与另一个编码版本兼容)，要考察以下规则：
1. 不同的大版本是不兼容的。客户和服务器都没有义务支持一种以上的大版本。例如，大版本是2 的服务器完全没有义务支持大版本1。这条规则之所以存在，是为了让Ice run time 能最终摆脱旧版本——没有这样的规则，未来的所有版本的Ice 就必须支持永远支持先前的所有大版本。用 简明的话说，使用不同大版本的客户和服务器不能相互通信。

2. 如果一个接收者说自己能支持小版本n，它就肯定能成功解码所有小于n 的小版本。注意，这并非是说，使用版本n−1 的消息能被当成版本n的消息进行解码：就它们的物理表示而言，两个相邻的小版本可能完全不兼容。但是，因为任何说自己支持版本n 的接收者也有义务正确处理版本n−1，小版本升级在语义上是向后兼容的，即使它们的物理表示可能并不兼容。

3. 支持小版本n 的发送者保证能使用所有小于n 的小版本来发送消息。而且，发送者还保证 ，如果它收到的请求使用的是小版本k (k≤n)，它将用小版本k 来发送对该请求的答复。

版本磋商

版本磋商客户和服务器必须以某种方式、就使用哪个版本来交换消息达成一致。取决于底层传输机制是面向连接的还是无连接的，用于磋商共同版本的机制也不同。

为面向连接传输机制进行磋商在使用面向连接的传输机制时，客户打开一个通向服务器的连接，然后等待验证连接消息返回。服务器发送的验证连接消息会指示服务器的协议和编码的大版本号、以及所支持的最高小版本号。如果服务器和客户的大版本号不匹配，客户端将引发UnsupportedProtocolException或UnsupportedEncodingException。
假定客户收到的来自服务器的验证连接消息与客户的大版本是匹配的，客户就知道了服务器所支持的最高的小版本号。从此以后，客户有义务不发送小版本号更高的消息。但是，服务器可以发送小版本号更低的消息。服务器一开始不知道客户所支持的最高小版本( 因为客户不会发送验证连接消息给服务器)。相反，服务器会查看消息头，了解每个消息中的客户版本号。这个小版本号指示的是客户所能接受的小版本号，其作用域是一次请求- 答复交互过程。例如，如果客户发送了一个小版本为3 的请求，服务器必须也用小版本3 发送答复。但是，下一次客户请求也许会使用小版本2，服务器也必需用小版本2 来答复该请求。在通过关闭连接消息进行有序的连接关闭时，服务器可以使用任何小版
本，但这个小版本不能高于此前从客户那里所接收到最高的小版本号。

为无连接传输机制进行磋商在使用无连接的传输机制时，不存在验证连接消息，所以客户必须通过其他手段来了解服务器所支持的最高小版本号。采用何种手段取决于无连接端点是直接绑定的还是间接绑定的：
• 对于直接代理，版本信息是代理中所包含的端点的一部分。在这种情况下，客户在发送消息时，使用的小版本号不高于代理中的端点的小版本号。
• 对于间接代理，代理自身完全不含版本信息( 因为代理不含端点)。相反，客户会在把适配器名解析成一个或多个端点时获取版本信息( 通过IcePack 或等价的服务)。端点的版本信息将决定客户可以使用的最高小版本号。