On Mon, May 22, 2006 at 10:53:38AM -0700, Ian Clarke wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > What system? Is it described in a wiki page? I have seen a *lot* of > ideas thrown around, but I haven't seen a single proposal. Perhaps I > have overlooked it.
There have been many proposals. :) > > Ian. > > On 22 May 2006, at 10:39, Matthew Toseland wrote: > > >I think the system we have been debating will adequately manage load, > >propagating load back to its original source, and preventing flooding. > > > >On Mon, May 22, 2006 at 12:14:13AM -0700, Ian Clarke wrote: > >>We have a summer project that will hopefully be accepted which will > >>focus on load balancing, but that shouldn't prevent us from > >>discussing the issue. > >> > >>As I see it, we need some form of "tit-for-tat" system, as > >>popularized by BitTorrent, where nodes incur credit or debt with each > >>other every time they send requests to each-other. For example, if > >>node A sends a request via node B which is answered by node C, then A > >>incurs a debt to B, which incurs a debt to C - since C answers the > >>request, it incurs a debt to nobody and thus gets a net credit in the > >>network as a whole. Note that B's network debt remains unchanged as > >>it just forwarded a message. > >> > >>This approach means that nodes initiating requests incur debt to the > >>network, while those answering those requests incur credit. I think > >>we would probably handle inserts in the same way - a node initiating > >>an insert would incur a debt, but the node where the data gets stored > >>incurs a credit. > >> > >>So we keep track of how much each node is contributing, the question > >>then is how we bias in favor of nodes that we are in debt to - > >>considerations are: > >> > >>1) A new node should be given the opportunity to build up credit with > >>the network, to do this it has to be able to make requests > >> > >>2) We need to avoid a deadlock situation where all nodes are refusing > >>to talk to each-other > >> > >>3) Ideally, we want to avoid any situation where nodes are just > >>sitting around waiting for each-other > >> > >>4) We also want to avoid situations where nodes all end up being > >>forced to make poor routing decisions - as these simply increase the > >>load on the network by making requests go through more hops - > >>worsening the overload problem. This is the issue we ran into in > >>previous versions of Freenet. > >> > >>Ian. > >>_______________________________________________ > >>Tech mailing list > >>Tech at freenetproject.org > >>http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > >> > > > >-- > >Matthew J Toseland - toad at amphibian.dyndns.org > >Freenet Project Official Codemonkey - http://freenetproject.org/ > >ICTHUS - Nothing is impossible. Our Boss says so. > >_______________________________________________ > >Tech mailing list > >Tech at freenetproject.org > >http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (Darwin) > > iD8DBQFEcfqlQtgxRWSmsqwRAtslAJ92D4/jhvR2hk1qNzNdM3aTvp8+bgCfSPji > v3Z42nSr3M8DjrUFh+MNQto= > =5UKM > -----END PGP SIGNATURE----- > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20060522/f44a95f3/attachment.pgp>
