Each CORBA object in DIET is reachable through omniORB using a TCP
port and the hostname of the machine on which it is executed. By
default these parameters are fixed automatically by omniORB but it is
also possible to choose them statically using the DIET configuration
When two objects are located on different networks that are reachable
only through ssh, it is easy to open an ssh tunnel to redirect the
communications between them on the good port and host. Then, correcting
the objects bindings into the omniNames servers is sufficient to ensure
the communications between the different objects. To allow two
CORBA objects to communicate through an ssh tunnel, users must:
- Start the process which declares the objects and register them
into the omniNames server(s).
- Open ssh tunnels that redirect the local objects ports to
- Modify the objects bindings in the omniNames server(s) to make
them point to the forwarded ports.
When using few objects that do not need much interaction, these steps
can easily be done “manually”. But DIET uses several different
objects for each element and is designed to manage thousands of nodes.
Moreover, creating an ssh tunnel between all the nodes of a Grid
cannot even be considered.
The DIET forwarders deal with this problem by creating proxy
objects that forward the communications to a peer forwarder through
a unique ssh tunnel. Then, only one ssh tunnel is created to connect
two different networks. This system also allows users to define complex
communications routing. Figure 18.1 shows how the DIET
forwarders work to route communications through ssh tunnels. Moreover
most of the configuration of the forwarders automatically can be set
by DIET itself.
Forwarders routing DIET communication through ssh tunnels
The DIET Team - Mer 29 nov 2017 15:13:36 EST