Multicasting is the ability to transmit a single stream to multiple subscribers at the same time. Unlike conventional streaming, it does not need one stream per recipient. Instead, there is one stream on any one segment of the network on which there is a subscriber. It is the task of the routers to track subscriptions and to create copies only on an as-needed basis. Unlike broadcasting, segments on which there are no subscribers do not receive the stream. Read the article at FreshMeat.
Introduction to Multicasting
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
VIC, RAT et al are really quite old and past their time. You can do interesting stuff with things like http://streamxpress.net/xcaster (shameless plug), videolan, and a host of other applications. Multicasting is very handy for distributing video in the home, and is the cornerstone of most content delivery networks that use satellite or terrestrial tv encapsulation for data delivery to multiple users with infinite scaleability.
When is the last time you used the mbone?
For me, a decade, almost. The mbone has no use in space or terrestrial communications. And don’t even get me started on so-called annoucement protocols (useless for anything beyond video conference identification) such as SDP/SAP.
As for ‘multicasting killed by P2P’ – that comment doesn’t even make sense, unless you’re saying multicast == mbone, which it is not. In those type of applications, since the infrastructure is not there, P2P is the only logical choice. But P2P is unicast, the complete opposite, and completely useless for specialized delivery applications where multicasting is used.
Multicasting would be perfect for internet radio streams if it weren’t for all the DMCA/CARP/RIAA regulations.It would save on having to have all the dedicated connections to streams as most of the time you’re not expecting any return response from the recepient.
It would be great if Shoutcast could be reworked to be multicasted. (But all the costs of using a commercial Shoutcast provider would have to be reworked since most use a per stream cost model.)
If the regulations didn’t have to track on a per listener basis (like terrestrial radio) this would be more viable.
It’s easy to rework Shoutcast to be multicast-enabled. You don’t even need to recompile, just broadcast to a multicast IP address (224.0.0.0/4, I think).
The barrier to this is: every router between you and the radio station has to be multicast-enabled; if one isn’t, then it won’t work. This is easy to guarantee for purpose-built networks such as the Access Grid (which uses vic/rat and multicast) or your LAN, but for the Internet, we’re not quite there yet.
Yes, to send multicast, you just have to send to an address in the 224.0.0.0/4 address range. Just make sure you don’t send to a reserved or link-local address. If you have your own ASN, you have some multicast address space already assigned via GLOP addressing. (RFC 2770) Yes, IPMc has to be configured across all routers between the senders and receivers, or the SPT can’t be built.
The MBONE (AS 10888) is essentially dead, it was just a whole bunch of DVMRP tunnels built using mrouted. The AS10888 provided an exchange for providers running native multicast prior to MSDP. If you ran PIM-SM, you just put your RP on the router connected to the Mcast peering and ran a dense mode protocol, like DVMRP or PIM-DM over the link to do a flood & prune to advertise all of your S&G information to remote RPs. MSDP works in tandem with BGP when deployed in an interdomain fashion. Pick up “BGP Design and Implemention” from Cisco Press and reach chapter 11 for an extensive discussion on how it works and how to deploy it. (Shameless plug, I know)
With the introduction of IGMPv3 and SSM, we may actually see IPMc services become viable. This is due to a number of security issues with previous versions, where anyone could just start streaming to a group and all of the receivers would also receive the packets. SSM allows people to join specific sources to weed this out. And yes, we can protect against people spoofing their source address to hi-jack a session, using RPF mechanisms.
Multicast is also alive and well in the enterprise, it work great for things like IPTV (streaming video). It is also used extensively in trade room floors (stock trading) with Tibco, a major improvement over their previous method of flooding broadcasts through the whole network using RPs (Different from the RPs mentioned above). Multicast is also used at the link-local level extensively in routing protocols, specifically IGPs, like OSPF, RIPv2, and EIGRP.
Hope this helps,
– Kelson
Quite an informative post. My UK based IPv6 TB began advertising PIM-SM in the last 4 weeks – I have a custom BSD firewall and built pim6sd/pim6dd binaries from KAME, but no such luck really – on the other side of the BSD box sits a XP desktop that happy runs IPv6 and shows me dancing turtle under KAME.
The question I have though, is even if I experiment with pim6sd, what do I do with it next? What applications can I use? How can I experiment?
It largely seems a technology waiting for an answer.
You don’t even need to recompile, just broadcast to a multicast IP address (224.0.0.0/4, I think).
Nope. You need a ‘multicast proxy’ which translates the unicast stream to multicast at the shoutcast server end, and at the receiver does a translation back to unicast. In other words all clients connect to localhost to listen to the broadcast, and the localhost does a IGMP join to receive the broadcast. I’ve done this for sending Shoutcast over digital TV (IP packets stuffed in MPEG2). Works quite well. Ofcourse since you are piping the data you can also add erasure correction codes (some overhead, but you can rebuild lost packets).
You can multicast mp3s just peachy with this:
http://www.live.com/liveCaster/
One thing I can say, is I certainly know why more of the internet is not mcast enabled… It’s a bitch to setup. For two weeks I’ve been trying to find whether Cisco RBE will pass multicast or not, no one seems to know. There is an amazing blackhole of information on the topic, especially on the host side. I won’t even talk about the windows host that I’m trying to get to act as a multicast video server. Googling for that platfrom brings thousands of hits that point you to MCSE-like certification classes. Ugh.
Oh, and does your DSL router support multicast? Excellent question. The answer is, “maybe, but don’t count on it being documented”. We’ve got Zyxels, Broadxent, and Netopias and none of them document their multicast support beyond “this turns igmp on/off”. Quite a hair-pulling, head-banging-on-desk experience really. This is the point where thousands before me said “why bother?”.
I won’t even talk about the crap-ass multicasttech.com mailing list. There’s perhaps one post per month.
There is an amazing blackhole of information on the topic, especially on the host side.
True – but due to the fact that most is done by private companies. This is a niche area, and satellite and other multicast distribution systems usually sell for $100k+.
As for devices – I can’t even name the amount of hardware firewalls, routers, switches and wifi boxes we’ve tossed aside because their backplanes either sucked (packet loss), or they just couldn’t handle multicast period.
BBTV Japan runs video and VOD over DSL, as do a handful of others. Telcos are starting to get the hint that to stay alive vs cable, they need to compete with cable (since cable is starting to provide voip). The only thing they lack is video delivery, and multicast is the only way they can accomplish this feat with their limited bandwidth capacity. Set top boxes from Samsung, Amino and other support multicast video delivery out of the box.
As for the hair-pulling, the only way to make these systems work is to be the provider and control the devices on the network. You can’t do this as a user.