[p2p-hackers] p2p in some place or other

[David Barrett]

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