The Best Idea in Networking That Nobody Deployed
Unicast sends to one machine and scales badly when many want the same thing. Broadcast reaches everybody and wastes the time of everybody who does not care.
Multicast is the obvious answer to both, and it is elegant. A sender transmits one copy. Machines that want it join a group. The network duplicates the packet only where the paths to two members diverge, and nowhere else.
Each router copies a packet only when it has members down more than one interface. A link carries at most one copy of the stream, however many members are beyond it.
A machine that has not joined receives nothing at all, which is exactly what separates this from broadcast.
This is arithmetic rather than a benchmark, and the flat line is the whole argument for the protocol.
The difference between multicast and broadcast is not visible on this chart, because it is not about the sender. It is about who else pays.
So multicast gives you the profile of broadcast with the targeting of unicast. It has worked for thirty years. It carries an enormous amount of real traffic today.
And it is essentially absent from the public internet, which is the more interesting half of this lesson.
A Group Address Is Not a Machine
The whole of 224.0.0.0/4 is multicast, which is one sixteenth of the IPv4 address space set aside for this. A group address does not belong to any device. It names a conversation that devices can join.
Where in that range your group sits changes what happens to your packets.
224.0.0.0/24 is the one worth memorising. Routers must never forward it, whatever the hop limit says, and that is a rule in the router rather than a consequence of .
That is where OSPF, IGMP and mDNS live, because all three are conversations between neighbours on one wire.
How the Network Knows Who Wants It
Every question in multicast reduces to one: how does each router know whether it has any members down each of its interfaces?
On a single subnet: IGMP
Membership is soft state: it expires unless somebody keeps confirming it.
That is the right design here. If a host crashes it never sends a leave, and hard state would never be cleaned up. Expiring by default means a dead member costs you one query interval and nothing more.
And the switch has to care too
Where the Model Meets the Cable
Everything above happens at the IP layer. A network card cannot filter on IP addresses at all, so there is one more step that is rarely taught and produces a genuinely surprising consequence.
The mapping is arithmetic with no lookup: a fixed prefix, then the low 23 bits of the group address. Twenty-eight bits do not fit in twenty-three.
So 32 distinct group addresses arrive at the card as the same hardware address.
Neither the joins nor the arithmetic are theoretical. Both are printable on an ordinary laptop that nobody has configured for multicast.
Why It Is Not on the Internet
A protocol this efficient not being used everywhere needs an explanation, and "ISPs found it complex" is only part of it.
The technical requirement is that every router on every path has to cooperate. The business requirement is harder: transit networks carry copies that nobody pays them for.
Without congestion control a multicast stream cannot be a good citizen on a shared link, and a group has no access control, so anybody can inject traffic into somebody else's stream.
Three of those deserve to be seen rather than listed.
The Model That Fixes Most of This
Almost every problem above comes from one design decision made in the 1980s: you join a group, and anybody may send to it.
Under any-source multicast the network has to discover who is sending, and that discovery is what rendezvous points and shared trees exist to do. It is most of the complexity in the protocol.
Under source-specific multicast the receiver already names the source, so the tree is built directly to it and unnamed senders are discarded.
If you are designing anything with multicast today, use source-specific. Any-source is the model that made inter-domain multicast intractable, and both the routing complexity and the injection problem disappear the moment the receiver names the sender.
What Won Instead
Every approach here replicates in software, at a place that somebody owns and can bill for.
That is the deployability lesson, and it generalises well beyond networking: a protocol that asks independent parties to cooperate for somebody else's benefit is very hard to ship.
The concept survived even though the protocol did not. Send once, deliver to interested parties, is exactly what a message broker's topic is, what a WebRTC forwarding unit does, and what a edge does for a live stream. All of it in software, none of it in routers.
But it is very much alive inside walls
IPv6 Made It Compulsory
The previous lesson covered IPv6 removing broadcast entirely. The other half of that decision is that multicast stopped being optional.
There is no broadcast address to fall back on, so the basics of joining a network run on groups.
The solicited-node group is the clever one. Because it is derived from the target's own address, an address lookup disturbs roughly one machine instead of all of them.
That is a design pattern worth taking away. Broadcast asks everybody a question meant for one machine. Deriving a narrow group from the question itself gets the same reach at almost none of the cost, and it needed no new mechanism because multicast already existed.
When to Reach for It
Ownership of the path is the gate, and everything else is detail.
If loss is unacceptable you need a repair mechanism, and that is real engineering rather than a configuration flag.
In an interview, the second box is the answer worth giving. "Multicast, if this is all inside our own network, otherwise a or a fan-out service" shows that you know why the technically better option is usually unavailable, which is a more useful thing to know than the protocol itself.
One last piece of pedantry that is worth being pedantic about. People say "we multicast the events to all the consumers" when they mean a broker delivers a topic to several subscribers. That is application-level fan-out over unicast connections. It is a fine design and it is not multicast, and confusing the two leads to expecting properties you are not going to get.
Quick Check
Knowledge Check
6 questions - Score 80% to pass
A server streams live video to 5,000 viewers on a corporate network. Which uses the least server bandwidth?
Your multicast video stream is working, but the network team reports that it is reaching every port on one particular switch, including machines that never joined. What is the most likely cause?
Why do 32 different multicast group addresses arrive at a network card as the same hardware address?
Why is multicast essentially absent from the public internet?
You are designing a market data feed inside a data centre you own. Which model should you choose and why?
A colleague says 'Kafka multicasts events to all the consumers in the group.' What is wrong with that sentence?
