multicastjgroups

JGroups : explain mcast_addr for dummies

Using the following command to listen in for MCast messages.

java -cp $CLASSPATH:./jgroups-all.jar org.jgroups.tests.McastReceiverTest -mcast_addr 228.1.1.1 -port 55555

Based on this image, the 228.1.1.1 should be a valid IP for multicasting.

enter image description here

Now the questions...

1 - In layman's terms, what exactly is this mcast_addr? Is the mcast_addr essentially a virtual name (set up as an IP address format) for the group machines that send messages to/from each other? So, instead of mcast_addr being something like "MyConferenceRoom1" I call it "228.1.1.1"?

2 - If 3 machines used the same mcast_addr, they can all use different -port options?

3 - A bit of an exaggeration, but if I were to write a program that iterated through all the mcast_addr 288.x.x.x, could I essentially be eavesdropping on someone else's messages?

Solution
    1. 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.

    1. 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.

    2. 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.