[omniORB] More endPoint questions

[Wernke zur Borg]

Hi all,

I have been dealing with the endPoint option to some success, but now I
am facing a difficult problem.

My server is running on a machine with two IP interfaces, where clients
can connect on either interface. A servant has to return object
references to clients, which are supposed to operate on them. Up to now
I used to create one server process for each interface, with the
relevant different endPoint setting for each process.

Now I have to use the same process for clients calling on both
interfaces. It is essential that every object reference gets the correct
IP address encoded in the IORs returned to each client.

My questions are:

1. When I set multiple endPoint options, can I expect that all related
endPoints get encoded into the IORs?

2. If yes, can I expect a client (not necessarily an omniORB client) to
try each endpoint in turn until he finds the correct one?

3. Alternatively, can I use endPointPublishAllIFs to get all available
endpoints encoded in IORs?

I am afraid that setting multiple endpoints or using the
endPointPublishAllIFs option merely leads to the ORB listening on those
interfaces but not to the usage of all of them in IORs. Correct me if I
am wrong.

Has anybody got a solution for the problem? Could perhaps the omniMapper
help?

Thank you for any hint.

Wernke

[Duncan Grisby]

On Thursday 21 September, "Wernke zur Borg" wrote:

[...]

Post by Wernke zur Borg
1. When I set multiple endPoint options, can I expect that all related
endPoints get encoded into the IORs?

Yes.

Post by Wernke zur Borg
2. If yes, can I expect a client (not necessarily an omniORB client) to
try each endpoint in turn until he finds the correct one?

All modern CORBA implementations should try them all. Older ones may not
-- omniORB 3 didn't, for example. In omniORB, the order the addresses
are tried in is determined by the client transport rules.

Post by Wernke zur Borg
3. Alternatively, can I use endPointPublishAllIFs to get all available
endpoints encoded in IORs?

Yes.

Post by Wernke zur Borg
I am afraid that setting multiple endpoints or using the
endPointPublishAllIFs option merely leads to the ORB listening on those
interfaces but not to the usage of all of them in IORs. Correct me if I
am wrong.

No, omniORB publishes the endpoints in IORs as well as listening on
them.

Have you read the relevant section in the omniORB documentation? For
omniORB 4.0.x it's here:

http://omniorb.sourceforge.net/omni40/omniORB/omniORB008.html#toc41


omniORB 4.1 has some new options about how addresses are published, that
let you do all kinds of interesting things. That's documented here:

http://omniorb.sourceforge.net/omni41/omniORB/omniORB008.html#toc42


Cheers,

Duncan.

[Wernke zur Borg]

Post by Wernke zur Borg
[...]

Post by Wernke zur Borg
1. When I set multiple endPoint options, can I expect that

all related

Post by Wernke zur Borg
endPoints get encoded into the IORs?

Yes.

OK, I have inspected the encoded IORs and I can see that there is a main
host entry in the profile plus a number of ALTERNATE_IIOP_ADDRESS
entries encoded as tagged components.

Post by Wernke zur Borg

Post by Wernke zur Borg
2. If yes, can I expect a client (not necessarily an

omniORB client) to

Post by Wernke zur Borg
try each endpoint in turn until he finds the correct one?

All modern CORBA implementations should try them all. Older
ones may not
-- omniORB 3 didn't, for example. In omniORB, the order the addresses
are tried in is determined by the client transport rules.

What I can now say from experience is that the Sun Java ORB does not do
it. It only tries the main host entry in the profile and ignores any
ALTERNATE_IIOP_ADDRESS. I currently cannot say if this default behaviour
can be changed easily.

I am now hoping to get away with an interceptor attached to encodeIOR,
which changes the host entry to the one relevant for the respective
client. Not nice but it seems to be the last resort in my case.

Regards, Wernke