Peer-to-peer streaming

Josh Coates jcoates at archive.org
Tue Jan 10 11:54:25 MST 2006


> On Tue, Jan 10, 2006 at 08:48:29AM -0700, Josh Coates wrote:
> so p2p streaming? (an aside- why p2p? isn't this just bandwidth
> theft?)
> fancy tree structures?  multicast?  not sure about all 
> that...but this is an existence proof - it works now, and 
> it's just an ingenius, but relatively simple protocol.
 
somehow i knew that my primary point was going to be ignored, and these
asides were the only thing that was going to be replied to... ;-)

> And "fancy tree structures" happen to form the backbone of 
> all computer science 

and yes michael, we all learned about "fancy tree structures" in our
undergraduate data structures and algorithms courses. :-p

seeing all these references multicast research, and having been exposed to
it in the past from a research perspective, and commercial one i thought i'd
just relay a message that says "hey, that stuff kind of sucked - but i think
we've got it figured out - and it's really easy."

look, the point was that *lots* (not all) of things that change the
technology world we all live and play in today are due to simple things,
solved by simple solutions instead of sophisticated algorithms.  (this is a
*really* easy exercise left for the reader.)

though to pay proper homage to the academic research gods, maybe if/when
move networks goes mainstream with it's new streaming protocol, then it's
likely that research students will write a paper which examines a streaming
protocol that look eerily like the move protocol, and then they will come up
with a new naming scheme or catagory for it (so that it can fit into a
conference, which hopefully is in a cool place that year like paris or
something and maybe if the professor likes the particular graduate student
they will let them go present) and then come up with lots of cool research
jargon and suppositions and whatnot that would make even the slickest .com
marketing vp jealous.   oh, and of course, after everything is published and
the conferences are over they will all sit down and feel pleased with
themselves until they look up and notice that industry has already figured
it all out long before they went to all this trouble. ;-)  (okay, it's not
really *that* bad, but you can tell i've done academic research before,
can't you?)

oh, and i'm going to skip the p2p == bandwidth theft thing.  we should save
that for another day, because it's an interesting topic.

anyway, the http://byu.tv demo is pretty cool, eh?

-josh


> -----Original Message-----
> From: plug-bounces at plug.org [mailto:plug-bounces at plug.org] On 
> Behalf Of Michael Halcrow
> Sent: Tuesday, January 10, 2006 9:22 AM
> To: Provo Linux Users Group Mailing List
> Subject: Re: Peer-to-peer streaming
> 
> On Tue, Jan 10, 2006 at 08:48:29AM -0700, Josh Coates wrote:
> > so p2p streaming? (an aside- why p2p? isn't this just bandwidth
> > theft?)
> 
> How do you figure? If you choose to run a P2P app, the use of 
> your bandwidth is consensual.
> 
> > fancy tree structures?  multicast?  not sure about all 
> that...but this 
> > is an existence proof - it works now, and it's just an 
> ingenius, but 
> > relatively simple protocol.
> 
> Okay, but these papers I mentioned were published in major 
> peer-reviewed journals. The authors implemented prototypes 
> and ran extensive simulations to prove the workability of 
> their solutions.
> 
> And "fancy tree structures" happen to form the backbone of 
> all computer science (yes, my LISP bias is showing again). 
> The key hierarchy covered in the Lam paper is an elegant 
> solution to the sticky problem of dynamic group membership in 
> multicast environments.
> 
> > i suppose adding multicast to cooperate networks would 
> enhance it, but 
> > the real problem appears to be in the actual streaming 
> protocol, not 
> > improving the economics of the packets (eg. multicast.)
> 
> That's what publications like the Byers paper are addressing.
> 
> Mike
> .___________________________________________________________________.
>                          Michael A. Halcrow                          
>        Security Software Engineer, IBM Linux Technology Center       
> GnuPG Fingerprint: 419C 5B1E 948A FA73 A54C  20F5 DB40 8531 6DCA 8769
> 
> "Security must be evaluated not based on how it works, but on 
> how it fails."
>  - Bruce Schneier
> 




More information about the PLUG mailing list