3

I develop client-server application, working in real-time. Server and clients exchanges by small messages, so I choose UDP for my architecture (as suggested in many articles in network). It's not a problem for me to use default java's DatagramSocket/DatagramPacket for orginizng all things as I want, but when I read documentation I see the "MulticastSocket" opportunity. But it is completely unclear for me: How MutlicastSocket at the user side will know where to connect? (public IP/port of the server). Really, as this shown at this official java tutorial. MulticastSocket creates like:

MulticastSocket socket = new MulticastSocket(4446);
InetAddress group = InetAddress.getByName("203.0.113.0");
socket.joinGroup(group);

and there is NO any specification about public server IP and port. What is "203.0.113.0"? It is possibles that tones of applications send something to that address in web, isn't it?

When I create client in regular (not Multicast) way I use something like:

DatagramSocket outputClientSocket = new DatagramSocket();
DatagramPacket outputPacket = new DatagramPacket(new byte[512],512,InetAddress.getByName("94.***.89.***"),9898);
...

where "94.???.89.???" is my server's public IP address, and 9898 is port of my server, that listens it. Like that:

DatagramSocket serverInputSocket = new DatagramSocket(9898);
DatagramPacket inputServerPacket = new DatagramPacket(new byte[512],512);
serverInputSocket.recieve(inputServerPacket);

and after recieving something I can establish connection with client, and answer something for him, like that:

DatagramSocket socketForSpecificClient = new DatagramSocket();
InetAddress realClientAddress = inputServerPacket.getAddress();
int realClientPort = inputServerPacket.getPort();
DatagramPacket packetForSpecificClient = new DatagramPacket(new byte[512],512,realClientAddress,realClientPort);
socketForSpecificClient.send(packetForSpecificClient);

This approach works well, even if client has no public IP. It is absolutely clear way of establishing connection for me, but I can't understand for what purposes MulticastSocket should be used?

Am_I_Helpful
  • 18,735
  • 7
  • 49
  • 73
Crabonog
  • 423
  • 3
  • 12

2 Answers2

1

Multicast is in IPv4 usually not working across network segments. If your application is supposed to work on the internet (and not e.g. just within an intranet under your control), you can not base your communcation on multicast.

Edit: Here are some further resources on the subject:

Wikipedia on IP multicast:

multicast services are generally not available to the average end-user

Other Stackoverflow question 'UDP Multicast over the internet?':

In general this is not possible since multicast packages aren't routed.

Discussion on hardforum.com 'Does multicast work over the itnernet(sic)?':

ISPs filter mutlicast you can't join a multicast stream over the internet.

These are just a few of the first hits when googling for 'using multicast over the internet'.

The address range 203.0.113.0/24 is reserved for use in 'documentation and example code' so the address in the example, 203.0.113.0, does not point to a real endpoint.

If you need a real, public multicast address and are connected through an ISP with multicast support, you have to obtain one from the IANA registry. You are right that anyone can send (potentially bogus) data to that IP address, but you have exactly the same problem with unicast addresses. If you provide a service on a unicast address, anyone can connect to that address and send data to it.

Community
  • 1
  • 1
jarnbjo
  • 33,923
  • 7
  • 70
  • 94
  • @Am_I_Helpful I can't prevent you from claiming the statement to be 'totally misleading', but it is not. In general, 'normal' internet service providers are *not* routing multicast packets. I've added a few links to my answer in case you are interested in reading up on the subject. – jarnbjo Mar 24 '16 at 18:01
  • I liked your answer, with so many resources, but, I'd just say at the end, that it has restrictions, but, still possible(depends on ISP's). Ok, I'm removing my downvote, which doesn't stand apt NOW, after such a long discussion. – Am_I_Helpful Mar 24 '16 at 18:26
-1

Quoting the paragraphs from the book Java Network Programming for framing the answer :

How MutlicastSocket at the user side will know where to connect? (public IP/port of the server)?

What is "203.0.113.0"? It is possibles that tones of applications send something to that address in web, isn't it?

Firstly, you should generally use IP-Address lying between 225.0.0.0 to 238.255.255.255 for creating a new multicast group.

When a host wants to send data to a multicast group, it puts that data in multicast datagrams, which are nothing more than UDP datagrams addressed to a multicast group. Multicast data is sent via UDP.

A multicast address is the shared address of a group of hosts called a multicast group. IPv4 multicast addresses are IP addresses in the CIDR group 224.0.0.0/4 (i.e., they range from 224.0.0.0 to 239.255.255.255).

A multicast group is a set of Internet hosts that share a multicast address. Any data sent to the multicast address is relayed to all the members of the group. Membership in a multicast group is open; hosts can enter or leave the group at any time. Groups can be either permanent or transient. The IANA is responsible for handing out permanent multicast addresses as needed.


Multicasting sends data from one host to many different hosts, but not to everyone; the data only goes to clients that have expressed an interest by joining a particular multicast group. In a way, this is like a public meeting. People can come and go as they please, leaving when the discussion no longer interests them. Before they arrive and after they have left, they don’t need to process the information at all: it just doesn’t reach them. On the Internet, such “public meetings” are best implemented using a multicast socket that sends a copy of the data to a location (or a group of locations) close to the parties that have declared an interest in the data.

In the best case, the data is duplicated only when it reaches the local network serving the interested clients: the data crosses the Internet only once. More realistically, several identical copies of the data traverse the Internet; but, by carefully choosing the points at which the streams are duplicated, the load on the network is minimized. The good news is that programmers and network administrators aren’t responsible for choosing the points where the data is duplicated or even for sending multiple copies; the Internet’s routers handle all that.


To receive data that is being multicast from a remote site, first create a MulticastSocket with the MulticastSocket() constructor. As with other kinds of sockets, you need to know the port to listen on. This code fragment opens a MulticastSocket that listens on port 2300:

MulticastSocket ms = new MulticastSocket(2300);

Next, join a multicast group using the MulticastSocket ’s joinGroup() method:

InetAddress group = InetAddress.getByName("225.2.2.2");
ms.joinGroup(group);

This signals the routers in the path between you and the server to start sending data your way and tells the local host that it should pass you IP packets addressed to the multicast group. Once you’ve joined the multicast group, you receive UDP data just as you would with a DatagramSocket .

It is possibles that tones of applications send something to that address in web, isn't it?

One would face the same problem even in case of unicast communication if the address is known on which the service is provided.

Community
  • 1
  • 1
Am_I_Helpful
  • 18,735
  • 7
  • 49
  • 73
  • 1
    Any reference for *"Multicast data is sent via UDP, which, though unreliable, can be as much as **three times faster** than data sent via connection-oriented TCP"*?. – SergeyA Mar 24 '16 at 13:50
  • @SergeyA - I've already quoted that, check the first line of the answer. The answer has been framed using the points mentioned in the book. Thanks for your concern though. – Am_I_Helpful Mar 24 '16 at 13:52
  • 1
    Oh, this is a quote from the same book, I see. Well, this is just BS, pure and simple. – SergeyA Mar 24 '16 at 13:52
  • 1
    @SergeyA - I don't know whether I qualify to say it as BS, but, it is not needed here. So, I am removing the point. Thanks again for your concern. – Am_I_Helpful Mar 24 '16 at 13:53
  • @Am_I_Helpful As I already pointed out in my answer, almost no ISPs are actually routing multicast packets, so even if the theory behind your answer might be correct, a practical implementation is not possible. – jarnbjo Mar 24 '16 at 16:00
  • @jarnbjo - Well, you may need to focus on that part of my answer which mentions about *permanent* and *transient* multicast groups! I don't know why it deserved a downvote just for this reason(which is incorrect in itself)! – Am_I_Helpful Mar 24 '16 at 17:24
  • 1
    @Am_I_Helpful I tried to ignore the section about permanent and transient multicast address since it does not make much sense in this context. Permanency and transiency is a property of IPv6 addresses, for which there is no direct counterpart in IPv4. – jarnbjo Mar 24 '16 at 17:36
  • @jarnbjo - That line(in my answer) has no direct relation to IPv6; `the biggest restriction on multicasting is the availability of special multicast routers (mrouters). Mrouters are reconfigured Internet routers or workstations that support the IP multicast extensions.` --- possible even with IPv4. – Am_I_Helpful Mar 24 '16 at 17:42
  • @jarnbjo - I, nowhere, explicitly talked about IPv6 and groups in the answer, it is just that `For your packets to reach any given host, there must be a path of multicast- capable routers between your host and the remote host. Alternatively, some sites may be connected by special multicast tunnel software that transmits multicast data over unicast UDP that all routers understand.` – Am_I_Helpful Mar 24 '16 at 17:44
  • @jarnbjo - Quoting the lines again from the same book. I am sorry, if it was not clear to you in the first reading. – Am_I_Helpful Mar 24 '16 at 17:45
  • If you're quoting, you should use quote formatting for the quotations. If you're paraphrasing, you shouldn't. – user207421 Mar 24 '16 at 20:56