- Site menu:
- Latest Discussions
- Latest Newswire
- Archives
- Submit Story
- Story HOWTO
- Syndicate
- E-mail Alerts
New P2P Internet Audio Idea
There's a new idea gaining momentum in the newsgroups, soon to be on SourceForge, regarding streaming audio. The concept is simple and solves a bandwidth (and thus, cost) problem that website owners face that prevents them from easily serving up audio on their website. Currently streaming audio must be served up by a web host and/or a small army of mirrors. But imagine if fans of that audio content could end up becoming their own mirrors of that content while they listen to it at the same time. As the popularity of your audio content grows, and your fan base increases, so does your bandwidth potential, exponentially, using the power of P2P programming. A special helper app would be required for the content, and the helper app would automatically not make the user as a server for the content if they were on dial-up, did not have the bandwidth to support at least an extra audio stream, or had opted out with a dialog box setting or command-line switch. The technology could revolutionize the way we think of audio on the web, using technology that is accessible today. And the next stop could become live video and screen replay so that businesses and universities could perform massively scalable webinars. News and other types of Internet radio shows could now perform their shows with less cost. Startup companies could now demonstrate their software or sales presentations inexpensively without large website costs. |
Comments (1)
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Sign up and post (it is free) or Log in and post
|
|
You simply can't break a file that way for real-time streaming(note: this is perfect fo podcasts)
You would need two basic servers(yes it can be the same app) One to stream the data, and a conversation channel between the Main server and Node Servers. Requests for the Data stream would have to be either be automatic(maybe region based IP filtering/seperating for speed?) Or you can jump to other nodes manually. Locally, each node could listen in on Localhost:xxxx With the total number of users possible based on bandwidth.(Modem users get one) If Automatic all nodes would have to report the number of users supported and the number currently using(-1).
The next questions are how to deal with sub-nodes, How to keep the conversations small, and how to deal with a node dropping. And how to create and deal with minimal delay (say 30 seconds max).