[omniORB] OmniORB 4.1.4 bidirectional GIOP fails

[mbazs123]

Hi,
I've never done bidirectional GIOP, I'm trying now (omniORB on server,
Jacorb on client side).

Something is weird: everything seems fine, the connection between two
parties is OK, but somehow omniORB seems to 'forget' the correct target port
to the client:



omniORB: Accepted connection from giop:tcp:192.168.0.143:1982 because of
this rule: "* unix,tcp,ssl,bidir"
omniORB: inputMessage: from giop:tcp:192.168.0.143:1982 314 bytes
omniORB: Receive codeset service context and set TCS to (ISO-8859-1,UTF-16)
omniORB: Receive bidir IIOP service context: ( 192.168.0.143:1980 )
omniORB: Accepted request from giop:tcp:192.168.0.143:1982 to switch to
bidirect
ional because of this rule: "* unix,tcp,ssl,bidir"
omniORB: Dispatching remote call 'createService' to:
root/CorePOA<1131377253> (active)
omniORB: Creating ref to remote:
key<5995057260.MainTransientPOA....9.J.K..G>
target id : IDL:hu.euronetrt/Charm/Client/Service:1.0
most derived id: IDL:hu.euronetrt/Charm/Client/AutoScanService:1.0
omniORB: Adding root<2> (activating) to object table.
omniORB: State root<2> (activating) -> active
omniORB: Creating ref to local: root<2>
target id : IDL:hu.euronetrt/Charm/Server/AutoScanService:1.0
most derived id: IDL:hu.euronetrt/Charm/Server/AutoScanService:1.0
omniORB: sendChunk: to giop:tcp:192.168.0.143:1982 192 bytes
omniORB: ObjRef(IDL:hu.euronetrt/Charm/Server/AutoScanService:1.0) --
deleted.
omniORB: LocateRequest to remote:
key<5995057260.MainTransientPOA....9.J.K..G>
omniORB: Client attempt to connect to giop:tcp:192.168.0.143:1980
omniORB: Failed to connect (no peer name): 192.168.0.143
omniORB: Switch rope to use address giop:tcp:192.168.0.143:1980
omniORB: Unable to open new connection: giop:tcp:192.168.0.143:1980
omniORB: throw giopStream::CommFailure from
giopStream.cc:1152(0,NO,TRANSIENT_ConnectFailed)
omniORB: throw TRANSIENT from omniObjRef.cc:1137
(NO,TRANSIENT_ConnectFailed)

So that's it.


My questions are:

Why is this:
omniORB: Accepted connection from giop:tcp:192.168.0.143:1982 because of
this rule: "* unix,tcp,ssl,bidir"

and this

omniORB: Receive bidir IIOP service context: ( 192.168.0.143:1980 )

have different ports (1982 vs. 1980)? And after all why does omniorb want to
connect to the 'bad' port (1980)?

I'm a newbie to this, so thx very much for your help!

MB

[Duncan Grisby]

On Tue, 2010-06-01 at 02:04 -0700, mbazs123 wrote:

[...

Post by mbazs123
omniORB: Accepted connection from giop:tcp:192.168.0.143:1982 because of
this rule: "* unix,tcp,ssl,bidir"
and this
omniORB: Receive bidir IIOP service context: ( 192.168.0.143:1980 )
have different ports (1982 vs. 1980)? And after all why does omniorb want to
connect to the 'bad' port (1980)?

1980 is the port the JacORB side is listening on as a server. It is the
address stored in object references coming from JacORB, and thus the
address the server should use for callbacks to your client if
bidirectional is not in use.

The way bidirectional GIOP works is that the client sends a message
saying that whenever the server makes an invocation on an object
reference with the specified endpoint details (in this case
192.168.0.143:1980), the call should instead go through the incoming
connection (in this case port 1982). To avoid a security issue where a
client can hijack calls intended for a completely different server, the
only object references that are candidates for bidirectional calls are
ones that have passed through the connection in question.

So, the question is why your object reference was not handled correctly.
How did the server get the callback reference? One guess is that it was
passed as a string, rather than as an object reference, meaning that
omniORB did not know the reference came through the connection. Could
that be it?

Cheers,

Duncan.

[mbazs123]

Post by Duncan Grisby
1980 is the port the JacORB side is listening on as a server. It is the
address stored in object references coming from JacORB, and thus the
address the server should use for callbacks to your client if
bidirectional is not in use.
The way bidirectional GIOP works is that the client sends a message
saying that whenever the server makes an invocation on an object
reference with the specified endpoint details (in this case
192.168.0.143:1980), the call should instead go through the incoming
connection (in this case port 1982). To avoid a security issue where a
client can hijack calls intended for a completely different server, the
only object references that are candidates for bidirectional calls are
ones that have passed through the connection in question.

So you're saying that on client side (Jacorb) everything OK with the
bidirectional settings?
Good news! :)

Post by Duncan Grisby
So, the question is why your object reference was not handled correctly.
How did the server get the callback reference? One guess is that it was
passed as a string, rather than as an object reference, meaning that
omniORB did not know the reference came through the connection. Could
that be it?

My client calls a server-side factory operation, passing a callback object
as one of the parameters. So I don't mess with string IORs etc.

What is very weird for me is that it is really doing what you've said, but
it seems omniORB cannot map the port found in "IIOP service context" to the
good, alive incoming socket. I'm seeing in 'netstat' that the 'good' channel
is very OK. So I don't really understand this ...

Of course I've done this, too:

const char *options[][2]={
{"serverTransportRule","* tcp,ssl,bidir"},
{"acceptBiDirectionalGIOP","1"},
{0,0}};
try {
m_orb=CORBA::ORB_init(argc,argv,"omniORB4",options);

Anyway, thx 4 the answer!
MB

[mbazs123]

Oh my God...

Of course it was my mistake... I confused POA's and policies...
Anyway, with your help I managed to understand the whole bidirectional
process!:clap:

Thx, bye!
MB