On 28 Mar 2002 at 2:18, Adam Back wrote: > And gnutella is not able to resume a transfer that dies part way > through which is very bad for download reliability. FastTrack/Kazza > (but no longer Morpheus since the Kazza / Morpheus fall-out) on the > other hand can resume, and in fact do multiple simultaneous downloads > from multiple nodes having the same content so that it gets the > content both much faster and much more reliably.
Actually, the gnucleus client will do both of these, so presumably the gnutella morpheus does also since it's based on gnucleus. > Also helps cope with > different link speeds as a group of slow nodes or asymmetric bandwidth > nodes (like cable with fast down but limited up) can satisfy the > download of cable and other broadband users. > > There's a nice write-up about the gnutella's problem's on openp2p.com > [1]. > > Contrary to what article [2] claims FastTrack/Kazza really does blow > Gnutella away, the supernode concept with high performance nodes > elected to be search hubs makes all the difference. Gnutella last I > tried it was barely functional for downloads, ~95% of downloads > failed, and searches were much slower. > > Adam > I think the idea (used in alpine) of using UDP for search queries and only establishing a persistent connection when you actually want to transfer a file is a good one. George > [1] Gnutella: Alive, Well and Changing Fast, by Kelly Truelove > > http://www.openp2p.com/pub/a/p2p/2001/01/25/truelove0101.html > > [2] Gnutella Blown Away? Not Exactly, by Serguei Osokine > > http://www.openp2p.com/pub/a/p2p/2001/07/11/numbers.html
