On Tuesday 18 November 2003 06:41 am, Edward J. Huff wrote: Well, what I want to do is to allow the node to be in control of the backoff time, as follows:
Can anyone explain how this protocol is vulnerable to attack?
Tom Kaitchuck wrote:
(Sometimes it's worth while to try a node even if it is overloaded and sometimes it is better to wait until it's not loaded, and sometimes it's best to use another node. The only way to tell which situation is applicable, is for the requesting node to know the revelevent information)
1000 points to Tom for stating this so well. But, only God has the global perspective to have an accurate "God's eye" view of each node's state _at_any_single_point_in_time_. There is only so much state two nodes can (or should) share across a limited bandwidth channel. Some of it is security-sensitive. This stuff can change *really fast*, but using averages-over-time is the best we can do...
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.
point is that the requesting node should know the load on the other node. And it should know the presentage of the queries that are processing that are it's. And the probability of being rejected is the product of the two. Then the node knows exactly the probability of being rejected. AND the exact
it will never BE exact, but stating this as a goal is commendable.
ken
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
