Ice Server as Client

mariolokomarioloko Adrián Gallego CastellanosOrganization: Carlos III University of MadridProject: Distributed Robot System on the CloudMember

Hello,

I am trying to deploy an Ice Architecture formed by a Client Application and a Server Application running in different networks and each one with its own firewall. In this architecture the server have to perform as client, this means that is the server the one that perform requests asking for data to the client(that act like a server serving data) when there are free resources on the server.

My first guess is that the best solution would be to use a publisher/subscriber communication being Server = Publisher and Client = Subscriber. In order to implement this solution I tried with IceBox, but after a further reading I saw that IceBox does not allow to return values in the interfaces and my interfaces need bidirectional connection.

And Example of how it would be my interface it would be something like this:

module Robot {
    enum JointType {...}
    interface Control {
        bool isRobotConnected();
        bool setAngle(JointType joint, float angle); /* Here bool stands for success in performing the operation. */
    };
};

Is there any Ice Service that allow to perform this communication having the Server performing the requests as if it where the client, or having it as a Publisher in a one to one channel and allowing return values.

NOTICE: The IP of the server is static and it can be known by the client before establishing any connection but the client IP is not known until a connection is performed.

NOTICE 2: It is possible to define which firewall ports will be opened in the server but it is not possible to define it in the client.

Best Answer

  • bernardbernard Jupiter, FLBernard NormierOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Accepted Answer

    Hello Adrián,

    Your architecture is very common - clients and server protected by firewalls and clients and server sending requests and hosting servants.

    IceBox allows you to hosts one or more IceBox Services in the same process: you can see an IceBox service as an Ice server that shares its process with other IceBox service. This can be useful to reduce the number of processes running on your computer. However, using IceBox does not help or hinder with firewall traversal and bi-dir communications, it's completely independent.

    Modeling your communications as publisher-subscriber instead of client-server doesn't make a difference either. A publisher corresponds to a client (it sends requests or data), while a subscriber corresponds to a server (it receives requests or data). BTW if you're interested in pub-sub, check out DataStorm!

    The service that could help you here is Glacier2. You could deploy a Glacier2 instance on the same computer (or at least LAN) as your server. This would give you an authentication mechanism (to control which clients can connect to your server) and also automatic bi-dir connections between your clients and the Glacier2 instance.

    Now, Glacier2 is even more useful when you have more than one servers, as it allows you to open a single port on your firewall to reach all these servers from the outside. With only one server, you could use direct client-server communications and handle authentication and bi-dir communications yourself.

    Cheers,
    Bernard

Answers

  • bernardbernard Jupiter, FLBernard NormierOrganization: ZeroC, Inc.Project: IceAdministrators, ZeroC Staff ZeroC Staff
    Accepted Answer

    Hello Adrián,

    Your architecture is very common - clients and server protected by firewalls and clients and server sending requests and hosting servants.

    IceBox allows you to hosts one or more IceBox Services in the same process: you can see an IceBox service as an Ice server that shares its process with other IceBox service. This can be useful to reduce the number of processes running on your computer. However, using IceBox does not help or hinder with firewall traversal and bi-dir communications, it's completely independent.

    Modeling your communications as publisher-subscriber instead of client-server doesn't make a difference either. A publisher corresponds to a client (it sends requests or data), while a subscriber corresponds to a server (it receives requests or data). BTW if you're interested in pub-sub, check out DataStorm!

    The service that could help you here is Glacier2. You could deploy a Glacier2 instance on the same computer (or at least LAN) as your server. This would give you an authentication mechanism (to control which clients can connect to your server) and also automatic bi-dir connections between your clients and the Glacier2 instance.

    Now, Glacier2 is even more useful when you have more than one servers, as it allows you to open a single port on your firewall to reach all these servers from the outside. With only one server, you could use direct client-server communications and handle authentication and bi-dir communications yourself.

    Cheers,
    Bernard

  • mariolokomarioloko Adrián Gallego CastellanosOrganization: Carlos III University of MadridProject: Distributed Robot System on the CloudMember
    edited December 7

    Hello Bernard,

    Thanks for your answer. After reading your answer I've been playing around with the Glacier2 demos and I tried to simplify my problem just to check if Glacier2 was the solution and in fact this solves the firewall problem for both client and server. That's AWESOME!!

    Thank you,
    Adrián Gallego Castellanos

Sign In or Register to comment.