Sign in to follow this  

Multicast... not available widely enough?

This topic is 3862 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Okay, I figure if anyone knows you guys will. I've been thinking about using Multicast UDP in a game... (Not Broadcasting where you send to 255.255.255.255 or what-not, but Multicast where you subscribe to an address in the 224.X.X.X range and the router/bridge is supposed to send the single packets you send out to all the other subscribers to that IP address) The thing is, my little tech demos I've tried have failed both at my house and at my work. Apparently neither support Multicast, which got me wondering... Is Multicast mostly unsupported in home-quality routers, or did I just find a bad sample? Do any of you own a router that supports Multicast and costed you less than $300 USD? I figured the standard was over 10 years old so it should be safe, but thus far in practice it's proven not to be... and my searches on the 'net for info on how widely it's available has turned up nothing (most routers don't mention if they support it or not). Thanks for any info you can provide!

Share this post


Link to post
Share on other sites
IPv4 multicast is a broken design, and will never work on the larger scale Internet.

Consider this: I and you form a multicast group; our routers talk to each other to make this happen. Now, our friend Sai in Japan wants to join our multicast group. His router needs to know about our group and our routers. By extension, every router on the Internet needs to know about every multicast group. Oops!

Share this post


Link to post
Share on other sites
Aye, and I totally agree with you on that... but I was picturing it more for intranet use. Basically for a party/LAN game on a large scale... I suppose theoretically up to the limit of # of people who can fit on a single subnet.

It would've been ideal bandwidth-wise in that scenario, and it could've been all served by a single router that didn't need to propagate the IGMP packet beyond the subnet... but it seems at least in the ones I've run across that it just hasn't been implemented: perhaps for the very reasons you gave (that it wouldn't work on an internet level). Alas. =(

Share this post


Link to post
Share on other sites
There are large enterprise installations that use multicast for simulation -- the DoD comes to mind. This always happens on closed subnets, and they need high-quality routers (i e, your $1,500+ Cisco, not your $150 Netgear) to make it work.

However, if you're on a single subnet, I would recommend just using UDP broadcast, rather than multicast. Broadcast is widely supported, and easy to work with, and on a single subnet, there is no bandwidth difference.

Share this post


Link to post
Share on other sites
Aye, true. Okay, here's the kicker though... and perhaps I'm just not thinking about a more elegant solution to the problem, but here it is. =)

I need multiple processes on the same system to be able to recieve the packets sent out for this program. That was why I originally turned to Multicast: from what I was reading, it sounded like Broadcast would still only be recieved by one process on a target system (if multiple processes were listening to the same port). From what I gathered from my investigation of Multicast, it sounded to me like all of the processes listening to the same port would recieve the packet, and thus they would all have the opportunity to update their information/respond as a result.

My workaround at the moment is to have a program running on a computer that acts as the server. Whenever a process opens on another computer, it gives that computer a new port number to listen to and records that port as being reserved on that system, and then whenever one of those processes sends a message to the central server it sends the message to each process by sending a message to each IP/Port combination it has recorded as active.

It doesn't feel clean though... that is, it feels cumbersome and inefficient. Is there a more graceful way to support this kind of setup without relying on Multicast that you may know of? I'm stumped on it at the moment, and thus resorted to this solution (that feels more like a hack to me). =(

Share this post


Link to post
Share on other sites
Have you tried it? I would expect each process to get a copy of the broadcast message if they all open a socket bound to the same port. Else things like mDNS (Rendez-Vous/DAAP/iTunes etc) wouldn't actually work.

Share this post


Link to post
Share on other sites
Hmm, I guess I should actually try it before I can say with 100% certainty that it won't work. Admittedly, when I first started looking all this up, I saw in a forum somewhere that in the scenario stated above the process which recieved the broadcast packet was random. I took the guy at his word, but indeed I ought to actually try it before I rule it out (especially since it shouldn't take too long to modify what I have to give it a shot).

Hmm... I'll see if I can make some modifications this weekend and actually try it with broadcast. I'll post on the results when I get time to work on it! =)

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603
Have you tried it? I would expect each process to get a copy of the broadcast message if they all open a socket bound to the same port. Else things like mDNS (Rendez-Vous/DAAP/iTunes etc) wouldn't actually work.


Though it has been ages since I really did some low-level networking I don't think this will work. In general you can not bind multiple listening sockets to the same port. But you could try. My knowledge on the subject is a bit vague so I could be wrong.

If opening multiple sockets on the same port doesn't work you could try some shared memory trickery to get the same packet to multiple processes.
Assuming you are developing for windows, you could have a publisher/subscriber mechanism in shared memory of a DLL, which would also contain the listening socket. Then when the listening socket in the DLL receives a packet it would call the events of the subscribed processes.
You would open up the socket when the DLL is loaded for the first time, and close the socket when the DLL is unloaded.
I do not know how the event mechanism would work across process boundaries and that might pose a technical challenge. Also this might result in a DLL-hell when you have multiple copies of the same DLL on your system.
I feel it is a tad more "elegant", though possibly less rubust when dealing with multiple DLLs, than keeping a seperate server on you system.

Share this post


Link to post
Share on other sites
Quote:
In general you can not bind multiple listening sockets to the same port.


I believe that is true for TCP, but not UDP. There is no reason why multiple UDP ports listening on the same port on the same machine wouldn't all get the same broadcast packet.

However, in this case it may be that non-broadcast packets only go to one, arbitrarily chosen, process.

Share this post


Link to post
Share on other sites
Sign in to follow this