> > what about basic pcache not on "first response time" (latency) but on
"transfer speed" (ticker started when key is requested and stopped when the
last byte of
> > the requested key is tranferred, resulting into a bytes/sec value, just
like on the splitfile information pane) ?
> > in fact, ever
On Sat, 2003-04-05 at 03:58, [EMAIL PROTECTED] wrote:
> >This is a great idea, but I see one problem. What if a malicious node
> >just responds quickly but "trickles" the data at something like 10
> >bytes/minute? Should transfer speed also be taken into consideration
> >with this algorithm? I c
>This is a great idea, but I see one problem. What if a malicious node
>just responds quickly but "trickles" the data at something like 10
>bytes/minute? Should transfer speed also be taken into consideration
>with this algorithm? I could see a node serving up dozens of
>connections over a dialu
On Wed, 2003-04-02 at 19:26, Ian Clarke wrote:
> I have given some thought to the next generation routing
> algorithm, and how to implement it efficiently.
>
> the idea is to efficiently store information about each node's
> response times for specific keys. The challenge is to store this
> infor
> comments?
(Excuse the lack of proper quotage/replyage, I'm stuck on MSOE right now.)
I think I like this. The algorithm, if I understand it, seems decent to me,
and the purpose sounds very nice. An algorithm that uses an objective
measure of performance as an integral part of routing, rather th
> Okay, so we have a bag of {key, time} points, at various points on a
> cylindrical space, and when we get a response, we plot the point
> corresponding to what just happened, and we move the others closer to
> it, gravitationally. And then we join the dots and use that to estimate
> response time
On Wed, Apr 02, 2003 at 05:03:47PM -0800, Ian Clarke wrote:
> Another clarification:
>
> > When a response time is reported for
> > a particular key, all of the vectors are moved closer to it
> > (assuming a two-dimensional plane in the key and the response
> > time), vectors which are further awa
Another clarification:
> When a response time is reported for
> a particular key, all of the vectors are moved closer to it
> (assuming a two-dimensional plane in the key and the response
> time), vectors which are further away, will move less (something
> akin to a gravity-attraction equation can
Just to clear up some confusion, I was referring to the idea of a vector in
the mathematical sense (like a set of coordinates), not the Java Vector
class! If you got confused, go back and re-read - it will make lots more
sense.
--
Ian Clarke [E
I have given some thought to the next generation routing
algorithm, and how to implement it efficiently.
the idea is to efficiently store information about each node's
response times for specific keys. The challenge is to store this
information efficiently, while allowing efficient response time
10 matches
Mail list logo
