Multicast, Explained: Why Exchanges Send One Feed and the Network Copies It

First, the plain-English version

Picture a radio station. It puts one signal into the air, and anyone whose radio is tuned in hears it. The station does not phone every listener — and it neither knows nor cares whether ten people are listening or ten million. The cost never changes — only the audience does.

Now picture the opposite — a performer who phones each listener separately and plays the whole show down every line. Ten listeners, ten performances; ten thousand, ten thousand, all identical. That is how data normally crosses a network, and for carrying live prices to every firm that wants them, it breaks down.

The problem: sending the same thing over and over

The everyday way of moving data is unicast — one sender, one receiver, one private stream between them. Unicast is exactly right for a conversation — your laptop asking a server for a page. But when the same stream has to reach many receivers, unicast becomes the performer phoning every listener: the sender pushes a separate copy for each receiver out of its own connection.

So the sender's link carries the identical stream once per receiver, and every link near the sender carries those copies too. Each added receiver costs exactly as much extra as the one before. A live price feed is the extreme case, because every subscriber needs the same update at the same moment.

What multicast actually does

Multicast changes who does the copying. The sender addresses its packets to a multicast group — a special IP address that stands for "everyone currently subscribed to this stream" instead of naming one machine — and sends each packet exactly once. The routers build a delivery tree — paths from the sender that branch outward to every router with a subscriber attached. A packet crosses each shared link once, however many receivers sit beyond it; only where the tree branches does a router make a copy, one per branch.

That shift moves the copying from the sender into the network — the same trick that carries IPTV, television channels delivered over an IP network: one channel, a huge audience, no reason to send the same picture thousands of times.

How receivers join: IGMP, then PIM

A receiver has to ask to join, in two stages. On the local link, the receiver's machine speaks IGMP — the Internet Group Management Protocol — to say "deliver group G to me". IGMPv3 (RFC 3376) goes further than earlier versions: the receiver can name the exact source it wants, not just the group.

From there, PIM — Protocol Independent Multicast — builds the tree router by router, growing it only where someone is listening. It is "protocol independent" because PIM runs no routing system of its own; it borrows the unicast routing table to locate the source. That borrowing brings a safety check: the RPF check (Reverse Path Forwarding) lets a router accept traffic for a source only if it arrives on the interface unicast routing points to for that source. Anything arriving another way is dropped — how loops and stray copies stay out of the tree.

Two ways to build the tree

The widely used flavour of PIM is PIM-SM — Sparse Mode, specified in RFC 7761. A receiver joining a group may not know where the sources are, so PIM-SM begins with a shared tree (also called the RPT, for rendezvous point tree): all of a group's traffic first flows to one meeting place, the rendezvous point (RP) — a router chosen as the group's hub — and from there down the shared tree. The state routers keep is written (*,G): the star means "any source", G is the group.

Once traffic flows, the router nearest a receiver can see where packets come from, and PIM-SM switches to the better shape: a source tree (the SPT, or shortest path tree), built straight from that source along the shortest path to the receivers. Its state is written (S,G) — this specific source S, this group G. The shared tree solves discovery; the source tree removes the detour.

The RP's placement is the tradeoff. On the shared tree, every packet visits the RP first — so place the RP far from the source and most receivers, and packets detour to the meeting point and back. A badly placed RP breaks nothing; it adds distance until switchover, or permanently for traffic that stays shared.

SSM: skip the meeting point entirely

SSM — Source-Specific Multicast, specified in RFC 4607 — asks: what if the receiver already knows the one source it wants? Then nothing needs discovering, no meeting point is needed, and no RP is involved at all. The receiver uses IGMPv3 to ask for one specific (S,G) pair, PIM builds a source tree straight from that source, and routers keep only (S,G) state. The address gives the design away: groups in 232.0.0.0/8 are SSM by definition, reserved for exactly this model. A neighbouring range matters too: 239.0.0.0/8 is administratively scoped — private use inside an organisation, not the public internet.

This is why market-data feeds fit SSM. A feed has one known publisher — the exchange's feed source, whose address subscribers are given in advance — and many subscribers who want that same source and no other. The feeds run over UDP, the connectionless transport with no built-in retransmission, deliberately: a lost price is stale by the time a re-send could arrive, so asking again is worthless. Instead, packets carry sequence numbers, and receivers watch them to spot gaps.

ASM or SSM? The decision in plain words

The older RP-based model is called ASM — Any-Source Multicast: receivers join a group without naming a source, anyone may send to it, and the RP connects senders and receivers who never knew of each other. The choice comes down to one question: do the receivers know the source before they join? If yes, and there is one source or only a few, choose SSM — no RP to place, protect, or make redundant. If sources are many, unknown, or changing, that is what ASM with an RP was built for.

Five mistakes that break real multicast

1. PIM enabled on only some interfaces in the path. The tree stops at the first hop where PIM is missing: everything upstream looks healthy, everything downstream is silent.

2. RPF failing because the unicast and multicast paths differ. The check assumes packets arrive from the direction unicast routing points to. Where the two differ — asymmetric paths are common — good feed packets arrive on the "wrong" interface and get dropped by the check itself.

3. An ASM design with no RP redundancy. If the one RP router fails with no backup, new joins on the shared tree have nowhere to meet the source — a designed-in single point of failure.

4. Using a 232/8 group while expecting an RP to be involved. Addresses in 232.0.0.0/8 are SSM by definition; there is no RP in that design, ever. Troubleshooting that goes looking for RP state on a 232 group is searching for something the addressing ruled out.

5. No boundary or filter for private 239/8 groups. The 239.0.0.0/8 range is meant to stay inside your own network. Without a boundary filter at the edge, private groups leak out or outside groups leak in.