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
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
Toad wrote:
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
Does God have an XML-RPC API?
Ian.
___
Devl mailing list
[EMAIL PROTECTED]
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:
When a fluctuation of the success rate results in excess trailers,
the node estimates how long they will take to transmit. Then it
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
On Mon, 2003-11-17 at 07:18, Martin Stone Davis wrote:
Edward J. Huff wrote:
But, to return to the original subject..., there is an argument for
closing connections instead of QR-ing when load is high. If a node
closes connections, it continues to accept requests from the
connections it
On Mon, 2003-11-17 at 07:18, Martin Stone Davis wrote:
Edward J. Huff wrote:
But, to return to the original subject..., there is an argument for
closing connections instead of QR-ing when load is high. If a node
closes connections, it continues to accept requests from the
connections it
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:
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
On Tue, 2003-11-18 at 11:44, Martin Stone Davis wrote:
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: [...]
When the node estimates that it can safely accept queries, it
will send a second message to all connected
