[REBOL] Re: I think I've figured out IGMP...
From: holger:rebol at: 23-Aug-2001 9:51
On Thu, Aug 23, 2001 at 12:06:57AM -0400, Porter Woodward wrote:
> OK -
>
> after some experimentation I think I've figured out how to handle multicasting in REBOL.
Yes, that's basically right.
> Of course, this isn't exactly new - it's how streaming media multicasts have worked
for the last couple of years, along with Microsoft's own WINS...
AFAIR WINS (name lookups etc. for NetBIOS over IP) uses broadcasting. As for streaming
media:
It's how streaming media should have worked. In reality most streaming media uses ordinary
unicasts. Multicasting is usually only used between *live* media sources and participating,
large ISPs, to reduce the load on the ISP's Internet link and the backbone. Multicasting
all the way to the user is very, very rare. The "MBone" is one of the few exceptions,
but
it is not suitable for the casual user.
The problem with multicasting is that there are two parts to it: there is multicasting
within a LAN, which is pretty easy, just by mapping multicast IP addresses to multicast
Ethernet addresses. Only works in a LAN though. Then there is wide-area multicasting,
which requires the propagation of "membership lists" between participating routers
("multicast routers"), so routers can build distributed membership and propagation
trees. IGMP is used by clients to tell multicast routers which addresses they are
interested in. Routers then collect and forward that information using their own
protocols (various versions) to build the distributed trees.
The problem is that multicast protocols (between routers) are still evolving, and
that most routers on the Internet do not support multicasting at all (or are not
configured to do so), so they never listen to IGMP or forward membership information.
That means your multicast subscription usually does not leave your LAN. The workaround
is to create "multicast tunnels" between multicast routers, but that requires complicated
configurations and makes the use of multicasting rather messy. The MBone uses such a
set of multicast tunnels to propagate multicast information Internet-wide.
REBOL's 'multicast-groups set/get-modes option maps to the TCP/IP kernel's
multicast membership API (for BSD-derived kernels this is IP_ADD/DROP_MEMBERSHIP),
and the kernel then translates this into the necessary IGMP requests. IGMP is never
something implemented at the application level. It is a kernel-level protocol
just like ICMP.
Depending on your OS and environment you may end up in one of three situations:
- Your OS does not support multicasting at all. This is true for old Unix versions,
for some newer Unix versions that do not have multicasting compiled, enabled or
configured in the kernel, for Elate, for BeOS, and for AmigaOS stacks other than
Miami(Dx).
- Your OS supports multicasting, but your next-hop router does not support it, and
you do not have a multicast tunnel. In that case multicasting works only in your
LAN. You might just as well use broadcasting, except multicasting has the advantage
that the CPU load on those machines in your LAN which are not interested in your
messages is lower, i.e. multicasting is a little more efficient than broadcasting.
- Your OS supports multicasting and you have a multicast-capable connection out of
your LAN, either through a multicast router or through a multicast tunnel, e.g.
to the MBone or some other multicast network or LAN. In that case multicasting works
within the whole multicast network you are connected to. This is where multicasting
gets interesting and more useful than broadcasting, but most users don't have setups
like this.
--
Holger Kruse
[holger--rebol--com]
