Archived

This forum has been archived. Please start a new discussion on GitHub.

Bidir links cross the NAT

Hi.
I'm sorry for my bad English. :-(

I have a problem with bidirectional connections (proxies) when remote node (server/client) are running behind the NAT.

I have:
1. many Ice Objects (servants) activated on the local side (NAT), have no direct inbound access
2. many Ice Objects (servants) activated on the remote side (NAT), have only one opened TCP port.
3. objects at both sides are communicates each other
4. first proxy to first remote object was obtained by X::CheckedCast communicator->PropertyToProxy(...) method. All works fine here!
5. all other proxies to next remote objects are obtained by requesting methods of Ice Objects Interfaces, for example: second_prx = first_prx->get_object2_proxy(), etc...
6. try to bind this proxies to local (unnamed) adapter: second_prx->ice_getConnection()->setAdapter(local_adapter) for bidirectional connections. But I have a problem here - second_prx->ice_getConnection() trying to establish a new connection to remote side cause a second_prx.endpoints != first_prx.endpoints (cause remote server behind the NAT).

I have found a "local solution" for this problem - I create a new proxies with endpoints = first_prx.endpoints, and use this new_second_prx proxy to call remote side methods. I appologize that it is not a best solution for my situation. May be I must use Glacier2 or some other utils.

Please, help me.

Leonardo.

Comments

  • mes
    mes California
    Hi,

    Welcome to the forum.

    It sounds like Glacier2 would be a good fit for your situation. Take a look at the Glacier2/callback example in the Ice distribution for a simple demonstration, and let us know if you have questions.

    Best regards,
    Mark
  • mes wrote: »
    Hi,

    Welcome to the forum.

    It sounds like Glacier2 would be a good fit for your situation. Take a look at the Glacier2/callback example in the Ice distribution for a simple demonstration, and let us know if you have questions.

    Best regards,
    Mark

    Thank you, Mark.
    I just tested this example of Glacier2. It seems to work fine.
    But how can I do the same without using Glacier2?
  • mes
    mes California
    Using bidirectional connections without Glacier2 makes the application more complex.

    Here are some guidelines:
    • A server can freely return proxies to a bidirectional client. The only limitation is that all of the proxies must resolve to the same connection; in general, this means the proxies should all refer to servants in the same object adapter. (The goal is usually for the client to have a single connection to the server, and using multiple object adapters in the server would require the client to create multiple connections.)
    • The server must create the proxy for every callback object in the client. As shown in our Ice/bidir example, the client passes the identity of its callback object to the server, and the server creates the proxy that it uses to send callback requests. The server should not be requesting proxies from the client.
    Using Glacier2 solves these issues and I recommend that you use Glacier2 if possible.

    Regards,
    Mark
  • mes wrote: »
    Using bidirectional connections without Glacier2 makes the application more complex.

    Here are some guidelines:
    • A server can freely return proxies to a bidirectional client. The only limitation is that all of the proxies must resolve to the same connection; in general, this means the proxies should all refer to servants in the same object adapter. (The goal is usually for the client to have a single connection to the server, and using multiple object adapters in the server would require the client to create multiple connections.)
    • The server must create the proxy for every callback object in the client. As shown in our Ice/bidir example, the client passes the identity of its callback object to the server, and the server creates the proxy that it uses to send callback requests. The server should not be requesting proxies from the client.
    Using Glacier2 solves these issues and I recommend that you use Glacier2 if possible.

    Regards,
    Mark

    Thank you for guidelines.
    Method that I used now just the same as that guidlines. Server use only one object adapter. It works fine just a method "with Glacier2".
    A "with Glacier2" method is more "correct" for this situation, but time delays between client and server in my project is more critical that "correctness" of method. Glacier2 it is an additional "hop" in packets path and it is add some little delay inside Glacier2 (proxies mapping and other calculations).
    I think to use method "without Glacier2" at the project's start. If project needs will grow in future I will use Glacier2.

    Thank you again, Mark.

    Regards,
    Leonardo