Multicasting seems provide an efficient method of routing networking traffic from a source to multiple end users, especially at this moment in time with teleconferencing, streaming media, online collaboration tools in high use. Looking into it, it appears to be seldom used for such applications, why is this?
1
-
Comments are not for extended discussion; this conversation has been moved to chat.– Ron Maupin ♦Commented Jun 5, 2022 at 4:31
Add a comment
|
3 Answers
Because multicast is one source to many receivers, and thus two way communications (and anything using TCP connections) won't work. That makes it unfit to use for teleconferencing, online collaboration and many more applications.
Streaming media would work, but many people like to be able to pause the stream for example, and that wouldn't be possible with multicast.
To add to that, multicast is quite complex to implement, especially between networks. It is used however, but mostly only within networks. Many consumer networks I know use multicast to provide IPTV with a fallback to regular unicast if functions like time shifting are activated.
-
11Just to add: multicast has no security mechanism. Outside of a controlled network, it could easily be used for DoS attacks - amplifying a low-bandwidth data stream to an extreme total bandwidth that overloads links or even the whole network.– Zac67 ♦Commented Sep 3, 2020 at 10:18
-
9It also comes down to setting up and maintaining multicast isn't trivial. Many engineers have next to no experience with it. IPv6 aside, I've only seen multicast routing in the enterprise once - decades ago, it was for video conferencing, and yes, it was easily broken. (today, the most common scenario I read about is music-on-hold, and ntp.)– RickyCommented Sep 3, 2020 at 14:33
-
3pausing a stream can still work if you use large buffers on the client side (maybe disk, or just RAM). Or if you just multicast to people watching live (or with a small buffer behind), with other users falling back to personal unicast if they fall farther behind than they're willing to buffer. If most users are watching live, that can still save a lot of core network bandwidth for some widely-watched streams during their initial broadcast. (Although the biggest streams probably mirror to distributed CDN endpoints, reducing backbone traffic anyway.) All this if multicast were supported... Commented Sep 4, 2020 at 10:10
-
I don't know if it is unreliable or I'm just incompetent, but I was once using multicast for service discovery and I had constant issues with Windows listening only on a wrong network device and/or other problems that somehow killed the multicast subscription.– AndreKRCommented Sep 4, 2020 at 10:42
-
1@Barmar Think about services like Twitch and YouTubeTV/Sling/etc, though.– DaiCommented Sep 6, 2020 at 3:42
Multicast is one of those ideas that sounds nice in principle but doesn't really scale to a network like the internet. It requires routers to keep track of a bunch of extra state, has significant potential for denial of service attacks and also has significant problems from a billing perspective. The result of this is that ISPs generally said no to multicast.
Multicast can be a useful tool within networks you control. It gets used for reimaging PCs in enterprise/academic scenarios and for distributing TV services by IP based "triple play" providers but it's of no use if you want to make a service that operates on the open internet because the providers don't support it.
answered Sep 3, 2020 at 17:16
-
8It was designed in the before times, in the long-long ago, when nobody needed to care about security, because the internet consisted of few people, and they all behaved. That is definitely not true today!– RickyCommented Sep 3, 2020 at 19:33
Multicast was once a popular choice for applications which had the following characteristics: a sequence of events with a similar structure but different values, each new value replacing all earlier values. There are no resources to buffer, or even notify the publisher if an event if was lost, you would just wait for the next event.
Data recorders for physical events and stock market tickers work on this principle. In financial markets most multicast systems now include a parallel request-response system for recovery of lost events.
