The open source
grid computing

 Home   About   Features   Download   Documentation   Forums 

JPPF And Networking

From JPPF Documentation

Jump to: navigation, search


Main Page > JPPF And Networking

What this page is about

This page is a discussion about how to integrate and work with JPPF in specific network environments.
Here, we will present a number of tools, techniques and configurations to help work with firewalls, proxies, and other types of constraints that can be found in many networks.
We intend to expand this page throughout time, to include new discoveries and findings that are deemed useful in this regard.

The TCP port multiplexer

We have seen in the Configuring section that JPPF requires at least 3 TCP ports to function. In network environments where a policy imposes the use of a firewall, these ports will generally be blocked, preventing any traffic through unauthorized ports.

This situation is very common, and in the case of JPPF, is very difficult, even nearly impossible, to work around. To address this situation, we have implemented a tool called TCP port multiplexer, that enables the routing of network traffic from multiple ports to a single port on one side, and the routing of the same traffic from a single port to multiple ones on the other side.

With this tool, it becomes possible to work with JPPF in firewalled environments, without having to deploy a complex hardware/software infrastructure. It also comes as a component separate from JPPF clients, servers and nodes, which means that client applications continue to use and deploy JPPF in exactly the same way as they already do.


To understand how the multiplexer works and how it integrates with a JPPF grid, let's take the example of a typical JPPF configuration:

  • the JPPF client, server and node are all on separate machines and use the default ports 11111, 11112 and 11113
  • the network environment includes a firewall that will only let traffic through port 443

This results in a configuration illustrated by the following figure:


A directed red arrow represents an incoming connection. The small circle at one end means that the corresponding component is listening for connections on the specified port.

This architecture bears a number of remarks:

  • nodes and clients connect to the multiplexer as if it were a local JPPF server
  • the JPPF server accepts connections from the multiplexer as if they came from local clients and nodes
  • the multiplexing and demultiplexing of the network traffic is completely transparent to the JPPF components
  • the multiplexer implementation is based on the same network communication APIs used in JPPF, and incurs the same benefits in terms of scalability, robustness and reliability
  • as additional network routing steps are added, a performance decrease should be expected, compared to a non-multiplexed JPPF grid
  • in this configuration, management and monitoring of the nodes and server is not possible, and should be disabled for the nodes and servers behind a firewall


In terms of configuration, we have seen in the #Architecture section that the multiplexer plays a different role, depending on whether it is on the JPPF server machine or not:

  • a multiplexer on a JPPF server host only needs to listen to connections on a multiplexing port
  • a multiplexer on a JPPF client or node host binds to the JPPF ports, as if it were a server. It needs to know which ports to bind to, and for each bound port which remote multiplexer to route the traffic to.

This is illustrated in the following figure:


Here is a full configuration example for a server host:

 # Local forwarding port this multiplexer listens to                            #
 # The local port number to which to forward messages to is the first message   #
 # sent by any inbound connection                                               #
 multiplexer.ports = 443

And for a non-server host:

 # Names of the remote multiplexers to connect to                               #
 remote.multiplexers  = m1
 # Host and port corresponding to the named multiplexer                         #
 remote.multiplexer.m1 = server_host:443
 # Local ports this multiplexer listens to                                      #
 bound.ports = 11111 11112 11113
 # Mapping of the bound ports to remote multiplexers (1 per port)               #
 # Communications with the bound ports will be forwarded to and from the        #
 # multiplexer                                                                  #
 mapping.11111 = m1
 mapping.11112 = m1
 mapping.11113 = m1


  • The clients and nodes must use, in their multiplexer configuration, the same port numbers as those specified for the JPPF server. These port numbers are actually sent to the server multiplexer, so that it knows how to re-route the traffic.
  • The JPPF host specified in the clients and nodes configuration must be set to localhost or, as they connect to the local multiplexer.

Another use case is when you have not only a JPPF server, but also a client or a node on the same machine.
In this case, the node or client does not need a multiplexer, as it will connect locally to the JPPF server.
This is illustrated in this figure:



Each multiplexer instance is deployed as a separate process. It has its own configuration file and logging configuration file, as for the JPPF components.

The TCP port multiplexer is released in its own package, so it can be easily deployed on any machine. It is the package named available on the JPPF download page.

To run the multiplexer:

  • unzip the anywhere on your hard drive
  • for a server host:
    • edit the config/ file and set the appropriate values for your environment
    • from a shell or command prompt, run the Ant target "ant run.multiplexer.server"
  • for a client or node host with no JPPF server:
    • edit the config/ file and set the appropriate values for your environment
    • from a shell or command prompt, run the Ant target "ant run.multiplexer"

Support This Project Powered by MediaWiki