I found the multicast registery here.
https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml
I already knew that addresses between 224.0.0.1 and 239.255.255.255 are reserved by multicast.
Obviously multicast could be immensely useful if used by the general public, it would obsolete much of facebook, youtube, nearly all CDNs (content delivery networks), would kill cloudflare and company’s business model and just re-arrange the internet with far reaching social implication.
So, why hasn’t all these multicast addresses been converted in usable private IPv4 unicast address space ?
I don’t see how that would work. So all my friends video streams, for instance, would be streaming data to all my devices as they are broadcast.
But my laptop is currently asleep. It wouldn’t receive anything.
How do you solve that without storing the video on a server that I can pull from on demand?
Even for my devices that are on, they’d have to store everything as it was broadcast.
And the streams (including every other broadcast) would constantly be eating up my bandwidth.
How would I not receive streams that I’m not interested in? What would decide which broadcast packets do or don’t get sent to my router?
You subscribe to multicast groups, when the cast happens, you have something to receive it, or you don’t that’s up to you.
In the old days we have these glass tubes, you turn them on and the streams appears on the front, when they’re off you can’t see the stream.
We had little black box underneath the tube, and if you push the right incantation of button, it would store the stream and you’d watch it later.
I know that might sound a little far fetched, a little magical, but the black square in your pocket that receives emails, it can receives those casts as well.
Depending on how much spam the manufacturer has injected in it, it can probably store around a couple hundred hours of videos, and a couple hundred million tweets or “short text messages” as they used to be called
From the research I’ve done since posting that, it has become evident that all the little internet fiefdoms that make up the net, each want a slice of the pie, and CDN networks, a parrallel pseudo network to the internet, is the bridge where they get to collect that toll.
If multicast worked as designed, this toll would be in danger, because anyone could just use it instead of the CDN or using unicast and local caches.
No the streams wouldn’t be “constantly offering your bandwidth” that’s a “broadcast” a broadcast you do always receive it, but a multicast you need to enter the multicast group or else you don’t receive it.
That’s the same as above, you just don’t subscribe or you unsubscribe to the multicast group.
There would be multicast groups just for knowing what streams you could join if you wanted to.
Your street would have a multicast of just your neighbours and just for text.
This might feel foreign to you, but that’s because the software to browser is as non-existent and the capability of multicast on the internet itself.
Nobody is going to make these browsers and pseudo internet VHS, when we all know that ISPs will never allow multicast through unless forced to by the statists, finally a legitimate use of force besides building roads and powerlines !
multicast subscription to multicast groups, a trivial affair, it was trivial in 1980s, it is still trivial now, the ISPs will tell you this is a complex scaling impossibility, they are lying
I see I misunderstood how you mean this to work, that routing would handle sending data only to subscribers. I was imagining that it mean a simple LAN broadcast using a packet with the subnet bits all set (e.g. 192.168.255.255). I think that it’s more analogous to a mailing list distribution, but for general data/streams?
But your earlier example of downloading the cat video still fails unless many people request the video at the same time (otherwise you’re multicasting to one). What happens if I watch the video on my phone while out, then watch it again on my laptop at home? It will still need sending twice.
Wouldn’t a more efficient approach just be to have something like ipfs with lots of local caching?
It’s not “video-on-demand”, you don’t subscribe to a file but to an address, the multicaster sends the file or stream or message when they’re ready, you receive them if you’re listening, everyone subscribed gets the same series of packets. It’s the only benefit that multicast really has over unicast, the sender just sends the packet once. There’s no server, no caching, no repeats. Direct from you to them and it can work for everything.