Usenet Audio
Carel writes "Everybody who has done some streaming knows the downside: as soon as you're getting popular the costs are getting sky-high. While there have been some efforts in the P2P area these didn't have the impact they need. Enter Usenet Audio, a project that uses the existing, distributed and proven Usenet as its medium. Check the site for details and for the beta-versions of the software (which is available for Linux, OS X and MS platforms)."
and we gotta endure a whole 24 hours of these posts over and over?
Ugh, shoot me now....
The less usenet's capabilities are publicized, the better. Do we want the RIAA/MPAA/etc pressuring ISP's for people that download from specific groups? Or pressuring to have those groups removed entirely? Keep it quiet!
it's April Fools day, but....... you never know.
If this is true it will be bad for one reason.
The Usenet has always been a place where those in the 'know' could go to grab or share stuff. Making this mainstream will make this a target as well. If this were to ever become the new 'napster' it would only be a matter of time before laws would start to pop up to deal with it.
How about contracting with an ISP that supports Multicast UDP? Multicast is not broadcast, though it offers similar bandwidth savings.
You send out one packet and pay for it once, the routers split it as appropriate as it spreads. Any router that doesn't support multicast gets one packet for each recipient that must be routed through that node; therefore all ISPs can save money on bandwidth by enabling multicast.
The only downside is that packet storms that bring down whole sections of the internet become available. But, since its UDP and therefore the application should be packet loss tolerant, a simple throttling mechanism can be used.
I am disrespectful to dirt! Can you see that I am serious?!
The sad part is a lot of people submit incredibly clever stories, but they get rejected in favor of stupid things like "Usenet Audio." Look, it's not funny to slap two things together and call it a joke. Just like someone else posted here, it'd be like "HP Sells Toilet Paper," like it's automatically funny because it's HP, and they're selling toilet paper.
At least when Taco is at the helm on April Fool's, better stories get posted. I remember some of the really clever April Fool's days of Slashdot's past, where the fun part was guessing which was real and which was fake. It was always hard to tell.
Usenet should not even be used as an April Fool's joke. You can take my P2P and my WWW, but leave my Usenet alone. This is the last bastion of the original "Internet" yet to be totally whored out to commerce and regulation. Please keep it on the dl.
Or, of course, ISPs could just multicast-enable their networks.
Right now they have little incentive - because enabling multicast for anything but distribution of their own "content" is perceived by ISPs as an added cost that provides them with no new revenue. So ISPs have an incentive not to enable it (or not to enable it generally even if it's on for themselves) while independent net-casters are stuck buying fat pipes to separately transmit streams to each customer - limiting their potential audience to the few they can afford to feed, and thus limiting their load on the ISPs.
But consider what happens with a broad adoption of a cooperative, peer-to-peer, flooding-protocol broadcast workaround:
- The listeners are now using their otherwise unused uplink to forward and fork the stream.
- The broadcaster's potential audience is no longer limited by the size of his feed - so it can expand without limit, just as if multicast were enabled.
- The load on the ISP is the same as if the broadcaster had to give each of his customers a separate unicast feed - but FAR higher than if multicast were used. (And it's harder to manage because it originates diffusely, both throughout the ISP's customer base and incoming from multiple external sources.)
Now the ISP gets the NxUnicast load ANYHOW. This gives him a strong financial incentive to enable multicast - even for external originators - and try to move his users to it.
If the application can detect, and automatically use, multicast when/where it's available, it will provide an INSTANT reward to the ISP for enabling multicast. Even if the program originated outside his network, the peer-to-peer links within it would be multicast, producing a drastic cut in his traffic. (The application could easily have multiple multicast islands connected by unicast links - and even adjust the routing to merge multicast islands and minimize back-and-forth unicast routes connecting them.) The forward-looking ISP gets lowered costs, his competition still pays. Market advantage. So once one adopts it, the rest either stampeed with him or get hit in the pocketbook and left in the dust.
Turning on multicast is a win-win for the ISP (who gets lower costs and better system utilization) and his customers (who get much lower latency when the stream is delivered by multicast than by many unicast hops.) This gives the application authors an incentive to include opportunistic-multicast and the users to prefer a multicast-capable solution over a unicast-only first cut.
= = = = = =
The original article may have been an April Fool joke. But it has pointed out a solution to one of our big problems. A peer-to-peer streaming broadcast application, combining the usenet flooding algorithm and voluntary-link-subscription approach with dynamic configuration ala Bit Torrent and opportunistic multicast will provide:
- a useful service under current ISP policies
- a built-in, seamless and automatic, migration path to a better solution, and
- an evolutionary selection pressure on ISPs to implement it.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way