Home Help Center

Using ICE in a complex network

Igor PetrovIgor Petrov Member Igor PetrovOrganization: RTIProject: Decentralized network services
Hello. We plan to use Ice 3.5.1 (only C++) in our system.
The structure of our network:
There are several LANs. In each network only one computer is connected to the Internet. Other computers have no direct access to the Internet (no NAT). There are services and clients on computers that are not connected to the Internet. The number of programs running on those computers should be minimized (in particular, running icegridnode is not desirable). Clients should have access to services from other local networks. Services should be accessible by name (IceGrid). There are no main server. Internet connections may occasionally drop, but this should not lead to a malfunction of the entire system.
Questions:
1. Is it possible to start a service (and register it in the icegridregistry) on a computer that is not running icegridnode?
2. How to maintain a registry (icegridregistry) of all running services from all local networks in the absence of the main server and with unstable connections to the Internet?
3. As I understood, client that knows name of the service connects to icegridregistry and receives an IP-address and port of the server. But in our case, different local networks can use the same private network addresses. How to identify services in this case?
Thanks in advance.

Comments

  • benoitbenoit Rennes, FranceAdministrators, ZeroC Staff Benoit FoucherOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Hi,

    For a new project, I recommend to try out Ice 3.6b instead.

    With IceGrid, you don't necessarily have to use the IceGrid node, the "dynamic registration" mode of IceGrid allows servers to be started by "hand". These servers will register their endpoints with the IceGrid registry.

    The servers register their endpoints with the IceGrid registry when its object adapters are activated. It doesn't need to contact the registry again until its deactivated/shutdown. When the object adapters are deactivated, the server clears its endpoints from the IceGrid registry.

    The server endpoints registered with the registry are the object adapter published endpoints. You can override the published endpoints with the object adapter PublishedEndpoints property. In your scenario, those endpoints should contain the public IP address of the gateway and a specific port that is mapped to the server if you want the server to be accessible to clients outside the network through the gateway IP.

    To try this out, you can use the Ice hello demo provided with your Ice distribution.

    For example:
    # Change to the hello demo directory from your Ice demo distribution
    $ cd demo/Ice/hello
    $ mkdir registrydb
    
    # Start an IceGrid registry with dynamic registration enabled
    $ icegridregistry --IceGrid.Registry.Client.Endpoints="tcp -p 4061" \
                            --IceGrid.Registry.Server.Endpoints=tcp \
                            --IceGrid.Registry.Internal.Endpoints=tcp \
                            --Ice.Default.Host=localhost \
                            --IceGrid.Registry.Data=registrydb \ 
                            --IceGrid.Registry.DynamicRegistration \
                            --IceGrid.Registry.Trace.Locator=2
    
    # Start the hello server (add locator and AdapterId configuration first to its configuration file)
    $ echo "Ice.Default.Locator=IceGrid/Locator:tcp -p 4061 -h localhost" >> config.server
    $ echo "Hello.AdapterId=helloAdapter" >> config.server
    $ echo "Hello.PublishedEndpoints=tcp -h localhost -p 10000" >> config.server
    $ ./server
    -- 02/11/15 09:44:07.158 icegridregistry: Locator: registered adapter `"helloAdapter"' endpoints: `dummy -t -e 1.1:tcp -h localhost -p 10000 -t 60000'
    -- 02/11/15 09:44:07.158 ./server: Locator: updated object adapter `"helloAdapter"' endpoints with the locator registry
       endpoints = tcp -h localhost -p 10000 -t 60000
    

    Note that this requires to setup port forwarding on the gateway machine for each server running in the private network. The IceGrid registry will also need to be accessible to all the servers and the published endpoints need to be setup carefully if the server needs to be accessible both within the network and outside the network.

    Another option would be to not use the IceGrid registry but instead implement your own service location mechanism, tailored for your needs.

    Note that we also provide with Ice 3.6b a multicast based locator implementation (which doesn't require IceGrid to locate servers). It is provided with the IceDiscovery plugin. However, I don't think in your case it would be suitable since you are dealing with separate private networks.

    Cheers,
    Benoit.
Sign In or Register to comment.