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

I think I've figured out IGMP...

 [1/4] from: pwoodward::cncdsl::com at: 23-Aug-2001 0:06


OK - after some experimentation I think I've figured out how to handle multicasting in REBOL. -=First instance of REBOL=- 1> Open a UDP "listener": udp: open udp://:9999 ; from the docs 2> Use set-modes to "join" a multicast group: set-modes udp [multicast-groups: [[224.0.1.89 your.ip.address.here]]] 3> Wait for incoming data... print copy udp -=Second instance of REBOL=- Now - you probably want to send the listener some data... 1> Open a UDP "sender": udp: open udp://224.0.1.89:9999 2> Send some data... insert udp "test" At this point, you should see the "test" appear in the first instance of REBOL. Now - what's really pretty cool about this is that if you have REBOL running on one or more systems - you can setup 2 or more listeners as described in the first portion - and data sent by the "sender" in the second part should reach _all_ of them w/o you having to explicitly address each of them!!! 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... But - hey REBOL makes it pretty easy. And here I thought I'd have a major struggle on my hands. Now to see if I can cobble together a crude "streaming media" server or not with this sort of thing... At least something like this should make a chat "room" style application easier (if RIM isn't already using it). - Porter Woodward

 [2/4] from: m:koopmans2:chello:nl at: 23-Aug-2001 6:46


Porter, Please be aware that a lot of routers don't support multicast. This is what makes it hard to do that kind of applications. Most streaming media apps use their own TCP based protocol, I think. Of course on Intranets you may not have this problem, and REBOLs elegance always helps! --Maarten
> OK - > > after some experimentation I think I've figured out how to handle
multicasting in REBOL.
> -=First instance of REBOL=- > 1> Open a UDP "listener":
<<quoted lines omitted: 10>>
> insert udp "test" > At this point, you should see the "test" appear in the first instance of
REBOL. Now - what's really pretty cool about this is that if you have REBOL running on one or more systems - you can setup 2 or more listeners as described in the first portion - and data sent by the "sender" in the second part should reach _all_ of them w/o you having to explicitly address each of them!!!
> 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... But - hey REBOL makes it pretty easy. And here I thought I'd have a major struggle on my hands. Now to see if I can cobble together a crude streaming media server or not with this sort of thing... At least something like this should make a chat "room" style application easier (if RIM isn't already using it).

 [3/4] 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]

 [4/4] from: pwoodward:cncdsl at: 23-Aug-2001 13:38


Holger - thanks for the clarification. I sort of figured that most things don't end up using true multicasts.
> 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.
Yup - the LAN multicasting is working great! I setup what I called a heartbeat server, which was (broad)multicasting "lub-dub" every 5 seconds. I then went two two other systems on the LAN and created a UDP "listener" and used set-modes to get it to join the 224.0.1.89 group. Both of the clients on the LAN were able to get the message. Pretty cool - and ideal for some small applications I have in mind (a front-door web-cam, with multi-cast updates for in house use).
> 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.
Cool - I figured that out after reading the chapter on it. Most routers which do manage multicasts poll every 125 seconds or so for new reports. Unfortunately, as you've observed, not many routers are a) multicast capable or b) compatible with one another for multicast purposes. In essence, my set(ting) of multicast-group is ultimately translated by the network stack into a join - and my network card stops ignoring packets that are addressed to 224.0.1.89.
> - 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.
That's me! I sort of do - but the Multicasts are still only effective on a pretty small portion of the network as a whole. People who are "near" my network segment with XO seem to be able to get my multicasts. But, once we leave the XO network - I'm dead. So, I can multicast a little outside my LAN - but not far enough to be really interesting... :( So I can't adapt my front-door cam idea to let me watch the front door at work via a multicast. Sure, I can still push it to an accessible URL, but I thought it'd be cool to multicast it - especially if I could encrypt it (I'm using View/Pro). - Porter Woodward

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted