JPPF, java, parallel computing, distributed computing, grid computing, parallel, distributed, cluster, grid, cloud, open source, android, .net
JPPF, java, parallel computing, distributed computing, grid computing, parallel, distributed, cluster, grid, cloud, open source, android, .net

The open source
grid computing

 Home   About   Features   Download   Documentation   Forums 

TCP Multiplexer

From JPPF 2.5 Documentation

Jump to: navigation, search


Main Page > TCP Multiplexer

We have seen in the Configuration guide 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.

1 Architecture

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

2 Configuration

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:


3 Deployment

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"
Main Page > TCP Multiplexer

JPPF Copyright © 2005-2018 Powered by MediaWiki