Ice Protocol documentation buglet

[vukicevic]

Howdy,

The protocol documentation in chapter 15, section 15.3.4 (Reply Message Body) doesn't correspond to what Ice 1.1 sends. The documentation states that a message header with a message type of Reply will be followed by a byte indicating the status of the request, and then one of the structures depending on the status type. Each of the structures has a requestId int32 as the first member. In Ice 1.1, it seems that the requestId is being sent first, followed by the reply type byte, and then the remainder of the structure as described in chapter 15.

I understand why the requestId is being sent first, so that the request invocation can proceed and a response be written without having to carry the requestId, so you might want to update this section of the documentation

[michi]

Originally posted by vukicevic
Howdy,

The protocol documentation in chapter 15, section 15.3.4 (Reply Message Body) doesn't correspond to what Ice 1.1 sends. The documentation states that a message header with a message type of Reply will be followed by a byte indicating the status of the request, and then one of the structures depending on the status type. Each of the structures has a requestId int32 as the first member. In Ice 1.1, it seems that the requestId is being sent first, followed by the reply type byte, and then the remainder of the structure as described in chapter 15.

Hi,

thanks for the bug report! I'll have a look at this today and fix up the doc as necessary, thanks! Out of curiousity, what are you doing with the Ice protocol? Methinks that you wouldn't have found this problem unless you are trying to interoperate with Ice?

Cheers,

Michi.

[michi]

Originally posted by vukicevic
Howdy,

In Ice 1.1, it seems that the requestId is being sent first, followed by the reply type byte, and then the remainder of the structure as described in chapter 15.

I just checked, and you are right: following the message header, Ice sends the request ID, followed by the reply status byte, followed by an encapsulation that contains the results.

I'll update the doc to agree with reality Thanks again for finding this bug!

Cheers,

Michi.

[vukicevic]

Hi,

Thanks for looking into it so quickly I'm working on a native implementation of the protocol in a .NET CLI environment, using the remoting infrstructure that exists there. I'll post more info later when there's more to post Edit: I've mostly given up on earlier work with python, mainly because python's pathetic threading situation doesn't work too well with Ice. Shouldn't be a problem with the CLI though.

Another documentation buglet.. section 17.3.1 that talks about the message header mentions ".. has a 13-byte header .."; unless my counting is off, the message header is 14 bytes

[michi]

Originally posted by vukicevic
Hi,

I'm working on a native implementation of the protocol in a .NET CLI environment, using the remoting infrstructure that exists there. I'll post more info later when there's more to post

Ah, interesting -- please let us know how you go!

Another documentation buglet.. section 17.3.1 that talks about the message header mentions ".. has a 13-byte header .."; unless my counting is off, the message header is 14 bytes

You are right -- I found the same thing when I made the changes for the reply message, so it's fixed already

Cheers,

Michi.