>> >There a lot of other ideas on how to do this but if you or anyone else >> >thinks theirs is better, please explain what advantages this could have >> >over my proposal. If you don't like to do a split LIFO/FIFO that's fine. >> >But the > >> actually, I think it is a very impressive design, with well supported >> examples. I am leery of reordering the queries, because I cannot comprehend >> so many of the consequences that might result. But it sounds like others >> are comfortable with the concept (of prioritizing/reordering), in several >> different forms. So let's go there. And do it slowly/carefully.
>The basic problem is timeouts. If you queue requests, the requestor will >timeout waiting for an answer. And then it will go somewhere else. >Whether this is at the node or the client level, it results in more >load. What's wrong with timeouts. As long as the timeout value is constant or attached to the request, the server knows when to drop the request if it has not gotten to it yet. But that's only a side issue. Can we get something implimented where the node rejects baised on not just overload but also how many querrys a node has pending. That would make routing more "fair". Plus the requesting node would have a much much better estimate of the probability of QR. _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
