Jusa Saari wrote:
Solution: make the send rate a function of the key in question. Requests to the areas of keyspace that are occupied by slow nodes *should* come at a slower rate, while requests to the areas with fast nodes *should* go at full speed.
This sounds promising, but it still depends on senders being well behaved.
It must be a function of the key, not node, since the node we forward to will forward based on the key, so two requests to the same node will likely differ in speed based on the key.
Any idea how we should divide up the keyspace? IIRC there was a similar issue with next-generation routing - how do we approximate an arbitrary function with a fixed number of points?
So, basically, if we can't forward to the best node, we forward to some other node ? Which causes the request to go the full HTL, increasing the total load in the network and making it more likely that any given request can't be forwarded to the best node, leading to a vicious circle of raising load.
Maybe - or maybe we route around the slow node, adding an extra hop but allowing the network to make better use of the resources offered by fast nodes...
I have said this before and I'm saying it again: routing and load balancing are mutually exclusive goals. You *can't* have both in the same network at the same time.
Obviously you can't have perfect greedy routing at the same time as perfect load balancing, but maybe a compromise between the two will achieve better performance than either extreme.
BTW shall we move this thread to tech to save everyone's bandwidth? A good example of reducing load without reducing coverage. ;-)
Cheers, Michael _______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
