Archived

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

IceStorm publisher and subscriber reside in different networks

I'm new to IceStorm. Using IceStorm, I was able to make the publisher and subscriber work when they are both part of the same network.

But I encounter problem when the publisher resides in the network behind a global static IP, while the subscriber resides in the network behind another global static IP. Port forwarding was properly done for both networks. I'm able to get the TopicManagerPrx and retrieve the TopicPrx, but cannot get both the publisher and subscriber from the TopicPrx. The error message is as follows:

"A connection attempt failed because the connected party did not properly respond after
a period of time, or established connection failed because connected host has failed to respond"

I list the configurations for Icebox&IceStorm, publisher and subscriber in a scenario where Icebox&IceStorm and subscriber run on the same host in network A (with global static IP 183.122.43.74), while publisher runs on a host in network B.

In config.icebox

IceBox.ServiceManager.Endpoints=tcp -p 9998 -h 192.168.0.4

In config.service

IceStorm.TopicManager.Endpoints=tcp -p 10000 -h 192.168.0.4
IceStorm.Publish.Endpoints=tcp -h 192.168.0.4 -p 10001

In config.sub

IceStorm.TopicManager.Endpoints=tcp -p 10000 -h 192.168.0.4
IceStorm.Publish.Endpoints=tcp -h 192.168.0.4 -p 10001

In config.pub

TopicManager.Proxy=DemoIceStorm/TopicManager:tcp -p 10000 -h 183.122.43.74

My questions are:

1. Can IceStorm work for the case where publisher and subscriber reside in different networks?

2. Are there any other configurations or settings needed for IceStorm to work in different networks?

Any help will be greatly appreciated!

Comments

  • benoit
    benoit Rennes, France
    Hi,

    The topic proxy obtained by your publisher most likely includes endpoints pointing to the internal IP address rather than the public IP address (which is the reason why the publisher fails to connect when you make an invocation on the topic proxy to obtain the publisher object). You could verify this by printing out the topic proxy or/and enabling network tracing with Ice.Trace.Network=2 in your publisher.

    There are few options to solve this.

    You could configure the published endpoints for the IceStorm.TopicManager and IceStorm.Publish object adapters. See Object Adapter Endpoints for information on published endpoints. Adding the following property to the config.service file should fix your problem (assuming you used the same ports for the public IP address):
    IceStorm.TopicManager.PublishedEndpoints=tcp -p 10000 -h 192.168.0.4:tcp -p 10000 -h 183.122.43.74
    IceStorm.Publish.PublishedEndpoints=tcp -h 192.168.0.4 -p 10001:tcp -p 10001 -h 183.122.43.74
    
    As you can see, the published endpoints contain both the internal and public IP addresses. This is necessary since your subscriber should connect to IceStorm using the internal IP and not the public IP.

    This configuration isn't ideal because the publisher might still try to connect to the internal IP address before connecting to the public IP address... This might cause some delays (you could override the connect timeout with Ice.Override.ConnectTimeout to minimize the delays).

    Two better solutions would be to:
    • Use Glacier2 on network A where the subscriber and IceStorm are running and modify your publisher to first establish a session with the Glacier2 router. Requests from your publisher to IceStorm will be routed through the Glacier2 router.
    • Create a VPN network in order to hide the network complexity from your distributed application.

    Let us know if you need more information on this.

    Cheers,
    Benoit.
  • Thanks Benoit for your quick reply. When I put in these two lines in config.service

    IceStorm.TopicManager.PublishedEndpoints=tcp -p 10000 -h 192.168.0.4:tcp -p 10000 -h 183.122.43.74
    IceStorm.Publish.PublishedEndpoints=tcp -h 192.168.0.4 -p 10001:tcp -p 10001 -h 183.122.43.74

    I got the following error message:

    !! 03/25/14 13:34:01.889 icebox: error: ServiceManager: exception while starting
    service IceStorm:
    Network.cpp:1868: Ice::SocketException:
    socket exception: WSAEADDRNOTAVAIL


    Could you please help on this?

    Thanks,
  • benoit
    benoit Rennes, France
    Did you modify the IceStorm.TopicManager.Endpoints and IceStorm.Publish.Endpoints properties? Can you copy/paste the content of your config.service file?
  • Oh, yeah, I made a mistake. Now it works for the scenario where IceStorm and subscriber run on the same host in network A (with global static IP 183.122.43.74), while publisher runs on a host in network B (with global static IP 67.10.195.25). Thanks a lot!

    But I have problem making it work for another scenario where subscriber runs on a host in network A, while IceStorm and publisher run on the same host in network B. The configurations are as follows:

    In config.service

    IceStorm.TopicManager.Endpoints=tcp -p 10000 -h 192.168.1.103
    IceStorm.TopicManager.PublishedEndpoints=tcp -p 10000 -h 192.168.1.103:tcp -p 10000 -h 67.10.195.25

    IceStorm.Publish.Endpoints=tcp -h 192.168.1.103 -p 10001
    IceStorm.Publish.PublishedEndpoints=tcp -h 192.168.1.103 -p 10001:tcp -h 67.10.195.25 -p 10001

    In config.pub

    TopicManager.Proxy=DemoIceStorm/TopicManager:default -p 10000 -h 192.168.1.103

    In config.sub

    LAWDSRemoteBeaconController.Subscriber.Endpoints=tcp -h 192.168.0.4
    TopicManager.Proxy=DemoIceStorm/TopicManager:tcp -h 76.10.159.52 -p 10000

    The error message I got is from IceStorm service console:

    -- 03/25/14 16:09:10.661 icebox-IceStorm: Network: failed to establish tcp connection
    local address = <not available>
    remote address = 192.168.0.4:52561
    Network.cpp:2519: Ice::ConnectFailedException:
    connect failed: The semaphore timeout period has expired.

    Your help is greatly appreciated!

    Xia
  • benoit
    benoit Rennes, France
    Hi,

    This is the same problem but this time for the subscriber: the subscriber proxy that is passed to the IceStorm::Topic::subscribe method contains the wrong endpoint. As you can see from the trace, it contains the internal IP address instead of the public IP address.

    You need to configure the published endpoint property for the subscriber object adapter:
    LAWDSRemoteBeaconController.Subscriber.Endpoints=tcp -h 192.168.0.4 
    LAWDSRemoteBeaconController.Subscriber.PublishedEndpoints=tcp -h <public IP address> -p <port>
    

    Benoit.
  • Thanks Benoit.

    What would be the <port> in the Subscriber.PublishedEndPoints? There is no port specified in Subscriber.Endpoints.

    Xia
    benoit wrote: »
    Hi,

    This is the same problem but this time for the subscriber: the subscriber proxy that is passed to the IceStorm::Topic::subscribe method contains the wrong endpoint. As you can see from the trace, it contains the internal IP address instead of the public IP address.

    You need to configure the published endpoint property for the subscriber object adapter:
    LAWDSRemoteBeaconController.Subscriber.Endpoints=tcp -h 192.168.0.4 
    LAWDSRemoteBeaconController.Subscriber.PublishedEndpoints=tcp -h <public IP address> -p <port>
    

    Benoit.
  • benoit
    benoit Rennes, France
    Hi,

    You need to specify a fixed port in Subscriber.Endpoints and setup your firewall to forward to this port like you did for the IceStorm ports (e.g.: LAWDSRemoteBeaconController.Subscriber.Endpoints=tcp -h 192.168.0.4 -p 10002).

    Cheers,
    Benoit.
  • Thank you very much Benoit! It's working now.

    I have no experience with Glacier2. Could you please point me to some examples/samples which show how to use Glacier2 and IceStorm together?

    Thanks,
    Xia