The P2PP Tool - Installation - Troubleshouting
Possible Installation Problems
Java executable not found
Unless you have installed the Java Runtime Environment at the same level as the P2PP installation directory (e.g. if you are using one of the Java tarballs we provide for some platforms), the executable java must be in your PATH. You can try typing the command "java -version" in a terminal window to check this.
Security setup problems
Some sites do not allow direct remote connections over arbitrary ports, thus preventing the direct connection between the P2PP tool in the local installation and the application server at ESO. This difficulty can be normally circumvented by making use of HTTP tunnelling, by which the connection is rerouted through the HTTP proxy server. Setting up P2PP to use HTTP tunneling is described here, as well as in the P2PP User Manual. In the text below, the term local means "ESO Garching", while remote indicates a user site outside ESO.
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 ofP2PP 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 P2PP2.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 .
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.
- The client attempts a direct connection, which fails because the remote firewall does not allow it.
- The client then repackages its request as HTTP, and contacts the HTTP proxy.
- The proxy forwards the request to a dedicated local HTTP server, using port 80.
- 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.
- The application server returns the requested information to the servlet
- 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.
- The P2PP client (actually, some protocol interface) converts the HTML reply into RMI, closing the cycle.
The expression HTTP tunneling refers to the process of packaging an RMI request as HTTP, and unpackaging the HTML reply back into RMI.
HTTP tunneling 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 tunneling implementation goes.
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 tunneling if direct RMI connection to the application server fails.
That can be accomplished by defining two keywords in site.cf or ~/.p2pp.cf:
- Full name of the host running the HTTP proxy server.
For instance: httpproxy.some-uni.de
- 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 tunneling.