[omniORB] CORBA and firewalls/NATs

[Corrado Santoro]

Hi all,

in your knowledge, is there any software that permits the use of CORBA
through firewalls and NATs?

thx,
--Corrado
--
==================================================================
Eng. Corrado Santoro, Ph.D.
University of Catania - ITALY - Engineering Faculty

Tel: [phone] VoIP: sip:***@voicegw2.diit.unict.it

Personal Home Page: http://www.diit.unict.it/users/csanto
NUXI Home Page: http://nuxi.diit.unict.it
==================================================================

[W T Meyer]

I have done this using SSH tunnelling. I posted a note in the
"Useful Tips" part of the omniORB Wiki page, which you can access at
http://www.omniorb-support.com/omniwiki/UsefulTips . Look for the
note with the heading "

SSH tunnels with omniORB".

Regards,

Tom Meyer

Post by Corrado Santoro
Hi all,
in your knowledge, is there any software that permits the use of
CORBA through firewalls and NATs?
thx,
--Corrado
--
==================================================================
Eng. Corrado Santoro, Ph.D.
University of Catania - ITALY - Engineering Faculty
Personal Home Page: http://www.diit.unict.it/users/csanto
NUXI Home Page: http://nuxi.diit.unict.it
==================================================================
_______________________________________________
omniORB-list mailing list
http://www.omniorb-support.com/mailman/listinfo/omniorb-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20061214/05d4ee8f/attachment.htm

[Karel Gardas]

Hi,

yes, it is.

<commercial>
our company answer to this question is
ObjectWall. If you are interested, please have a
look at http://www.objectwall.com/ for more information. Also please do
not hesitate to contact me off-list in case of any further questions about
CORBA over firewall/NAT and ObjectWall.
</commercial>

Cheers,
Karel

Post by Corrado Santoro
Hi all,
in your knowledge, is there any software that permits the use of CORBA
through firewalls and NATs?
thx,
--Corrado
--
==================================================================
Eng. Corrado Santoro, Ph.D.
University of Catania - ITALY - Engineering Faculty
Personal Home Page: http://www.diit.unict.it/users/csanto
NUXI Home Page: http://nuxi.diit.unict.it
==================================================================
_______________________________________________
omniORB-list mailing list
http://www.omniorb-support.com/mailman/listinfo/omniorb-list

--
Karel Gardas ***@objectsecurity.com
ObjectSecurity Ltd. http://www.objectsecurity.com

[Renzo Tomaselli]

Hi all,
we use the servant activator for dynamically instantiate servants since
several years and through several versions of OmniORB, till 4.07.
One disappointing feature of this mechanism concerns the method
omniOrbPOA::dispatch_to_sa (in poa.cc), which holds a mutex on
omniServantActivatorTaskQueue while calling incarnate method inside
application code. If this in turn needs the servant activator again,
then we get a deadlock on any pthread implementation (not on Windows,
though).
We cannot prevent this since it occurs internally to OmniORB. Also it's
hard to predict, since it occurs whenever a method is called on an obj
ref which has no servant yet, and I don't know about any public way to
detect this in advance (the process object table is not public), besides
the heavy complication of checking it for all methods of all objects.
Is this behavior still present in 4.1 ? Any chance to release that mutex
or is there any other trick possible ?
Thanks -- Renzo Tomaselli

[Duncan Grisby]

Post by Renzo Tomaselli
we use the servant activator for dynamically instantiate servants
since several years and through several versions of OmniORB, till 4.07.
One disappointing feature of this mechanism concerns the method
omniOrbPOA::dispatch_to_sa (in poa.cc), which holds a mutex on
omniServantActivatorTaskQueue while calling incarnate method inside
application code. If this in turn needs the servant activator again,
then we get a deadlock on any pthread implementation (not on Windows,
though).

Sadly, this behaviour is required in the CORBA spec:

Section 11.3.5 of CORBA 2.6:

"
? Invocations of incarnate on the servant manager are serialized.
? Invocations of etherealize on the servant manager are serialized.
? Invocations of incarnate and etherealize on the servant manager are
mutually exclusive.
"

It's a side-effect of the mutex semantics on Windows that they permit
recursive calls by the thread holding the mutex.

I'm afraid I don't have any good suggestions about what you can do about
it, other than to refrain from making CORBA calls inside your servant
activators. It would probably be quite easy to remove the lock, at the
expense of no longer adhering to the spec.

Cheers,

Duncan.

[Renzo Tomaselli]

Thank you, Duncan. Indeed we delayed any case needing to call incarnate
again down to actual method execution, when the involved mutex was
unlocked by omniOrbPOA. Thus incarnate just creates an empty servant,
without further actions.
This way everything runs fine.
-- Renzo

Post by Duncan Grisby

Post by Renzo Tomaselli
we use the servant activator for dynamically instantiate servants
since several years and through several versions of OmniORB, till 4.07.
One disappointing feature of this mechanism concerns the method
omniOrbPOA::dispatch_to_sa (in poa.cc), which holds a mutex on
omniServantActivatorTaskQueue while calling incarnate method inside
application code. If this in turn needs the servant activator again,
then we get a deadlock on any pthread implementation (not on Windows,
though).

"
? Invocations of incarnate on the servant manager are serialized.
? Invocations of etherealize on the servant manager are serialized.
? Invocations of incarnate and etherealize on the servant manager are
mutually exclusive.
"
It's a side-effect of the mutex semantics on Windows that they permit
recursive calls by the thread holding the mutex.
I'm afraid I don't have any good suggestions about what you can do about
it, other than to refrain from making CORBA calls inside your servant
activators. It would probably be quite easy to remove the lock, at the
expense of no longer adhering to the spec.
Cheers,
Duncan.