27
Why is so much of IPv4 allocated to multicast when it cannot be used by the public at large ? (lemmy.ml)
submitted 1 year ago* by to c/asklemmy@lemmy.ml
31 comments fedilink hide all child comments
 

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 ?

you are viewing a single comment's thread
view the rest of the comments
[–] [S] -2 points 1 year ago (1 child)

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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 0 points 1 year ago (1 child)

    So when a video is created it is immediately sent to subscribers?

    In that case, for things to be sent once, it relies on the receivers always being online. That doesn't work if my laptop is closed at the time.

    That's why I'm thinking that it needs online caching to work. Or everyone has a cloud server that handles sending and receiving while they're not online.

    In fact, that starts to sound like everyone running their own personal lemmy-like instance, to which their friends subscribe.

    And in that case it wouldn't matter if messages were sent more than once, each person's server would handle it.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] [S] 1 point 1 year ago (1 child)

    The information could be live streamed from the camera or from a recording, that doesn't make a difference. It could also be ANY data, not just video.

    Also, yes, if you are not listening for the packets, then you will not receive them later. There is no servers between the sender and receiver, this means no gatekeeper, no middleman, it's a democratization of broadcast without intermediaries.

    The only reason it is more efficient is because of how direct it is.

    Before the internet we had TVs which, if they were not turned on, could not store and receive any of the video stream being broadcast, it's a lot like that. You didn't ask the TV station to send you a video file, they sent it out regardless and you listened to it or you didn't.

    The problem with caching or storing anything, is now you're back to need one connection per receiver, you're no longer sending out a single copy, you have to send 500 hundred copies if 500 people want it, that takes far too much resources.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 1 year ago (1 child)

    Realistically that single sent packet is going to get copied multiple times in order to re-route it just to the subscribers. We're not all one one big LAN.

    What mechanism causes a single sent packet to get to all the subscribers (and only them)?

    Assuming that we all have a static IP for simplicity, a sent packet needs to be routed to the subscriber IPs (via their ISPs). Where is that table stored? Is it sent with each packet so that it can be routed on the way? That would be a huge bloat of the packet size.

    BTW, I do remember life before VCRs. Pre internet, I downloaded QWK packets from BBSs.

    I get the appeal of removing communication from the hands of FB etc, but I don't see how switching to a broadcast system that increases unreliably would help. And I don't see how the broadcast would work on the Internet that we have.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] [S] 0 points 1 year ago* (1 child)

    Multicast group where the listener subscribes dynamically to sender. When a packet in the multicast IP range arrives in the router, they get routed depending on the subscription list. So instead of a packet being sent down one link, it might get sent down both of them, the routing rules are the same as unicast except in the destination of all hosts in the subscription list, which is only read for packets of the specific multicast destination address of the packet so not all rules (there would be a lot of them, megabytes of rules, too much for 80s computers, but trivial to route under 2 microsecond with our hardware)

    I don't know the exact mechanism or if that's how it works, but it's how it SHOULD work and I think that's how IGMP actually works

    I don't think the hurdle is technical, it is political, stopping all these monopolistic ISPs in between the people from trying to extract a toll for every passing packets, which of course just kills the entire concept. If it's not dynamic, fully automatic and "as free as" unicast packets then it quickly become not worth doing at small scale.

    I think only government action can ram this in.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •