Internet Futures - Access Grid Projects

Projects - rcb-forward

rcb-forward is a small, java, command-line tool designed to be used in conjunction with rcbridge to allow machines on multicast disabled subnets to (almost) transparently use multicast. You will need to understand (and be able to access an) rcbridge before you use rcb-forward.

It automates the process of:

connecting to rcbridge,

communicating with rcbridge to create multicast to unicast tunnels,

remulticasting onto the local subnet unicast packets received from rcbridge,

unicasting to rcbridge multicast packets received from the local subnet,

maintaining a connection with rcbridge so the tunnels don't time out.

Installing and running rcb-forward

The rcb-forward application is contained in the rcbforward.jar file, which you can download here:

Note that this code is released (c)ANU Internet Futures, 2003.
No warranties implied, you take this code AS IS. Use at your own risk

rcb-forward 1.0.0 (29kB, 21 Nov 2003)

The application was compiled against JDK 1.4.1-02 and uses classes that are not available before Java 1.4. We have found that the current JVM-1.4 for FreeBSD is extremely buggy, and does not work properly.

Save the above file into some convenient directory, and ungzip it. To start rcb-forward, you'll need to know what multicast group(s) you want to connect to (address/port), and the address and port of an rcbridge service. Then enter:

java -cp rcb-forward-1.0.0.jar RcbForwardMain [options]

(note that the capitalisation of the class is important). The options include:

	 --help  | -h                        show usage
	 --proxy | -p   [addr/port]          proxy address for rcbridge
	 --video | -v   [addr/port/(ttl)]    multicast group to tunnel for video, and re-multicast ttl
	 --audio | -a   [addr/port/(ttl)]    multicast group to tunnel for audio, and re-multicast ttl
	 --debug | -d                        turn debugging output on

proxy:
The proxy parameter must be specified. It is the ip address of the machine running rcbridge and the tcp port rcbridge is configured to listen to.

video / audio:
At least one of these must be specified. It is the multicast group and port to tunnel between rcbridge and rcbforward. It is also the group and port that rcb-forward will remulticast packets onto on the local subnet. The ttl is set only for multicast packets being sent out locally. You probably only want to have this set to 1 unless you know what you are doing.

How rcb-forward talks to rcbridge

rcb-forward will attempt to establish a http connection to rcbridge at the specified ip address and port, and send the message 'GET /' which rcbridge will interpret as a new client attempting to connect. rcbridge will spawn a new client process and send a message back telling the client to connect to a client specific port. rcb-forward will parse the response looking for a line starting with '>meta http-equiv='. The client port is contained in that line. After the client port is obtained rcb-forward will reconnect to rcbridge on the client port

It will then (via http):

Set the bridge timeout time

Turn autoforwarding on

Create tunnels

rcb-forward will then send another 'GET /' request and parse the response. If rcbridge has been able to create the bridges the response will contain the line  where XXXX is the unicast port packets are being sent to from rcbridge and also the port rcbridge is listening to for unicast packets from the client.

Every 90 seconds rcb-forward will reconnect to rcbridge and set the bridge timeout to 2 minutes. If a connection cannot be established rcb-forward will wait a few seconds and try again. rcb-forward will stop trying to connect after 5 consecutive unsuccessful attempts. Thus the rcb-forward application can be arbitrarily killed and at most traffic will only be forwarded for another 2 minutes.

This will be done twice if both audio and video bridges and needed. (ie rcb-forward maintains 2 client connections to rcbridge)

At the moment rcb-forward is hard-coded for rtp/rtcp bridges. Thus 4 bridges are created:

a (unicast_port) -> (multicast_port) bridge [rtp inbound]
a (multicast_port) -> (unicast_port) bridge [rtp outbound]

a (unicast_port+1) -> (multicast_port+1) bridge [rtcp inbound]
a (multicast_port+1) -> (unicast_port+1) bridge [rtcp outbound]

If both audio and video bridges are to be created then this process is repeated thus creating 8 bridges all up.

Issues and plans

It is possible to create loops or at least duplication of traffic with rcbridge and rcb-forward, especially in areas with fickle multicast connectivity. Appropriate use of ttl's may assist to minimise this, but it needs to be made more robust.

The rcb-forward code presumes rtp/rtcp, and is thus a bit overenthusiastic at setting up bridges. A general-multicast bridge needs half the number.

Conversely, one may want more than just 1 audio + 1 video bridge, any arbitrary number should be supported.

rcb-forward does not yet support stream selection the way rcbridge does. So using rcb-forward on narrow bandwidth links is risky. You can manually intercede in the tunnels, using a web browser and working out what port rcbridge is listening to rcb-forward on, but it's clumsy.

Feedback

We are looking for feedback on rcb-forward and how to make it more useful to users. You can email us with comments.