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!

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!

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. =(

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.

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). =(

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.

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! =)

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.