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? > 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. > How to define spare capacity? Initially we simply have an arbitrary number of > requests. We can tune this, or introduce an algorithm to tune it, later. This is the real problem: a node doesn't know when it's busy. I'm not sure it makes sense to change the signalling between nodes until this problem is solved. When you say "an arbitrary number of requests" do you mean that when the queue reaches a certain length the node considers itself busy? What happens when a local client dumps a load of requests on the queue - do we tell all the peers to back off until we've processed all the local requests? > One obvious problem is that requests which are not close to any of our nodes > may not get sent for a very long time, and worse, they may clog up the node > so that requests which are closer to the target don't get through. I don't see how the head of the queue could be blocked but some other item in the queue could be sendable. Either a peer has handled twice the median number of requests, in which case it's embargoed for all requests, or it hasn't, in which case we can send it the request at the head of the queue. (Incidentally we need to recalculate the median when a peer disconnects, otherwise we could deadlock with all the fast peers embargoed and all the slow peers disconnected.) Cheers, Michael
