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