Table of Contents Previous Next
Logo
Glacier2 : 42.2 Introduction
Copyright © 2003-2010 ZeroC, Inc.

42.2 Introduction

We have presented many examples of client/server applications in this book, all of which assume that the client and server programs are running either on the same host, or on multiple hosts with no network restrictions. We can justify this assumption because this is an instructional text, but a real-world network environ­ment is usually much more complicated: client and server hosts with access to public networks often reside behind protective router-firewalls that not only restrict incoming connections, but also allow the protected networks to run in a private address space using Network Address Translation (NAT). These features, which are practically mandatory in today’s hostile network environments, also disrupt the ideal world in which our examples are running.

42.2.1 Common Scenarios

Let us assume that a client and server need to communicate over an untrusted network, and that the client and server hosts reside in private networks behind fire­walls, as shown in Figure 42.1.
Figure 42.1. Client request in a typical network scenario.
Although the diagram looks fairly straightforward, there are several troublesome issues:
• A dedicated port on the server’s firewall must be opened and configured to forward messages to the server.
• If the server uses multiple endpoints (e.g., to support both TCP and SSL), then a firewall port must be dedicated to each endpoint.
• The client’s proxy must be configured to use the server’s “public” endpoint, which is the host name and dedicated port of the firewall.
• If the server returns a proxy as the result of a request, the proxy must not contain the server’s private endpoint because that endpoint is inaccessible to the client.
To complicate the scenario even further, Figure 42.2 adds a callback from the server to the client. Callbacks imply that the client is also a server, therefore all of the issues associated with Figure 42.1 now apply to the client as well.
Figure 42.2. Callbacks in a typical network scenario.
As if this was not complicated enough already, Figure 42.3 adds multiple clients and servers. Each additional server (including clients requiring callbacks) adds more work for the firewall administrator as more ports are dedicated to forwarding requests.
Figure 42.3. Multiple clients and servers with callbacks in a typical network scenario.
Clearly, these scenarios do not scale well, and are unnecessarily complex. Fortu­nately, Ice provides a solution.

42.2.2 What is Glacier2?

Glacier2, the router-firewall for Ice applications, addresses the issues raised in Section 42.2.1 with minimal impact on clients or servers (or firewall administra­tors). In Figure 42.4, Glacier2 becomes the server firewall for Ice applications. What is not obvious in the diagram, however, is how Glacier2 eliminates much of the complexity of the previous scenarios.
Figure 42.4. Multiple clients and servers with callbacks using Glacier.
In particular, Glacier2 provides the following advantages:
• Clients often require only minimal changes to use Glacier2.
• Only one front end port is necessary to support any number of servers, allowing a Glacier2 router to easily receive connections from a port-forwarding firewall.
• The number of connections to back end servers is reduced. Glacier2 effec­tively acts as a connection concentrator, establishing a single connection to each back end server to forward requests from any number of clients. Simi­larly, connections from back end servers to Glacier2 for the purposes of sending callbacks are also concentrated.
• Servers are unaware of Glacier2’s presence, and require no modifications whatsoever to use Glacier2. From a server’s perspective, Glacier2 is just another local client, therefore servers are no longer required to advertise “public” endpoints in the proxies they create. Furthermore, back-end services such as IceGrid (see Chapter 38) can continue to be used transparently via a Glacier2 router.
• Callbacks are supported without requiring new connections from servers to clients (see Section 42.4). In other words, a callback from a server to a client is sent over an existing connection from the client to the server, thereby elimi­nating the administrative requirements associated with supporting callbacks in the client firewall.
• Glacier2 requires no knowledge of the application’s Slice definitions and therefore is very efficient: it routes request and reply messages without unmar­shalling the message contents.
• In addition to its primary responsibility of forwarding Ice requests, Glacier2 offers support for user-defined session management and authentication, inac­tivity timeouts, and request buffering and batching.

42.2.3 How it works

The Ice core supports a generic router facility, represented by the Ice::Router interface, that allows a third-party service to “intercept” requests on a properly-configured proxy and deliver them to the intended server. Glacier2 is an imple­mentation of this service, although other implementations are certainly possible.
Glacier2 normally runs on a host in the private network behind a port-forwarding firewall (see Section 42.11), but it can also operate on a host with access to both public and private networks. In this configuration it follows that Glacier2 must have endpoints on each network, as shown in Figure 42.5.
Figure 42.5. Glacier2’s client and server endpoints.
In the client, proxies must be configured to use Glacier2 as a router. This configu­ration can be done statically for all proxies created by a communicator, or programmatically for a particular proxy. A proxy configured to use a router is called a routed proxy.
When a client invokes an operation on a routed proxy, the client connects to one of Glacier2’s client endpoints and sends the request as if Glacier2 were the server. Glacier2 then establishes a client connection to the intended server, forwards the request, and returns the reply (if any). Glacier2 is essentially acting as a local client on behalf of the remote client.
If a server returns a proxy as the result of an operation, that proxy contains the server’s endpoints in the private network, as usual. (Remember, the server is unaware of Glacier2’s presence, and therefore assumes that the proxy is usable by the client that requested it.) Of course, those endpoints are not accessible to the client and, in the absence of a router, the client would receive an exception if it were to use the proxy. When that proxy is configured with a router, however, the client ignores the server’s endpoints and only sends requests to the router’s client endpoints.
Glacier2’s server endpoints, which reside in the private network, are only used when a server makes a callback to a client. See Section 42.4 for more information on callbacks.

42.2.4 Limitations

Glacier2 has the following limitations:
• Datagram protocols, such as UDP, are not supported.
• Callback objects in a client must use a Glacier2-supplied category in their identities (see Section 42.4).

Table of Contents Previous Next
Logo