On Nov 30 2007, Matthew Toseland wrote: > No, the proposal was that the node sends a solicitation for a single > request. Or perhaps for a number of requests. It's essentially token > passing.
Ah sorry, I misunderstood the proposal. > This is exactly what I am trying to achieve: A good transport layer. But > for Freenet, the transport layer is *everything from the request source > to the data source*. Call it what you want - the point is that you have to make a distinction between "something between the request source and the data source is busy", "my immediate downstream peer is busy", and "the link to my immediate downstream peer is busy". At the moment it's not clear which of those things is causing the problem. I'm arguing that if we separate them more clearly, with a well-defined socket-like interface between peers that behaves more or less like that other famous well-defined socket-like interface, then the problem of load control / load balancing will become managable. > What I propose above is the exact transposition of your "don't read any > more packets from the socket" to something that can actually be > implemented at the request layer. We don't accept (read) another request > (packet) until we have space in our queue (buffer). It's exactly the > same. You're right, token passing is pretty similar to sockets - but if the transport layer behaves correctly (ie it blocks when the buffer is full and/or the link is congested) then token passing should be redundant. We can tell which peers are busy because their sockets are blocked. > It would apply to all requests. If we accept a "bad" request, that > occupies a slot that could be used by a "good" request. It may occupy it > for a very long time, because we won't accept any more potentially "good" > requests in the meantime. Hence the need for a timeout leading to > backtracking. We stop sitting on a bad request so we can accept a good request and sit on that instead? If we have any peer that's unblocked and below twice the median, we can send it the bad request. If not, why accept the good request? We won't be able to forward it either. Cheers, Michael
