Inertia's picture

UDP Multicast?

Does anyone know some reliable links how Multicast works? What I'm looking for are answers to:

  1. Is there some kind of service your application can contact to get an unused ip:port for multicast?
  2. Is it legit to simply chose a ip:port on your own, even if it's used by other applications? (could discard packets that are not sent by mine)
  3. How to figure out whether the routers between all potential clients support multicast?
  4. Is there some (rather compatible) alternative to multicasting? My primary interest in it is to avoid the (unicast) server sending out the very same packet multiple times, just to different endpoints.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

I haven't kept the links, but I've managed to find a couple of nice tutorials on google. In my experience, consumer routers tend to drop multicast packets, which limits their usefulness. It is possible to use multicast over the web (I've read of some audio streaming service that did it), but I don't know what infrastructure is necessary for this to work.

Kamujin's picture

We use UDP multicast for market data extensively in my business.

1) If there is I am unaware of it. Multicast ip:port pairs are normally published as part of an API spec. There are no directory services that I am aware of.

2) It is not appropriate to reuse an ip:port in use by another application unless all reading applications are aware of how to process the packets of all sending applications. Also, yes, this will increase the drop rate.

3) Multicast subscriptions come in the form of IGMP join messages, your routers will need to forward these upstream if you plan to multicast across subnets. There are protocols such as PIM (and others) that support this. Commercial grade routers will support these protocols.

4) There are experimental version of multicast that try to address the reliable delivery issue, but router support becomes increasingly spotty. There is UDP broadcasting, but that's not a particularly good substitute. There are no TCP based 1 to many systems to my knowledge. TCP's only supports 1 to 1 sessions as the receiver is required to verify receipt of the data.

Please also be aware that UDP Multicast packets are not guaranteed to be correctly ordered or reliably delivered. In any non-trivial application you will observe dropped and misordered packets.

Inertia's picture

Searching the web did occur to me, but the only article worth reading dates 1.10.1997 and I was kinda hoping the issues had been resolved since then. Everything else I found did not get me any further than what I had already read on MSDN about UdpClient's join/leave multicast methods.

So - if I get it right - the problem is that my ISP's routers are not forwarding the packets, that would explain why it works on my own PC (multicast loopback in effect) but not through the internet connection.

Maybe you have some other ideas how to accomplish the same goal, I'm currently working on a simple text and voice chat conference application. Transmitting the uncompressed voice recording to the server (30kb/s) is not a problem for the client itself, but the server must duplicate incoming packets and send those to all peers in the conference except itself and the sender. So a conference with 4 members will require more upload bandwidth than what is currently available to consumers.
Yes, there are codecs like speex, flac, etc. and I could probably heavily reduce bandwidth by examining the samples and detecting silence (usually 1 person will speak and the others listen), but I'm looking at the worst-case scenario (someone tells a joke and everyone laughs, or people sing a song together, etc.). It would be desireable to have a codec-free fallback aswell, in case the codec is unavailable for whatever reasons.
This is why I looked at multicast, because the way I understood it, it would allow every client to send their recorded samples directly to all peers (minimum latency) as opposed to having a server duplicate the packets. But it seems this is not what multicast is designed for, it's more useful for a single "provider" and many "consumers".
That packets might get lost is not a problem for voice chat (it's actually preferable to reliable delivery, 1/20th of a second is no more than a single letter in a spoken word), so multicast looked like the right solution.

objarni's picture

Searching the web did occur to me,

Haha I'm really starting to like your sarcastic style Inertia ;)

Inertia's picture

Well I meant no disrespect. Simply cannot get rid of the feeling that the technology I'm looking for is there but is occluded by my perception of how things are supposed to work.

objarni's picture

Well I meant no disrespect.

Me neither, I just like your "spock" style. BTW I guess you have tried reading the RFCs for these things..? The little RFC-skimming I've done has been a great source.

the Fiddler's picture

In that case, these might help:

I wonder how VOIP software implements conferences. SIP communicator is open-source and might be a good starting point. I've perused its source before (Java and not pretty, but quite usable) and there's a lot of interesting stuff in there.

Edit: your use case falls into the many-to-many multicast scenario from the first document, which means it is supported (actual implementation is another matter entirely).

Kamujin's picture


The way I see it, if I have 5 people on a conference call, I would blend all 5 conversations at the server and send a single compressed / mixed stream to each client using TCP. For the 5 man conference, I would think you would need to compute 5 distinct streams each containing the transmission of the other parties, but excluding the transmission of the client itself (otherwise, you'd echo).

This is really way out of my core competency, but I don't see this problem as copying the same data to 5 people. I see it as sending 5 different streams that are roughly 80% similar to 5 different clients.

Inertia's picture

Separate recordings allow placement of OpenAL sources for each user and thereby any enhancements through Efx Effects. With 3 users in the conference bandwidth is not a problem, but your idea scales best for "crowd traffic". Maybe the best course of action is to determine first how many people are actually speaking and only merge recordings if theres three or more talkers (possibly base that decision on server's upstream), otherwise just forward the packets.

What I'm basically trying to achieve is balance between Teamspeak and Skype, the one requires a dedicated server and has poor quality but can handle 20 users easily, the other has ok quality but assumes it is the only application using all available bandwidth. The idea is to keep packets below 1400 bytes payload, so even with IPv6 headers it stays smaller than an ethernet frame to rule out fragmentation. If a packet dies on the way (50ms worth of audio were lost) there is no point in resending it, the gap in the word is more acceptable than pauses in the playback. My first approach was using TCP aswell since it is reliable, but looking at multicast - and the kind of data being transported - it became clear that UDP is perfectly sufficient.

The finale stage of the application is to become command line driven (so it can be launched conveniently as a new process from a game for voice communication on a different CPU) but it also has a WinForms UI for standalone usage. However this is of limited use because it doesn't directly provide any means for clients to learn about server's addresses and either dynamic DNS services or a third party tool like ICQ/AIM must be used to communicate them. Multicast would have been very useful in that regard as users could simply announce themselves in a reserved multicastip:port group, but the way I see it that isn't going to happen unless all ISPs forward multicast packets.

Kamujin's picture

I guess it depends on what your goals are, but I would think that the client could communicate it's effects parameters to the server which could use them during the mixing. Realtime multi-track mixing is trivial on todays hardware, where as high speed broadband is not quite as ubiquitous as some might think.

If this is seriously going to be an internet app, you might want to consider TCP if for no other reason than it's usually a lot easier to deal with soho firewalls.