skip to content

How does UDP deliver one datagram to many receivers with IP multicast, and why can't TCP do the same?

level: middleimportance: nice to knowfreq 18%

answer

  1. one send, a group address
  2. receivers join; sender unaware
  3. TCP connection is a socket pair
  4. no ICMP errors for multicast
  5. Any-Source versus Source-Specific

basics

~20 s

A UDP sender addresses a datagram to a multicast group address, and the network copies it to every host that has joined the group. TCP cannot, because a connection is state between exactly two endpoints, and RFC 9293 requires rejecting multicast addresses.

solid answer

~50 s

In IP multicast, a **group address** — an IPv4 Class D address, or an IPv6 multicast address — stands for a set of hosts. Receivers join the group, on IPv4 using IGMP to tell local routers, and the network replicates each datagram toward every member. The sender sends once and does not know who, or how many, receive it. UDP fits because it keeps no per-peer state and needs no replies. TCP cannot: RFC 9293 defines a connection by a pair of sockets, says an implementation MUST reject an OPEN to a multicast address, and MUST silently discard a `SYN` sent to one. The cost is that every gap in the datagram model multiplies: some receivers lose what others get, no ICMP error comes back for a multicast destination, and RFC 8085 §4 says multicast applications SHOULD still provide congestion control.

go deeper

for a junior

Recall that multicast sends one UDP datagram to a group address, and the network delivers copies to every host that joined.

for a middle

Explain group membership, why TCP's two-endpoint connection rules multicast out, and that no ICMP errors come back for multicast destinations.

for a senior

Show the production consequences: per-receiver loss, repair by negative acknowledgements or redundancy, datagrams sized under the MTU, and congestion control that works for a mixed group.

for a principal

Weigh network multicast, which needs infrastructure support and trust in who may join, against unicast fan-out through relays that is simpler to operate and costs more bandwidth.

## Three ways to address a datagram | Delivery | Destination | Who receives | Reach | |---|---|---|---| | **Unicast** | one host's address | that host | anywhere routable | | **Broadcast** | a broadcast address | every host on the subnet | normally constrained by routers to the local subnet (RFC 8085 §4) | | **Multicast** | a group address | every host that joined the group | as far as multicast routing and scope allow | Multicast is one-to-many *by subscription*: only interested hosts receive, and the sender does not need to know them. RFC 1122 §4.1.1 lists multicast and broadcast among the services applications get from UDP that are "not available from TCP". ## How a datagram reaches a group 1. **The group address.** On IPv4, RFC 1122 §3.2.1.3 describes a multicast (Class D) address as "a 28-bit logical address that stands for a group of hosts" — with the leading 1110 bits, that is the 224.0.0.0/4 range. Permanent group addresses are assigned by IANA; transient ones are allocated dynamically. IPv6 has its own multicast address format with a scope field (RFC 8200 notes the added scope). 2. **Receivers join.** A host that wants the traffic joins the group. On IPv4, IGMP tells the routers on its network which groups have members; RFC 1122 §3.2.3 describes IGMP working with a multicast routing protocol to extend delivery across networks. Without it, a host can still take part in multicast on its own link. 3. **The sender sends once.** It addresses one UDP datagram to the group address and a port. 4. **The network replicates.** Routers forward a copy along each branch that leads to members, so a link generally carries one copy however many receivers sit behind it. 5. **Each member delivers locally.** Every receiving host's UDP layer passes the datagram to the sockets that joined the group and bound the port. RFC 8085 §4 names two service models: **Any-Source Multicast** (ASM), where members receive data sent to the group by any source, and **Source-Specific Multicast** (SSM), where the distribution tree is constrained to a single source. ## Why TCP cannot do this - **A TCP connection is two-party state.** RFC 9293 defines a connection by a pair of sockets; sequence numbers, windows and the state machine describe one sender and one receiver. - **The handshake needs exactly one responder.** If a group of hosts answered one `SYN`, the sender would face many conflicting initial sequence numbers. - **Acknowledgements would multiply.** A sender getting an ACK from every member would drown in feedback, and its window could only move as fast as the slowest receiver. - **The specification forbids it.** RFC 9293 says a TCP implementation MUST reject a local OPEN for a broadcast or multicast remote address, and MUST silently discard an incoming `SYN` addressed to a broadcast or multicast address. UDP has none of these problems because it keeps no per-peer state and expects no replies. ## The datagram model, multiplied Every property of UDP's datagram model still holds, now across many receivers at once: - **Loss differs per receiver.** One member can get a datagram another lost; the sender does not know which receivers exist, let alone which missed what. - **No error feedback.** RFC 1122 §3.2.2 says an ICMP error MUST NOT be sent in response to a datagram destined to a multicast or broadcast address — so not even a Port Unreachable comes back. - **Congestion control is harder, and still expected.** RFC 8085 §4.1 says applications using multicast SHOULD provide congestion control, and describes two styles: *feedback-based*, where receivers report back, and *receiver-driven*, where data is spread over several groups and each receiver joins or leaves groups to match its own capacity. - **Message size.** RFC 8085 §4.2: a multicast application SHOULD NOT send datagrams whose IP packets exceed the effective MTU toward its receivers. - **Anyone may join.** RFC 8085 notes that any multicast-enabled receiver may attempt to join any group, and a transport cannot stop a join propagating to the next-hop router. ## Where it is used Multicast is common where the network is controlled and receivers are many: service discovery on a local link — multicast DNS (RFC 6762) sends its queries to a link-local group — and one-to-many feeds such as media or data distribution inside a single network. Across the public Internet, native multicast is rarely available, which is why most large-scale one-to-many delivery is built from unicast fan-out instead.

  • If some members of a multicast group lose a UDP datagram, can the sender simply retransmit it to them?
    Not with UDP alone: the sender does not even know who the members are. Reliability must be designed in — receivers that notice a gap can send negative acknowledgements, or the sender can add redundancy so receivers repair losses themselves. RFC 8085 §4 points to the IETF's reliable multicast framework and building blocks, such as NORM, rather than ad hoc schemes.
  • What is the difference between Any-Source Multicast and Source-Specific Multicast?
    In Any-Source Multicast (ASM), a group member receives everything sent to the group by any source. In Source-Specific Multicast (SSM), the receiver asks for traffic from one source to one group, so the distribution tree carries only that source's data. RFC 8085 §4 describes both; SSM narrows who can put traffic in front of a receiver.

saying these in an interview costs you the question

  • Multicast means the sender loops over its receivers and sends each one a copy.
  • TCP supports multicast once both sides enable the right socket option.
  • The multicast sender learns which receivers got each datagram.
  • A receiver must be registered with the sender before it can join a group.
  • Multicast and broadcast are the same: every host on the network receives it.