HTTP Tunnelling for P2PP

P2PP 2.4 introduced the concept of HTTP tunnelling to support user sites with strict security policies. This document describes how tunnelling works, and how to configure P2PP to enable this feature.

In the text below, the term local means "ESO Garching", while remote indicates a user site outside ESO.

Note that some details were left out of this document, for the sake of clarity.

Default setup

P2PP 2.13 (client) is distributed in a default configuration which makes no use of HTTP tunnelling at all. The resulting setup is shown in Fig. 1, and it currently supports the vast majority of P2PP users.

Fig. 1: Default setup; client and server communicate directly

The thicker lines in Fig. 1 represent firewalls. The firewall at the remote site allows connections over ports 1228 and 1229 (both used by P2PP 2.13); alternatively, there is no firewall at all at the remote site. Since our local firewall allows those connections as well, P2PP client and application server can establish a direct RMI connection.

Nota Bene - technical details: the port 1228 is used to connect and query the Application Server, i.e. to locate the RMI server. With the initial query to RMI, the client is informed to perform further communications through 1229. The Application Server is contacted at the address phase2.hq.eso.org .

Secure setup

Some remote sites have a tighter security policy, and do not allow direct connections over arbitrary ports. Such sites must therefore provide an HTTP proxy server; that is, a host which is allowed to make outside connections and service HTTP clients (like Web browsers) behind the firewall. The P2PP client can be configured to connect to the application server through the proxy, and the corresponding setup is shown in Fig. 2.

Fig. 2: Secure setup, using HTTP tunnelling.

This is how the P2PP client obtains a service from the application server through the proxy.
  1. The client attempts a direct connection, which fails because the remote firewall does not allow it.

  2. The client then repackages its request as HTTP, and contacts the HTTP proxy.

  3. The proxy forwards the request to a dedicated local HTTP server, using port 80.

  4. The HTTP server activates a (Java) servlet, which re-transforms the request into the original RMI format, and contacts the P2PP application server on port 1228.
    In other words, the servlet makes an RMI request on behalf of the remote client.

  5. The application server returns the requested information to the servlet.

  6. The servlet packages the application server's reply as HTML, and returns it to the HTTP server; which returns it to the remote HTTP proxy; which returns it to the P2PP client.

  7. The P2PP client (actually, some protocol interface) converts the HTML reply into RMI, closing the cycle.
The expression HTTP tunnelling refers to the process of packaging an RMI request as HTTP, and unpackaging the HTML reply back into RMI.

Performance implications

HTTP tunnelling imposes a performance overhead. Its entity is however difficult to estimate, because it depends on factors outside our control, like the performance of the remote proxy server.

The tests we made seem to indicate that the performance is acceptable; if needed, we can find ways to improve it -- at least as far as the local side of HTTP tunnelling implementation goes.

Configuration

For the P2PP Application server it is transparent whether an RMI request comes from a remote P2PP client or from a local servlet, so no special configuration is needed.

The P2PP client, however, must be instructed to try HTTP tunnelling if direct RMI connection to the application server fails.
That can be accomplished by defining two keywords in site.cf or ~/.p2pp.cf:

APPSERVER.HTTPPROXYHOST
Full name of the host running the HTTP proxy server.
For instance: httpproxy.some-uni.de

APPSERVER.HTTPPROXYPORT
Port on which the HTTP proxy server accepts connections; should normally be set to 80, but it depends on the proxy configuration.
Users are advised to contact their network administrators before attempting to setup HTTP tunnelling.

Last modified: 19 Nov 2007