Easy CORBA objects connections through ssh

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 file. 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 remote ports.
• 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.

Figure 18.1: Forwarders routing DIET communication through ssh tunnels