Say you need to distribute a large file to many people and you want to do it on the Internet. Today you would put the file on a server and tell people to download it. Then the targets would go and try to download the file from your host server. If you have 500 kbps connection to the internet and you have 1000 (1k) people trying to download it at the same time, each person will be downloading at 500 bits per second.
Let’s say the file is a large one, like a feature length movie. The movie would play at 10 Mbps for 8000 (8k) seconds (2 hours 13 minutes). That’s a total of 80 Gbits, or 10 GBytes. A 10 GB file is fairly large. And that’s with 8 bit bytes. What if they decide to go to 16 bit bytes to provide better color definition? That file just doubled in bit size. But I digress; we are going to stay with 8 bit bytes.
At 500 Kbps, it would take 45 hours to send the file. Just to one person. It is left to the reader to determine how long it would take at the 500 bits per second we postulated above.
There are many ways to reduce the download time, including reducing the size of the file with additional compression (at 10 mbps, the video is already compressed 150 times from an original 1.5 Gbps video signal. I’m talking HD quality here.) , reducing the frame size so it only fills a quarter of the screen, and other methods that reduce the over quality of the resulting image. Or you can increase the size of you network access trunks and hope that you ISP can handle your sized traffic on the other side of the router. A 50 Mbps OC1 should let 100 users have 500 kbps access to your server and it should only cost you an arm, a leg and a head every month.
Now, how about broadcasting a single 500 kbps stream into the internet? And let anyone who wants, to tap in to the stream as it passes by. If you send out your file in a continuous loop for a week or so, everyone who wants will have a chance to tap in. And the network isn’t being tied up with lots of repetitive streams.
This streaming technique is known as Multicasting. The source makes a multicast address available and lets others know what it is. The multicaster starts streaming and interested parties notify their local routers that they want to connect to the multicast address. The routers start querying other routers for the multicast address and when they find a router that has the multicast passing through, that router starts streaming the multicast to the requesting router. The requesting router doesn’t have to go back to the source router/server, just the nearest one with a stream. Now the requesting router can become the source for other requesting routers. And the stream can go around the world on a single thread.
If you think that some of your prospective users can’t access the net at 500 kbps, then cast a stream at 50 kbps and another at 5 kbps. As long as you have 555 kbps that should work. (If not, reduce the first stream to 445 kbps. We’re flexible. We’re not expecting people to use these streams to view real-time video.)
This multicast technique would work very well for online radio stations since it doesn’t matter when you tune in, you just listen to the music from the point you find it and not worry about what came before. For large file transfers, it is a little different. The user needs to capture all the information to have a useful file. If the file that is being distributed is broken into a lot of discreet packages and each package is labeled X of 100000, X+1 of 100000, etc. and the file is multicast in a loop for a week or so, the receiver just needs to collect all the packages to reconstruct the original file. So if a connection is lost, or goes down, for a while, the receiver can tune back in to the multicast and collect the missing packets.
There needs to be software that can parse the packages and another to recover the file. I think that already exists. All we need is a viable Multicasting network. It’s part of the IP protocol, it just hasn’t been activated on most routers because there are some overhead and network utilization problems. Probably the biggest problem will be the financial one. If a router is acting as a Multicast bridge, passing the stream on to other requesting routers, does the router owner get any money out of it? Tying up resources without recompense, what sort of world is this, anyway?
This may be argued for a long time, since the Internet is a network of networks and it is the responsibility of a network to pass traffic through even if that network is not a target with the understanding that other network will do the same with its traffic. But Multicasting hasn’t really taken off, for a variety of reasons.IPv6 should help get it rolling. It will be interesting to see what sort of business opportunities develop with the new IP.
