> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 > /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
