* Ian Clarke <ian at locut.us> [2006-05-22 00:14:13]:
> 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.
I'm not sure that's a good idea.
People would fake storing the data and would be given credit...
As they already do on BT, Emule and others ;)
Moreover, I'm not sure that making inserting more expensive is the way to
go : they already are by design.
my $0.02
NextGen$
>
> 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
>
-------------- 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/3c63fe6f/attachment.pgp>
