h a l f b a k e r yNeural Knotwork
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Please log in.
Before you can vote, you need to register.
Please log in or create an account.
|
Multicast is a group of IPs that allow a single site or group to broadcast a stream of data that theoretically anyone receiving that multicast stream can listen into and watch or capture.
Back when I worked at the Pentagon, a bunch of my Air Force geek friends set up a multicast music channel, streaming
a random mix of music anywhere in the AF network.
Multicast hasn't been used (to my knowledge) much for globally broadcasted data, much more for a network-centric data stream. There has been no agreement among providers about accepting a stream from another network and broadcasting it to its own, nor has there been a way in the past for the end user on the "Last Mile" to "tune into" these multicast channels broadcasted but not received by other networks.
Let's build a network that simply streams data, whether it be data files, music, TV, anything digitized. Take that network and have major providers enable the end user on the Last Mile "tune into" these channels. If I have the bandwidth, I can just accept the stream to my connection and voila -- I have my data.
Alternatively, let the major providers have a caching system where data is stored for a period of time, enough so that I can say "give me what was broadcasted on stream 224.5.3.1 between 22:04:33.442 and 22:04:34.557" which according to the channel owner is CSI: Miami (or maybe something the networks wouldn't mind). The provider just looks up that stream during that time and sends you the file.
Effectively, this allows you to set up your computer to "record" channels between certain times to get "shows" where the shows may be movies, mp3s, video conferences, word docs, torrent files, anything.
Sure, that will require a new protocol of sorts, that adds some metadata to the channel stream, depending on the type of data that is being sent. But it should allow all of us to receive massive amounts of data without forcing everyone to go peer to peer, or kill a single server being forced to make 100,000 simultaneous copies to 100,000 different networks.
BBC Article about not enough fiber
http://news.bbc.co....hnology/6342063.stm
Not enough Fiber [ooglek, Feb 12 2007]
University Project based on Digital Television over Multicast
http://www.doc.ic.a...tv/doctv-report.pdf
I've not read it but it seems very interesting and also very extensive - if not the completely satisfactory. [Jinbish, Feb 12 2007]
[link]
|
| |
The caching/rebroadcast system is the tricky part - otherwise, you could just use existing digital television channels, right? BitTorrent probably does a fairly good job of store-and-forward right now, while requiring much less in terms of infrastructure and support. What problems are you trying to head off by not "forcing everyone to go peer to peer"? |
|
| |
BT still requires many to one transfer, rather than a distribution of content globally, pushing the content closer to the end user, and thus removing lots of transit data from the network. |
|
| |
Right now, 100 people downloading a torrent generated probably 100,000 simultaneous TCP connections, ideally downloading from peers closest to them network-wise, but realistically from anyone who is sharing that torrent, which is most likely not on your local network. |
|
| |
To reduce bandwidth between providers, streaming data and being able to "dip your cup into the flowing river" of data means everyone can get the data as it passes by. Popular files might get scheduled to repeat more often, others may just send a file once. Some channels may be 5mbps and others could be 5tbps. Clearly a channel running at 5tbps couldn't be accepted by a home user, and thus the need for some caching or buffering at the network so users can download at 3-30mbps and still get the files they want. |
|
| |
//Let's build a network that simply streams data, whether it be data files, music, TV, anything digitized. Take that network and have major providers enable the end user on the Last Mile "tune into" these channels.// |
|
| |
In many ways, this is cable television. The stream happens to be MPEG2-TS (in the case of DVB-C) and it isn't quite multicast streaming, but it is, in essence, what you are describing. |
|
| |
Multicast isn't really used in the normal IP sense, but it would have to be if this was taken up over the Internet and still provide decent Quality of Service. There is a lot of this kind of stuff in the research community - especially in the mobile cellular world, where the access networks are now using IP and seeking to provide multimedia to end users. |
|
| |
If you would like to implement this yourself, you can do this with:
i) A great big Internet pipe.
ii) DVB PC card + MythTV
iii) VideoLAN (running as a server - possibly transcoding too)
iv) some lawyers to fend off the piracy & unauthorised broadcast claims. |
|
| |
Hmm - intriguing. What your saying is that broadcasting technology might be useful for broadcasting content after all... That's crazy - but it might just be worthy of study... ;-) |
|
| |