Using a tunnel to set up a multicast feed

It's important to note, however, that this tunneling mechanism has some limitations (described below), and is not a full substitute for having real multicast connectivity. Before setting up a tunnel, you should first try to set up a proper multicast feed:

1. Ask your Internet Provider whether the router(s) that you use to access the Internet support (or can be reconfigured to support) multicast routing directly, without the need for tunneling.
2. If not, then if you're running a Unix system (anywhere on your local network; not necessarily as a router), you may be able to run "mrouted" on this system, to set up a full IP multicast tunnel to another computer (or router) that's on the Multicast Internet.
3. If neither of these conditions hold (e.g., you connect to the Internet using a Windows PC via a (non-multicast-capable) dialup connection), then you can try using multikit's tunneling mechanism to connect to the Multicast Internet. Ask your Internet Provider to (i) set up its own multicast feed (if it hasn't already done so), and (ii) set up a "liveGate" server with a tunnel to your computer. (Refer them to the URL "http://www.live555.com/liveGate/".) Alternatively, try to find another multicast-connected server (preferably one located close to you) that runs liveGate and will agree to set up a tunnel to you.

To set up a tunnel, use the "Set up an MBone tunnel" command in multikit's "Tunneling" menu. You will need to enter the remote endpoint of the tunnel (as either a domain name or an IP address).

• If the remote endpoint has more than one IP address, then the address that you specify in the tunnel-setup dialog should be the source address that this endpoint uses when sending packets to you. One way to find this is to look at the IP address that the remote "liveGate" server outputs (on the console) as it starts up. This is likely to be the address to use.
• If you shut down and restart multikit, any tunnel that you previously set up will be reestablished automatically once you restart.
• You should not attempt to set up a tunnel if you are already connected to the Multicast Internet (either directly, or via another tunnel elsewhere on your local network). multikit (& liveGate) will detect any unnecessary tunnel, and shut it down. Before it is detected, however, an unnecessary tunnel may temporarily cause extra (duplicate) data to be sent over the Internet.

  (An unnecessary tunnel is detected by (i) checking for an incoming multicast packet whose source address is the endpoint of our tunnel, and (ii) periodically multicasting a 'status' packet to a common group address/port, and checking whether it ever gets looped back to us. These are the same techniques used by Peter Parnes's "mTunnel" - a similar tunneling mechanism that was developed independently.)

• When setting up a tunnel, the "tunnel locally only" checkbox should be left on. (Exception: If you are using a tunnel to connect two copies of multikit (rather than multikit<->liveGate), then this checkbox should be turned off on the multikit that's already on the Multicast Internet.)

  The "tunnel locally only" checkbox has the following effect:

  • Incoming decapsulated packets are not multicast beyond TTL 0, and
  • Received multicast packets from other nodes are not sent over the tunnel
  This helps prevent accidental tunneling loops (see above).

To shut down a tunnel that you've previously created, use the "Shut down tunnel" command in multikit's "Tunneling" menu.

Monitoring the status of a tunnel

Limitations of multikit's tunneling mechanism

1. The application must be launched by multikit, and multikit must remain running while the application is running.
2. The application must use UDP/IP multicast - not 'raw' IP multicast.
3. All multicast address(es)/port(s) used by the application must be made known to multikit (or to any 'invoked command' script that multikit uses to implement the application).
4. The application must allow outgoing multicast packets to be looped back, and must allow other processes on the same machine to use the same multicast address(es)/port(s). (I.e., the application must have set the SO_REUSEADDR and SO_REUSEPORT socket options.)
5. The application must not rely upon the source address of its incoming multicast packets being different for different original data sources. In particular, it must not use source addresses to identify these original data sources.
6. The application must accept multicast packets that come from a different process on the same machine. In particular, it must not erroneously reject such packets because it thinks they are merely looped-back packets from itself.

Troubleshooting