[p2p-hackers] p2p in some place or other

[Serguei Osokine]

On Sunday, December 11, 2005 David Barrett wrote:
> How much of this is motivated by a desire for "high availability" 
> versus "high performance"? 

	Not sure how to separate those. They are closely related. For
example, in Gnutella the average host session time is about an hour
and a half. So if you try to get something from this host, and it
will give you only 1 KB/s (a frequent occurence, because content
tends to be concentrated on relatively few nodes), then you'll be 
able to receive only about 5 MB during the average host session.

	In fact, the average transferred volume before this host goes
off-line will be half of that, or about 2.5 MB. Not enough to get 
even a single song. So availability and performance are closely
related.

> In other words, if you had a "guaranteed seeder" for the file that
> you knew would never go offline, would proactive caching still be 
> worth the trouble?

	That does solve the availability problem; not sure about the
performance one. Personally, I wouldn't like to download movies at
1 KB/s and wait several days for the download to finish. But people
use eDonkey all the time - and its speed is not much better. So the
answer depends on whether you want to make your users happy or you're
fine with someone else doing that, I presume :-)

	Best wishes -
	S.Osokine.
	12 Dec 2005.


-----Original Message-----
From: p2p-hackers-bounces at zgp.org [mailto:p2p-hackers-bounces at zgp.org]On
Behalf Of David Barrett
Sent: Sunday, December 11, 2005 11:01 PM
To: Peer-to-peer development.
Subject: Re: [p2p-hackers] p2p in some place or other


Serguei Osokine wrote:
> On Sunday, December 11, 2005 David Barrett wrote:
> 
>>Thus the uploader can either choose to:
>>a) Send the file only to the downloader
>>b) Only to the innocent bystander
>>c) To both
> 
> Add to this:
> 
> d) send the file to bystander in advance, even before the downloader
>    asks for it

Ah, ok, so it sounds like your saying that proactive caching becomes 
valuable when the bystander gets the file before the downloader makes 
its request.

(This seems obvious in retrospect, but I was thinking along the lines of 
"just in time" proactive caching -- sending the file to more than just 
who requested it to somehow improve the experience for the requester.  I 
couldn't see any way to make this work, though I'd be happy to be wrong.)

So really, it sounds like proactive caching sets a "minimum replication" 
target for every file with one or more requests.  Thus the policy is to 
keep making copies until that target is achieved.  If anyone goes 
offline (and thus reduces a file's cache count below the minimum 
threshold), a new cache is made.

How much of this is motivated by a desire for "high availability" versus 
"high performance"?  In other words, if you had a "guaranteed seeder" 
for the file that you knew would never go offline, would proactive 
caching still be worth the trouble?


Again, my initial thought around proactive caching was to use it to 
improve download performance by making the long tail download as fast as 
a well-deployed file.  (And I still don't see how to make that happen 
without simply making every file "well deployed" through massive 
proactive caching.)

But I can see how very limited proactive caching can be used to improve 
availability, and thus ensure the interesting subset of the long tail be 
downloaded *at all*.

-david
_______________________________________________
p2p-hackers mailing list
p2p-hackers at zgp.org
http://zgp.org/mailman/listinfo/p2p-hackers
_______________________________________________
Here is a web page listing P2P Conferences:
http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences