-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matthew Toseland wrote: > I don't understand what you mean when you talk about token schemes. We > can certainly tell our peers how many requests they can send - but so > what? How does this limit load?
We tell a peer when its bucket is empty, and it stops sending requests. This is more efficient than waiting for a request we know we'll reject anyway, then rejecting it. (But we can fall back to that if the peer isn't well behaved or the messages cross on the wire.) > I don't see how you are propagating them either. There are two answers to this, depending on what you mean by propagating. I've got the impression from earlier discussions that you mean asking the source to slow down. If that's the case then here's how we propagate load: * A peer would like to send us a request * There are no tokens left in its bucket (and we've told it so) * Being unable to forward the request, it has to reject it * The RejectedOverload travels back to the source * The source slows down On the other hand, if by 'propagating' you mean calculating how many tokens to give our peers on the basis of how many tokens our peers have given us, here's what I'd suggest: * Calculate the ratio of incoming to outgoing requests (running average) * Work out how many requests our peers are willing to accept, in total * This tells us how many requests we can accept, in total * Divide these requests among our peers (eg give each bucket the same number of tokens, with full buckets overflowing into the fullest non-full bucket) > One major constraint: One fast node must not result in our request > throughput greatly increasing! We do not want a situation where all > requests are routed to the nearest ubernode regardless of keys! I agree, but I think that would only happen with misrouting, which I'd prefer to put aside until we've dealt with load balancing. For the moment, can we assume that a request will only be routed to one peer, and if that peer's overloaded the request will be rejected? Cheers, Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEmH6Vyua14OQlJ3sRAic3AJ944U29UdPbbwMSYcGBxsiAfH9vsgCg9ct3 zLb5SF7PgmIGVF0//kU+gbI= =EvbL -----END PGP SIGNATURE-----
