Re: [Blocks-development] Content caching and replication...and deniability

[<lu...@et...>]

* Michael Spencer Jr. wrote:
> [snip]
> In the change I'm proposing...suppose my client keeps the blocks cached, but
> doesn't advertise the completed file.  Once the download is complete, other
> clients only see search results with routing entries AF, but the data comes
> directly from me.  Suppose the leaf node disconnects...now routing entry F
> on my client is invalid.  However, the file is still known to the rest of
> the network as on AF (for example).  If a client again tries to download AF,
> ideally instead of returning that the route is no-longer valid, my client
> should return the cached blocks, not revealing the fact that my node F has
> disconnected.
> 
> Wait a minute...there seems to be a hole in my logic somewhere.  Can someone
> help me find it?

Your logic looks sound to me, but I think there may be more going on under the
hood than you think.  Perusing the code I saw a message that seemed to be
fore 'unadvertising' a route when a connection goes away.  If this
were done then, in your example, the route 'AF' would be unadvertised and
you'd be holding a file in your cache for no reason.

On a related note, I'm getting the impression that files fall out of
the cache when they're replaced by something "fresher".  This seems
to include things I've shared from my local drive, though, so I 
have to keep re-adding them to the cache every so often.  Is this
really the case?  Perhaps there should be two caches, one "sticky" and one
for files that are "just passing through"?

-Luke