Archived
This forum has been archived. Please start a new discussion on GitHub.
Controlling connection direction
in Help Center
The server/client layout that I have is a single server in a trusted area, and several servers in untrusted areas. I need the server to make connections out (never in), and lock in the connection. For example, I thought of creating a proxy on the central server, and passing the proxy as an argument while connecting out to the outside servers, who could then use the proxy to access the central server.
For example, in the central server:
local_proxy = adapter->add( foo, bar );
proxy_to_untrusted_server = stringToProxy( blah );
proxy_to_untrusted_server->hand_it_proxy( local_proxy );
And in the server in untrusted land:
hand_it_proxy( Prx &p )
{
store_someplace( p );
}
...and later...
p->access_to_secure_server()
However, when the satellite servers in untrusted territory use the proxy, do they end up making additional connection -into- the trusted zone, under the hood? Because that will be blocked by the firewall. How can I structure this setup most efficiently?
--Sean
For example, in the central server:
local_proxy = adapter->add( foo, bar );
proxy_to_untrusted_server = stringToProxy( blah );
proxy_to_untrusted_server->hand_it_proxy( local_proxy );
And in the server in untrusted land:
hand_it_proxy( Prx &p )
{
store_someplace( p );
}
...and later...
p->access_to_secure_server()
However, when the satellite servers in untrusted territory use the proxy, do they end up making additional connection -into- the trusted zone, under the hood? Because that will be blocked by the firewall. How can I structure this setup most efficiently?
--Sean
0
Comments
-
You have to use Glacier2 for this. Since you want your server in the trusted environment to establish connections to the servers in the untrusted environment, you have to add Glacier2 to the servers in such untrusted environment.
This is the opposite of the more common scenario, where you have clients connect to a server behind a Glacier2 firewall, and the server sends callbacks to the clients, using the Glacier2 and the connection that was established from the client to the server. For more information, please have a look at the Glacier2 documentation in the Ice manual.
Ice 2.2 (not the upcoming 2.1) will provide more options to explicitly take control of connections, such as explicitly creating proxies for existing connections. But for now, Glacier2 is the only option.0 -
Actually, we will provide the new features that allow you to take explicit control of connections in the upcoming Ice version 2.1 already. I would therefore recommend that you wait for this version, instead of using Glacier2 in a way it was not intended to be used.
Having said this, it might still be useful to read the chapter about Glacier2 if you require security and session management.0 -
Glacier2 in the mean time
Thanks, I'll read over the Glacier2 chapter again with that in mind. I need to get this out and working in the next month, so I can't wait for a stable version of ICE2.2. However, if there's a better way to do it in the future, I'll take that into account during design. Are there any examples of the way the new connection interface will work, so that I can create a system that can be ported to using it in the near future?0 -
The feature will be available in Ice 2.1 already, which will be available in about two weeks. I will also send you an email with more information shortly.0
