3 ms·
I think other (more modern?) systems solve that by requesting the first few seconds after a channel switch via unicast in parallel to the join request, to cover
by iforgotpassword 9y ago
I think other (more modern?) systems solve that by requesting the first few seconds after a channel switch via unicast in parallel to the join request, to cover up the time until the join is completed. I discovered this when I swapped my ISP router for a Linux box and didn't forward igmp. When turning on the TV I saw a frozen image. After switching the channel I got about 4 seconds of TV and then freeze again. Some wiresharking hinted me at the igmp and multicast I forgot to properly handle, and after setting it all up I saw a couple of seconds of unicast UDP data after every channel switch.
- myrandomcomment 9y agoThe time to start the single stream would be not much faster or at all to the mcast join. Most channels are broadcast to the local head node (main router in an service area). The join just builds the tree down past the head to the end user. Last time I looked at / worked on / designed these systems was maybe 8 years ago, but I do not except it to have changed to much. But you never know. I think the most interesting thing was this use case was what mcast was really designed for and the only real world use case I have seen beyond stuff in the finance market (market data feeds from the exchanges are multicast). Well there is OSPF...
- iforgotpassword 9y agoYes, these setups are really just a big mystery regarding the inner workings if you don't happen to work in that field. The unicast stream really started almost instantaneously when switching channels (sub second), so they somehow got this optimized well, but multicast always took 2 to 3 seconds...