Evan Daniel wrote:
> If we're knowingly misrouting around slow nodes, then it seems to me
> we should make a specfic effort to have the one request that can go to
> the slow node be the one that it is most likely to be able to serve,
> instead of the one that happens to arrive first.

I agree in principle, but the question is how to do that without 
introducing long delays - how long should you wait for a request that's 
closer to the slow peer's location?

Could we give slower peers a smaller region of the keyspace, not by 
modifying the swapping algorithm but by modifying the algorithm that 
determines which peer is closest to a given key when routing a message? 
For example, instead of circular distance could we use circular distance 
over speed? Again, there would probably have to be limits to prevent a 
fast peer taking over the whole keyspace...

Cheers,
Michael

Reply via email to