Using TUNNEL and Router to tunnel firewalls

JavaGroups tunneling solution works as follows. A channel inside a firewall has to use protocol layer TUNNEL instead of UDP as bottommost layer in the stack. This layer uses the Router daemon (outside the firewall) to connect to and to retrieve the initial membership for its group. This is done using TCP. It establishes a TCP connection to the Router (outside the firewall) which accepts messages from members and passes them on to other members. This connection is initiated by the host inside the firewall and persists as long as the channel is connected to a group. The Router will use the same connection that initiated the connection to send incoming messages to the channel. This is perfectly legal, as TCP connections are fully duplex. Note that, if the Router tried to establish its own TCP connection to the channel behind the firewall, it would fail. But it is okay to reuse the existing TCP connection, established by the channel.

The PING protocol uses the Router to obtain its initial membership: it connects to the Router briefly (giving the groupname) and the Router returns the currently registered members for that group. To do so, PING has to be given the address and port of the Router (same address and port as used in TUNNEL), e.g.:

        "TUNNEL(router_host=janet;router_port=8080):
         PING(router_host=janet;router_port=8080):..."

This setup assumes a Router daemon is running on host janet at port 8080. (Of course, if a firewall only allows TCP connections to port 80, then the Router would have to be started on port 80).

Any time a message has to sent, TUNNEL forwards the message to Router, which distributes it to its destination: if the message's destination field is null (send to all group members), then Router looks up the members that belong to that group and forwards the message to all of them via the TCP connection they established when connecting to Router. If the destination is a valid member address, then that member's TCP connection is looked up, and the message sent forwarded to it^3.11.

To tunnel a firewall using JavaGroups, the following steps have to be taken:

1.

Check that TCP port 8080 is enabled in the firewall for outgoing traffic. ^3.12

2.

Start the Router:

              Router -port 8080

3.

Configure the TUNNEL and PING protocol layers as instructed above.

4.

Create a channel and proceed as usual. Note that the application does not have to be changed at all.

The general setup is shown in fig. 3.5.

  

Figure 3.5: Tunneling a firewall

First, the Router daemon is started on host B. Note that host B should be outside the firewall, and all channels in the same group should use the same Router daemon. When a channel on host A is created, its PING layer will register its address with the Router and retrieve the initial membership (assume this is C). Now, a TCP connection with Router is established by A; this will persist until A crashes or voluntarily leaves the group. When A multicasts a message to the group, Router looks up all group members (in this case, A and C) and forwards the message to all members, using their TCP connections. In the example, A would receive its own copy of the multicast message it sent, and another copy would be sent to C. This scheme permits Java applets, which are only allowed to connect back to the host from which they were downloaded, to use JavaGroups: the HTTP server would be located on host B and the Router daemon would also run on that host. An applet downloaded to either A or C would be allowed to make a TCP connection to B. Also, applications behind a firewall would be able to talk to each other, joining a group.

However, there are several drawbacks: first, the central Router daemon constitutes a single point of failure (if host B crashes), second, having to maintain a TCP connection for the duration of the connection might use up resources in the host system (e.g. in the Router), leading to scalability problems, and third, this scheme is inappropriate when only a few channels are located behind firewalls, and the vast majority can indeed use IP multicast to communicate.

Therefore, the possibility exists for users of JavaGroups to create their own tunneling mechanisms, modifying for example the TUNNEL layer Router daemon^3.13.