--- Ian Clarke <[EMAIL PROTECTED]> wrote:
> Is it fair that when 3 nodes might have sent me a vast number of
> requests, thus overloading my node, that a 4th node which has never
> asked anything of my node before is refused? Probably not, but how can
> this be addressed?
>
> The obvious option is to bias QRs towards nodes in proportion to the
> degree to which they are responsible for the QR being sent. Now
> clearly, this is an imperfect solution as it relies on negative trust,
> and there really can't be any reliable negative trust on the Internet.
> Having said this, while this mechanism might not be impossible to
> circumvent, it could be enough to encourage developers of high-traffic
> applications such as Frost to make their users try to be better Freenet
> citizens.
>
> Thoughts?
You're asssuming all connections were created equal. If two big Monster nodes are
connected to
each other they might send 10 times as much stuff over thier connect as connections to
all thier
other neighbors. It would seem kind of dumb for them to have to create 10
connections. You can
create a net where all connetions are equal, but I'm not sure you'd want to.
How about this tally messages/data recieved/sent to each peer. Do a Golden Rule with a
botch("credit") factor say 10%. If I've sent you 1000 requests over our knowing each
other, I'll
reject/slowdown your requests once you have sent me more than 1100. The longer P2P
relationships
stay around the better this will work.
It's hard to measure how much of a node's requests are from itself. It goes against
the plausible
deniablity to a degree. Say things happen in average 10 hops. If I use double the
resources of
everyone else my neighbors will only notice an increase of 10% in messages coming from
me.
When using this kind of accounting, you have to make sure nodes aren't just accepting
your
requests and dropping them. The NG metrics should take care of that, I think.
Also don't forget what a newbie node will have to go through in order to get standing.
It won't
be able to do anything but forward requests to other nodes, or drop them. Until it
gets a useful
cache, it won't develope much "credit" to do any requests. Maybe that's something we
want.
Does this help?
__________________________________________________________________
Gesendet von Yahoo! Mail - http://mail.yahoo.de
Logos und Klingelt�ne f�rs Handy bei http://sms.yahoo.de
_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
