

Multicast in Ruby: Building a Peer-to-Peer Chat System - mportiz08
http://tx.pignata.com/2012/11/multicast-in-ruby-building-a-peer-to-peer-chat-system.html

======
smutticus
1) Do NOT use 224.0.0.1! I cannot emphasize this enough. This is the IPv4 all
hosts address and should not be used for mcast applications. IANA has reserved
the 239/8 range for intra-AS mcast applications. Use it. In general using any
address in the 224/8 range is bad for mcast application development. But
especially do not use anything in the 224/24 range.

2) Does Ruby automagically take care of setting the destination Ethernet
address to an IP multicast MAC? I don't see any mention of this but it's
pretty important.

As insaneirish rightly points out, it's really only multicast if it crosses an
L2 boundary and a multicast routing protocol like PIM or DVMRP is involved.
This writeup will most likely only result in poorly formed packets being
broadcast on a local subnet.

------
insaneirish
Some thoughts about multicast. This works great on a single subnet, but it's
likely to just be treated as broadcast (in the absence of IGMP snooping on the
switches). Making multicast work outside a single subnet (even off of the same
router) requires multicast routing to be enabled (and it's usually not,
because doing it without breaking things is complicated).

Now for some comments that apply more generally to multicast (and not for this
low volume chat application). Setting TTL=1 for multicast traffic is often
bad, because it causes the first hop router to have to generate an ICMP time
exceeded message. Having to do this lots and lots and lots of times per second
can crush some legacy router platforms. Speaking as someone who builds
networks just for multicast, we instruct our application developers to always
use a large TTL and tell them we will ensure it doesn't go further than it
should. It's just a practical course of action.

But good job!

~~~
dgregd
> Speaking as someone who builds networks just for multicast

I heard about IP Multicast more than 10 years ago. But it never took off. Or
at least I thought so.

I am really curious what are practical applications of the networks you build.
Do your clients use them for broadcasting video streams or something else?

~~~
zb
IP multicast is used quite extensively for streaming video. Mostly in combined
voice/video/data networks for IPTV (think hotel rooms, but also network
service providers), as well for stuff like e.g. security cameras.

On the public Internet it's still virtually unheard-of afaik, and I expect it
to remain that way indefinitely.

(I used to work on IP multicast support for network switches.)

~~~
fulafel
It used to be pretty popular on the public Internet back when a lot of the use
was by academic institutions.

I remember seeing some NASA stuff (?) on there before the local university
management decided to put up a firewall and break all the interesting IP apps.

ref. <https://en.wikipedia.org/wiki/Mbone>

------
donavanm
" _I've never used multicasting in a real-world application but will be
keeping my eyes open for an opportunity_ ". Don't. Seriously, just don't do
it. I personally know of outages directly attributed to multicast that have
cost more than your $widget will ever make.

 _But_ , you say, _I've got the textbook case of media broadcast!_ Yeah, still
probably not worth it. Check out UDP broadcast, or tiered distribution, or
service and peer discovery. There's another way to do what you want.

 _No way! I know all about multicast forwarding, and every node really does
need all of these packets_ Really? You're going to build reliable delivery at
the application layer? And deliver yet _more_ mcast to _every_ node. And you
won't have contention problems, across your entire domain, for the limited
byte & namespace resources? And it won't be a problem when every packet _must_
be routed to every TOR? Because you _will_ have heterogenous hosts in each
rack subscribed to every available group.

So, really, don't do it. It looks cool. It looks efficient. It looks simple.
It's not. In grown up land it's just not worth it.

