On Friday 30 November 2007 17:52, Michael Rogers wrote: > 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.
Just like with TCP! TCP is end-to-end! > 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. TCP/IP is end-to-end. It loses packets on each hop. > > > 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. One request and one ack use the same number of bytes in immediate terms of just that message, but a request will use a LOT more bytes overall. Therefore, IMHO it would be inappropriate to limit messages rather than requests. We may need to limit messages as well, but requests are the main concern. > > > 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. How exactly do you decide which requests to accept then? > > Cheers, > Michael -------------- 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/11a7cf56/attachment.pgp>
