On Friday 30 November 2007 08:52, Florent Daigni?re wrote: > * Michael Rogers <m.rogers at cs.ucl.ac.uk> [2007-11-30 03:17:14]: > > > When a node has spare capacity in terms of the number of requests it can > > > carry, it sends a message to this effect, inviting requests, to each of its > > > peers. A node receiving such a message will normally send the queued request > > > closest location-wise to the sender, although timing concerns may factor in > > > also. Within a short period several requests will have been received, and the > > > node will accept one and reject the others. > > > > This sounds pretty similar to the current system - when a peer rejects a > > request we raise a flag and don't send it any more requests until the > > flag is lowered. But the flag is currently lowered by a timer, and > > you're saying it should be lowered by an explicit signal from the peer? > > That makes sense in principle, but whether it works in practice depends > > on whether nodes can estimate their capacity well enough to send the > > signal at the right time. > > We could have both (timeout or peer said so).
IMHO backoff isn't working. The explicit request soliciting message and request rejections will work cleanly together, although they're not perfectly efficient. But the proposal I gave is nowhere near 0.5's typical route-to-the-only-node-we-think-isn't-overloaded behaviour, for example. > > NextGen$ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20071130/3648c793/attachment.pgp>
