[omniORB] Bidirectional GIOP calls using Endpoints with Omnin ames

[Young Travis - tyoung]

>On Tuesday 27 April, Young Travis - tyoung wrote:

>> 	I have a server process that I am wanting to restrict all
>> communication to one port to resolve firewall issues.   I'm using the
latest
>> version of omniORB.   I built the bidir example that came with the
install,
>> setup the configuration and ran it.   The example worked properly, but it
>> choose an random port to open for the callback.   I added an
>> endPoint=giop:tcp:tyoung:12340, and ran it again and port 12340 was used
for
>> the callback which was the result that I was looking for.

>I think you are misunderstanding the point of bidirectional GIOP.

>It is designed for the case that a client is behind a firewall that
>does not permit any incoming connections. Thus, the client opens a
>connection to the server, and the server does its callback through the
>same connection. The callback does not involve opening a connection at
>all. That's the point of bidir.

>It looks like what you've seen is that the bidir server opens a new
>connection to the bidir client. In that case, you have failed to set
>bidir up correctly, and it's just using a normal callback.

You are right, I am misunderstanding bidirectional GIOP.  In my case,
omninames and my server process are running on a machine behind a firewall.
The client is installed on a machine outside the firewall.  The security
team here would like to only open up 1 port or a few known ports instead
large range of ports so that the my client can communicate with my server.
Is there a way that I can limit the ports that my client and server use? 

>> 	I then made the necessary changes to my client and server and then
>> tried to run it with the same configuration.  I get the following error
when
>> my server tries to resolve the Naming Service which is running on the
same
>> machine.   
>> 
>> omniORB: Creating ref to in process: key<0x4e616d6553657276696365>
>>  target id      : IDL:omg.org/CORBA/Object:1.0
>>  most derived id:
>> omniORB: Initial reference `NameService' resolved from configuration
file.
>> omniORB: Invoke '_is_a' on in process: key<0x4e616d6553657276696365>
>> omniORB: throw OBJECT_NOT_EXIST from inProcessIdentity.cc:179
>> (NO,OBJECT_NOT_EXIST_NoMatch)

>That shows that you have now misconfigured omniORB so it thinks the
>reference to the naming service is in the same process as your code,
>so when you try to contact it, the object doesn't exist.

>Cheers,

>Duncan.

>-- 
> -- Duncan Grisby         --
>  -- duncan at grisby.org     --
>   -- http://www.grisby.org --


**********************************************************************
The information contained in this communication is
confidential, is intended only for the use of the recipient
named above, and may be legally privileged.
If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, 
distribution, or copying of this communication is strictly
prohibited.
If you have received this communication in error,
please re-send this communication to the sender and
delete the original message or any copy of it from your
computer system. Thank You.