* Michael Rogers <m.rogers at cs.ucl.ac.uk> [2007-11-30 03:17:14]: > Matthew Toseland wrote: > > But the > > practical effect was reports from various places, not least on my own node, > > of the node using a lot more bandwidth and doing a lot more work than it > > would otherwise have done. > > If the problem is just that nobody's node is reaching the bandwidth > limit, would it be possible to tweak the various load thresholds > (MAX_PING_TIME etc) until nodes seem to be using the configured amount > of bandwidth?
I think that it's the way to go too. > > > 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). NextGen$ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20071130/77bef6f2/attachment.pgp>
