[omniORB] How omniOrb handles GIOP message with Request Id out of sync

[Zhu, Wayne]

Greetings!
We use CORBA one way callbacks to send updates to OmniOrb server(c++) with GIOP messages. These GIOP messages are GIOP 1.2 Requests. If one message's request id is out of sync, does omniOrb drop the messages? For example, request id 685 comes before 684. Thanks.

Wayne

[Duncan Grisby]

Post by Zhu, Wayne
We use CORBA one way callbacks to send updates to OmniOrb server(c++)
with GIOP messages. These GIOP messages are GIOP 1.2 Requests. If one
message's request id is out of sync, does omniOrb drop the messages?
For example, request id 685 comes before 684. Thanks.

No, omniORB doesn't care if the request ids are out of order. In fact,
the CORBA spec doesn't require them to be in order. It merely says:

request_id is used to associate reply messages with request messages
(including LocateRequest messages). The client (requester) is
responsible for generating values so that ambiguity is eliminated;
specifically, a client must not re-use request_id values during a
connection if: (a) the previous request containing that ID is still
pending, or (b) if the previous request containing that ID was
canceled and no reply was received. (See the semantics of the Section
15.4.4, "CancelRequest Message," on page 15-40).

Most ORBs satisfy that by using an incrementing counter, but an ORB
could choose to use some other strange scheme.

If you start looking at omniORB's request ids, you'll notice that they
always increment by 2. That's to cope with bidirectional GIOP where
clients only use even request ids and servers performing callbacks only
use odd ones. That's required somewhere in the CORBA spec, but I can't
find it right now.

Cheers,

Duncan.