On Fri, Nov 21, 2003 at 01:02:32AM -0500, Ken Corson wrote: > >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.
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. > > >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 -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so.
signature.asc
Description: Digital signature
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
