[omniORB] Multiple Interface Selection and omniNames

[Christian Hansen]

I would like to know how to configure omniNames to properly run on a
machine with 2+ network interfaces.
Supposing I have a machine where the interfaces are named host1a and
host1b, and host1a is publicly accessible whereas host1b is not. I want
to run omniNames and my CORBA services on host1 and my clients somewhere
else, say host2. If I do:

host1b>omniNames -start -logdir /some/path &
host1b>nameclt -ior corbaname::host1a: bind_new_context test_context
host2>nameclt -ior corbaname::host1a: list

The last command eventually times out. A look at tcpdump shows that
some of the communication is being attempted via the private interface.
I have tried setting ORBendPoint = giop:tcp:host1a:, but that doesn't
seem to help. Any ideas?

Thanks,
Christian Hansen

P.S. This was all done with omniORB 4.1.0 on a x86_64 box running Linux
2.6.16. With logging turned up to a verbosity level of 10 for omniORB, I
got:

on host1:
omniORB: Accepted connection from giop:tcp:[::ffff:72.14.207.99]:53914
because of this rule: "* unix,ssl,tcp"
omniORB: Adding root/<1641574701007840/1> (activating) to object table.
omniORB: Creating ref to local: root/<1641574701007840/1>
target id : IDL:omg.org/CosNaming/BindingIterator:1.0
most derived id: IDL:omg.org/CosNaming/BindingIterator:1.0

on host2:
omniORB: Distribution date: Tue Nov 28 13:27:23 GMT 2006 dgrisby
omniORB: Information: the omniDynamic library is not linked.
omniORB: Creating ref to remote: key<NameService>
target id : IDL:omg.org/CORBA/Object:1.0
most derived id:
omniORB: AsyncInvoker: thread id = 1 has started. Total threads = 1
omniORB: Creating ref to remote: key<NameService>
target id : IDL:omg.org/CosNaming/NamingContext:1.0
most derived id:
omniORB: Creating ref to remote: root/<1641574701007840/1>
target id : IDL:omg.org/CosNaming/BindingIterator:1.0
most derived id: IDL:omg.org/CosNaming/BindingIterator:1.0
omniORB: LocateRequest to remote: root/<1641574701007840/1>
omniORB: Unable to open new connection: giop:tcp:192.168.0.4:2809
omniORB: throw giopStream::CommFailure from
giopStream.cc:1148(0,NO,TRANSIENT_ConnectFailed)
list: Cannot contact the Naming Service because of TRANSIENT exception.
Is the naming service running?

[Michael]

Hi Christian,

"ignoreport" is the key

Assuming 192.168.1.1 is your external address:

e.g.
omniNames -ignoreport -ORBendPoint giop:tcp:192.168.1.1:2809

All servants that should be accessible by the externalhost should explicitely bound to the
external interface by using -ORBendPoint. You could also configure that in omniORB.cfg:

InitRef = NameService=corbaname::192.168.1.1
endPoint = giop:tcp:192.168.1.1:

It's also a good idea to run persistent POAs on a fixed port.

regards
micahael

Post by Christian Hansen
I would like to know how to configure omniNames to properly run on a
machine with 2+ network interfaces.
Supposing I have a machine where the interfaces are named host1a and
host1b, and host1a is publicly accessible whereas host1b is not. I want
to run omniNames and my CORBA services on host1 and my clients somewhere
host1b>omniNames -start -logdir /some/path &
host1b>nameclt -ior corbaname::host1a: bind_new_context test_context
host2>nameclt -ior corbaname::host1a: list
The last command eventually times out. A look at tcpdump shows that
some of the communication is being attempted via the private interface.
I have tried setting ORBendPoint = giop:tcp:host1a:, but that doesn't
seem to help. Any ideas?
Thanks,
Christian Hansen
P.S. This was all done with omniORB 4.1.0 on a x86_64 box running Linux
2.6.16. With logging turned up to a verbosity level of 10 for omniORB, I
omniORB: Accepted connection from giop:tcp:[::ffff:72.14.207.99]:53914
because of this rule: "* unix,ssl,tcp"
omniORB: Adding root/<1641574701007840/1> (activating) to object table.
omniORB: Creating ref to local: root/<1641574701007840/1>
target id : IDL:omg.org/CosNaming/BindingIterator:1.0
most derived id: IDL:omg.org/CosNaming/BindingIterator:1.0
omniORB: Distribution date: Tue Nov 28 13:27:23 GMT 2006 dgrisby
omniORB: Information: the omniDynamic library is not linked.
omniORB: Creating ref to remote: key<NameService>
target id : IDL:omg.org/CORBA/Object:1.0
omniORB: AsyncInvoker: thread id = 1 has started. Total threads = 1
omniORB: Creating ref to remote: key<NameService>
target id : IDL:omg.org/CosNaming/NamingContext:1.0
omniORB: Creating ref to remote: root/<1641574701007840/1>
target id : IDL:omg.org/CosNaming/BindingIterator:1.0
most derived id: IDL:omg.org/CosNaming/BindingIterator:1.0
omniORB: LocateRequest to remote: root/<1641574701007840/1>
omniORB: Unable to open new connection: giop:tcp:192.168.0.4:2809
omniORB: throw giopStream::CommFailure from
giopStream.cc:1148(0,NO,TRANSIENT_ConnectFailed)
list: Cannot contact the Naming Service because of TRANSIENT exception.
Is the naming service running?
_______________________________________________
omniORB-list mailing list
http://www.omniorb-support.com/mailman/listinfo/omniorb-list

[Wernke zur Borg]

-----Original Message-----
Subject: Re: [omniORB] Multiple Interface Selection and omniNames
Hi Christian,
"ignoreport" is the key
...

Post by Christian Hansen
I would like to know how to configure omniNames to properly run on a
machine with 2+ network interfaces.
...

I am not sure why -ignoreport should be required to get the desired
behaviour. To my understanding -ORBendPoint should be sufficient. Why
would the additional listening on the default port do any harm?

Thanks for any clarification.

Wernke

[Duncan Grisby]

Post by Wernke zur Borg

Post by Michael
"ignoreport" is the key
...

Post by Christian Hansen
I would like to know how to configure omniNames to properly run on a
machine with 2+ network interfaces.
...

I am not sure why -ignoreport should be required to get the desired
behaviour. To my understanding -ORBendPoint should be sufficient. Why
would the additional listening on the default port do any harm?

Without the -ignoreport, omniNames uses the port specification from the
command line or omniNames redo log to add its own -ORBendPoint argument
to the command line. It adds it at the start of the arguments, so it
takes precedence over the one you add yourself. By default, only the
first endpoint is published in IORs, meaning the one that gets published
is the wrong one.

With omniORB 4.1, the best way to get omniNames to publish the address
you want is to use -ORBendPointPublish giop:tcp:hostname:2809 since that
allows it to listen on all network interfaces as usual, but publish the
specific address you want.

Cheers,

Duncan.

[Wernke zur Borg]

-----Original Message-----
Sent: 06 December 2007 13:12
Subject: Re: [omniORB] Multiple Interface Selection and omniNames

Post by Wernke zur Borg

Post by Michael
"ignoreport" is the key
...

Post by Christian Hansen
I would like to know how to configure omniNames to

properly run on a

Post by Wernke zur Borg

Post by Michael

Post by Christian Hansen
machine with 2+ network interfaces.
...

I am not sure why -ignoreport should be required to get the desired
behaviour. To my understanding -ORBendPoint should be

sufficient. Why

Post by Wernke zur Borg
would the additional listening on the default port do any harm?

Without the -ignoreport, omniNames uses the port
specification from the
command line or omniNames redo log to add its own
-ORBendPoint argument
to the command line. It adds it at the start of the arguments, so it
takes precedence over the one you add yourself. By default, only the
first endpoint is published in IORs, meaning the one that
gets published
is the wrong one.

I was under the wrong impression that publishing IORs is not an issue
for omniNames because it only publishes what has been stored by binding
clients. But taking a closer look, of course it publishes its own
NamingContexts, therefore it does make sense.

Thanks for the clarification!

Wernke

[Michael]

Post by Wernke zur Borg

-----Original Message-----
Sent: 06 December 2007 13:12
Subject: Re: [omniORB] Multiple Interface Selection and omniNames

Post by Wernke zur Borg

Post by Michael
"ignoreport" is the key
...

Post by Christian Hansen
I would like to know how to configure omniNames to

properly run on a

Post by Wernke zur Borg

Post by Michael

Post by Christian Hansen
machine with 2+ network interfaces.
...

I am not sure why -ignoreport should be required to get the desired
behaviour. To my understanding -ORBendPoint should be

sufficient. Why

Post by Wernke zur Borg
would the additional listening on the default port do any harm?

Without the -ignoreport, omniNames uses the port
specification from the
command line or omniNames redo log to add its own
-ORBendPoint argument
to the command line. It adds it at the start of the arguments, so it
takes precedence over the one you add yourself. By default, only the
first endpoint is published in IORs, meaning the one that
gets published
is the wrong one.

I was under the wrong impression that publishing IORs is not an issue
for omniNames because it only publishes what has been stored by binding
clients. But taking a closer look, of course it publishes its own
NamingContexts, therefore it does make sense.

Of course it does :) Maybe this should be put in an FAQ someday, because almost everybody
in Christian's situation struggles with it at least once...

Post by Wernke zur Borg
Thanks for the clarification!
Wernke
_______________________________________________
omniORB-list mailing list
http://www.omniorb-support.com/mailman/listinfo/omniorb-list