[p2p-hackers] [i2p] Re: thoughts toward i2p persistent storage (fwd from frosk@i2pmail.org)

[Eugen Leitl]

----- Forwarded message from Frosk <frosk at i2pmail.org> -----

From: Frosk <frosk at i2pmail.org>
Date: Thu, 10 Mar 2005 00:45:42 +0000 (UTC)
To: i2p at i2p.net
Subject: [i2p] Re: thoughts toward i2p persistent storage
User-Agent: Loom/3.14 (http://gmane.org/)

David McNab <david at ...> writes:

> The other option is a syndicate of servers, each of which maintain 
> partial mirrors of overall content. However, that takes us at least part 
> of the way to the full kademlia query flooding scenario. Here, we have a 
> scenario where client 'Alice' knows about servers 'Steve', 'Sally' and 
> 'Stan' and 'Samantha'. Alice wants to get 'SSK <at> yadayada/foo/bar'. Assume 
> that only Sally has that item. Scenarios include:
> (i)   alice tries steve - steve says 'try sally' - alice tries sally,
>        sally coughs up the content
> (ii)  alice tries steve, steve puts alice on hold, steve then gets the
>        content from sally, steve says to alice 'here ya go'

The third scenario, covered by Feedspace (aka I2PContent) is that Alice knows
beforehand that Sally has the content, either because Sally is a big-ass
syndicator who, by choice, carries a (relatively) large part of the total
content, or because Sally has announced somewhere that she has it (e.g., through
announcement services available on the same network, through eepsites, etc). You
may think Sally will get overloaded with requests, and you'd be right. However,
Sally enters ad-hoc peering agreements with other syndicators (meaning they
exchange some shared subset of the content they both have), and are able to
refer incoming requests to these if the load needs to be shared. When Alice
reaches a syndicator who can handle her request, say Steve, Alice will in fact
enter such a peering agreement with Steve. Alice now acts as a syndicator for
the content herself, for the duration of the peering. As long as they are
peered, Steve will push content on Alice according to the subscription criteria
of the peering agreement. We keep pulling at an absolute minimum, and let data
flow wherever it's wanted, but nowhere else.

Questions like "but how will I find a syndicator to carry my own content" still
need to be answered, but this shouldn't be a big problem (especially since you
are your own syndicator by default; it just becomes a problem of spreading the
word).

Down the road, it may be nice to have a fully distributed syndicate database for
discovery of syndicators, but this isn't a critical component.

We have started writing some code for Feedspace (though nothing functional yet),
but there's plenty to be spec'ed yet. I'm working on a new revision of the "call
for comments" paper after the IRC discussions following the current rev, but the
current one isn't completely obsolete, so if you haven't yet, it would be cool
if you'd have a look through http://frosk.i2p/i2pcontent-5.p{s, pdf} and tell us
what you think.

-- frosk


_______________________________________________
i2p mailing list
i2p at i2p.net
http://i2p.dnsalias.net/mailman/listinfo/i2p

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a>
______________________________________________________________
ICBM: 48.07078, 11.61144            http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
http://moleculardevices.org         http://nanomachines.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050310/a4782679/attachment.pgp