Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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]