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 gossip daemon (outside the firewall) to register itself (periodically) and to retrieve the initial membership for its group. This is done using TCP. It also establishes a TCP connection to a JRouter daemon (outside the firewall) that 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. JRouter will use the same connection to send incoming messages to the channel that initiated the connection. This is perfectly legal, as TCP connections are fully duplex. Note that, if JRouter 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.
PING has to be given the address and port of the gossip daemon (see 3.7.2 above) and TUNNEL has to be configured with the address and port of the JRouter daemon, e.g.:
"TUNNEL(router_host=janet;router_port=12001):
PING(gossip_host=janet;gossip_port=12002):..."
This setup assumes a JRouter daemon is running on host janet at port 12001 and a gossip daemon is running on the same host at port 12002.
Any time a message has to sent, TUNNEL forwards the message to JRouter, which distributes it to its destination: if the message's destination field is null (send to all group members), then JRouter 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 JRouter. If the destination is a valid member address, then that member's TCP connection is looked up, and the message sent forwarded to it3.11.
To tunnel a firewall using JavaGroups, the following steps have to be taken:
GossipServer -port 12001
JRouter -port 12002
The general setup is shown in fig. 3.5.
First, the gossip and JRouter daemons are created on host B. Note that these should be outside the firewall, and all channels in the same group should use the same gossip and JRouter daemons. When a channel on host A is created, its PING layer will register its address with the gossip daemon and retrieve the initial membership (assume this is C). Now, a TCP connection with JRouter is established by A; this will persist until A crashes or voluntarily leaves the group. When A multicasts a message to the group, JRouter 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 allows for example 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 gossip and JRouter daemons 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 gossip and JRouter daemons constitute 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 JRouter), leading to scalability problems, 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, and finally, it is not always possible to enable outgoing traffic on 2 ports in a firewall, e.g. when a user does not 'own' the firewall.
Therefore, the possibility exists for users of JavaGroups to create their own tunneling mechanisms, modifying for example the TUNNEL layer and the gossip and JRouter daemons3.12.
