[omniORB] Short identifier for objects?

[Duncan Grisby]

On Thursday 4 October, "Keeley, Michael" wrote:

> I am in the process of writing a "replay tool" that can emulate one side of
> a CORBA conversation from one recorded previously. (This is to enhace our
> component testing abilities).

OK.

> It's not required to be an all-singing, all-dancing, robust,
> works-with-any-orb tool, just as long as it can do the basics using omniORB
> 2.8, we'll be fine.

I'm glad you said that.

> One of the tricks is to identify objects as they are passed back and forth
> across the wire, and to match them up during replay. So that when object
> Apple from process Eve is returned to process Adam, and then later on Adam
> makes a call on the Apple (er... Eat for example), the two recorded objects
> can be matched successfully.
> The recording is done at Adam's end, so the return value from Adam: apple =
> Eve->GetApple() is output using the IOR of the Apple. Later on the Adam:
> apple->Eat() call causes the IOR of apple to be output. The replay tool
> compares the IOR strings to get a match.

I'm not sure I completely understand what you are doing, but never
mind. What bit of the interaction are you trying to replay?

> I know that you are not *supposed* to compare IOR string directly. However,
> as they are both output from the same instance of a process, they will be
> the same, right?

Wrong, I'm afraid. IORs contain some padding bytes that are not
initialised by the ORB, so two IOR strings for the same object,
created one after the other, may differ.

> IORs are unweildy to use in this manner, especially for high volumes of
> calls.
> Is there a smaller thing that I can get that will be unique for a given
> object and process? (The servant for the object may not be in the same
> process). 

Like I say, I don't completely understand what you are trying to
achieve.

However, given that you say you are happy for a solution that isn't at
all robust, you might like to look at the source for catior in
src/appl/utils/catior.cc. That extracts the information about host,
port and object key from an IOR, which may be sufficient for what you
want.

In the general case, poking inside IORs is a very dangerous thing to
do, and you're asking for all sorts of pain. It's quite possible to
have two totally different IORs that refer to the same object, for
example. In your case, though, you'll probably get away with it. It's
certainly better than comparing IOR strings.

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --