Sounds good to me. But why bother with the token? We already know which peers we sent an "overload cleared" message to.Well, what I want to do is to allow the node to be in control of the backoff time, as follows:
When a fluctuation of the success rate results in excess trailers, the node estimates how long they will take to transmit. Then it informs all of its connected peers that it is going to ignore all queries _that is has not already responded to_. And if there are no sequence numbers in messages, this application requires them because the other node needs to know exactly which queries this statement applies to. (This solves the "in transit" problem).
The message sent to the connected peers is a contract: the node promises to ignore a specific set of messages, starting with a particular sequence number, and as yet open ended. Call this the overload message. It amounts to a reply to all of the in-transit messages, and a promise to ignore any and all subsequent messages.
When the node estimates that it can safely accept queries, it will send a second message to all connected peers, call it an overload cleared message. This message contains a token which the peers must present in the next request. Any requests still in the pipeline will be ignored until one with the token arrives.
Can anyone explain how this protocol is vulnerable to attack?
Sounds safe to me.
You could even go a step further and send that "overload cleared" message to only a portion of nodes instead of to all, which might result in better load balancing (you'd prevent everyone giving you too many queries all at once). (Note that this *would* be vulnerable to operators creating multiple nodes, but there are defenses to that as discussed in the recent thread about negative trust.)
As maybe you know, this is not the first time a requestee-controlled QR backoff scheme has been proposed. See "[Yet] another load-balancing idea" et al. Perhaps someone should review all the various ideas proposed so far and summarize them for the list...
-Martin
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
