- In layman's terms,
mcast_addr is like a radio frequency with the exception of that you need to join it before you can listen in (not true within a net without a router hop). Most often, a port is also used but you can view this as part of the frequency.
So, instead of mcast_addr being something like "MyConferenceRoom1" I
call it "228.1.1.1"?
Yes, exactly.
Yes, but for super-high volumes, filtering of unwanted messages will then happen higher up the IP stack which can degrade the performance. You usually want to separate classes of traffic on the multicast group for reasons explained below.
Yes, there is no permissioning built-in to this at the IP level. You might run into routers not playing along, this is one of the reasons you need to join a multicast group before listening:
+--------+ +--------+ +----------+
| Sender | -> | Router | -> | Listener |
+--------+ +--------+ +----------+
As a listener, when you join a multicast group, a message gets sent to the router that, depending on its configuration, will start routing messages to the listener.
Now, imaging having a network of subnets where there might be 2 routers between the sender and listener:
+--------+ +----------+ +------------+
| Sender | -> | Router A | -> | Listener 1 |
+--------+ +----------+ +------------+
|
V
+----------+ +------------+
| Router B | -> | Listener 2 |
+----------+ +------------+
If Listener 1 joins 224.1.2.3 and Listener 2 joins 228.1.1.1 they won't see each other's traffic. This mechanism prevents flooding the network with multicast messages very few are interested in. Listener 2 could certainly try to join 224.1.2.3 but it's the router that decides if this should be allowed.
In an enterprise setting, routers are usually configured to block multicast traffic other than within a subnet because then routers are not typically involved.
As mentioned before, if you are separating classes of traffic on the port, the routers won't be able to perform their work as efficiently since they usually don't care about the port.
