Archived

This forum has been archived. Please start a new discussion on GitHub.

Ice Protocol documentation buglet

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 :)

Comments

  • Re: Ice Protocol documentation buglet
    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.
  • Re: Ice Protocol documentation buglet
    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.
  • 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 :)
  • 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.