database <-> host with corba <-> access server <-> client (corba)
host server
Now, client try to call remonte methods form "host with corba server"
via "access server". Client sends request to IP, which is translated by
"access server" to internal IP of "host with corba server" (NAT). But in
reverse way, external address from which client receives packages could
be diffrent from input IP.
And now, my client corba application cannot connect to "host with corba"
- name service doesn't work.
I hope you understand my problem :) and there is some reasonable
solution. I use omniORB-4.0.5 version. Client is based on Windows,
server is working on Debian actually. Is it a problem for CORBA
applications to use NAT (which is set up on "access server")?
NAT and CORBA generally don't mix that well. IORs typically have
IP addresses or hostnames in them, as do object references that
pass through the GIOP stream, neither of which (generally) goes
through the NAT process. (There might be firewalls out there which
claim to rewrite GIOP streams for you, but I haven't looked into it.)
In some cases you can get simple things to work. If you tell
your server ORB to put the IP address of the NAT server in the IORs
it publishes and make sure the TCP port number it uses gets through
untranslated, you can probably get simple method calls to go through.
A more reliable method would be to put some sort of CORBA proxy
functionality on the NAT box which talks to both the outside and
inside, but that often isn't practical.
The CORBA Firewall Traversal spec talks about NAT, but it doesn't
claim to solve all the problems (callbacks, in particular), and it
certainly isn't implemented in omniORB.
Sorry the news isn't better.
Gary Duzan
BBN Technologies
There are two separate things to configure for an omniORB server
process:
/1/ The host and port on which the server process *actually* listens
/2/ The host and port on which the server process *pretends" it is
listening.
In a typicaly deployment, /1/ and /2/ are the same. In this case, you
use the following configuration variable:
endPoint = giop:tcp:<host>:<port>
where you replace "<host>" and "<port>" with the relevant host and
port.
If /1/ and /2/ are different then you use the following configuration
variables:
endPointNoPublish = giop:tcp:<host>:<port>
endPointNoListen = giop:tcp:<host>:<port>
The "endPointNoPublish" variable is for /1/, and the
"endPointNoListen" variable is for /2/.
If I understand your posting correctly then you should set the above
variables as follows:
endPointNoPublish = giop:tcp:<host-with-corba-server>:<port>
endPointNoListen = giop:tcp:<access-server-host>:<port>
Make sure that you specify the same <port> value for both
configuration variables.
You can find more information about these configuration variables in
the omniORB manual.
Regards,
Ciaran.
Ok, sounds good, but now i have a questions regarding that. Lets assume
that i run my server with such options:
-ORBendPointNoPublish giop:tpc:xxx.xxx.xxx.xxx:2809
-ORBendPointNoListen giop:tcp:yyy.yyy.yyy.yyy:2809
I got error message (no resources exception) - i think this is because
omniNames service is running on the same it's default port - should i
change port in above parameters? Or shouldn't i run omniNames service at
all in this case?
What option should i call to run on client side?
InitRef = NameService=corbaname::xxx.xxx.xxx.xxx:<port>??
or maybe something other?
Question is, if i'm using endPoints, i shouldn't use namingService or
there is no logic connection between thats two issues?
How to call client (parameters?) to get connection with server run with
above parameters? Do you know any sample (URL?) where is NAT problem
solved in similar way?
Any advices would be appreciated - i'm desperate. Please, HELP!!! :)
Your server listens on a port. omniNames is *another* server
application and it too listens on a port. It is important that the
port used by your server does not clash with the port used by
omniNames (because only one server can listen on a specific port). If
I remember correct, port 2809 is the default port used by omniNames
so, yes, it would be a good idea for you to use a different port for
your server.
If omniNames is running on the same machine as your server application
then you should use a pair of -ORBendPointNoPublish <...> and
-ORBendPointNoListen <...> for your server and another pair of those
options for omniNames. Just make sure that the port for your server
don't clash with omniNames' port.
You should configure the client to contact the Naming Service with:
-ORBInitRef NameService=corbaloc:iiop:1.2@<NAT-machine>:<omniNames-port>
You should configure the server (on the same side of the NAT as
omniNames) to contact the Naming Service with:
-ORBInitRef NameService=corbaloc:iiop:1.2@<real-omniNames-machine>:<omniNames-port>
> Question is, if i'm using endPoints, i shouldn't use namingService or
> there is no logic connection between thats two issues?
Whether or not you use endPoints is independent of whether or not you
use the Naming Service. However, remember that the Naming Service is
itself a server process that should use endPoints if it is behind a
NAT.
Regards,
Ciaran.
// ...
orb->run();
return 0;
// ...
When i want close server (on unix machine) i just use Ctrl+C - is it a
good way to that? (i cannot find any samples showing solution for that).
It seems that after that there are some threads still running and
makes endpoints ports busy (that thread is listening on that port)- so
next time i cannot create server instance with such ports number - i
have to change them in config file. So - how to properly shutdown
server? Make new thread with key handling and just call some function to
close CORBA after pressing particular key???