> - If the network implementation takes node-weighs into account, the
> frequency should increase if the node guesses that the quotient of
> it's weight and the key interval's length (it is responsible for) is
> too small/big compared to the same quotient of other nodes he knows
> about, and the required realignment can be done only by other nodes.
Interesting. I assume 'key internal's length' is the node's
interval that the node is trying to optimize. When you say 'other nodes
he knows about', do you mean the other nodes in it's finger table? I
suppose that is what you meant. If yes, then are you gonna ping all
these nodes for their quotients? That might turn out to be a bit costly,
considering the fact that the stabilize algorithm contacts just two
nodes at the most. Or perhaps, you could ping a subset of the finger
table, such as the closest 'n' nodes. Or better still, add another entry
'quotient' to the finger table that contains the quotient of each node.
That way, you wouldn't have to ping all those nodes. But if you do that,
I wonder how quickly will the 'quotient' entries get stale, and how
drastically will it affect the accuracy of the node's frequency. Very
interesting issues to ponder upon. :-)
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gabor Czigola
Sent: Tuesday, September 25, 2007 9:07 PM
To: theory and practice of decentralized computer networks
Subject: Re: [p2p-hackers] Chord stabilize frequency
On 9/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
>
> Hi Gabor,
> I had the same question too while implementing Chord. For now, I
> have used an arbitrary interval to run the stabilize algorithm. It'll
be
> interesting to know if someone has put more thought into this. Maybe
an
> algorithm to learn and evolve the frequency as the network continues
to
> function. A question: what are you suggesting when you say
"extrapolate
> it"?
>
> Regards,
> Ratul Mukhopadhyay
I guess it would make sense to adopt the frequency of the update
interval dynamically from the combination of the following parameters:
- The count of finger-table entries (after joining a network this list
is empty, multiple updates are required).
- The count of nodes in a given period of time which fail to respond
(this means there are dead entries in the finger table, probably
because the nodes leave and join the network faster then the update
occurs).
- If the network implementation takes node-weighs into account, the
frequency should increase if the node guesses that the quotient of
it's weight and the key interval's length (it is responsible for) is
too small/big compared to the same quotient of other nodes he knows
about, and the required realignment can be done only by other nodes.
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Gabor
Czigola
> Sent: Tuesday, September 25, 2007 2:53 AM
> To: P2P hackers mailing list
> Subject: [p2p-hackers] Chord stabilize frequency
>
> Hy!
>
> I'm actually working on the implementation of a p2p library, I call it
> libDRPC (distributed remote procedure call). I began the
> implementation just a few weeks ago, and it will take a long time
> before I have finished it.
> The main goals are:
> - The library supports connecting to networks, registering RPC's
> locally, and handling remote RPC requests.
> - The library supports internetworking.
> - Nodes can be weighted.
> - Nodes are looked up with keys.
> - The keys are well-balanced.
> - Nodes have information about at most O(log n) hosts, and have no
> information about the total node count.
>
>
> The joining/routing/key lookup algorithms are based on Chord.
>
> The Chord spec [1] states on page 7:
> "Every node runs stabilize periodically (...)"
>
> We can find a similar update / stabilize procedures in other p2p
> systems. But what is a good interval to run it? Should the frequency
> be a constant, or shall I extrapolate it? When the latter, how?
>
> [1] http://pdos.csail.mit.edu/papers/chord:sigcomm01/
>
> --
> Czigola, Gabor
> _______________________________________________
> p2p-hackers mailing list
> [email protected]
> http://lists.zooko.com/mailman/listinfo/p2p-hackers
>
>
> The information contained in this electronic message and any
attachments to this message are intended for the exclusive use of the
addressee(s) and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately and destroy all copies of this message and any attachments.
>
> WARNING: Computer viruses can be transmitted via email. The recipient
should check this email and any attachments for the presence of viruses.
The company accepts no liability for any damage caused by any virus
transmitted by this email.
>
> www.wipro.com
> _______________________________________________
> p2p-hackers mailing list
> [email protected]
> http://lists.zooko.com/mailman/listinfo/p2p-hackers
>
Regards,
--
Czigola Gabor
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
The information contained in this electronic message and any attachments to
this message are intended for the exclusive use of the addressee(s) and may
contain proprietary, confidential or privileged information. If you are not the
intended recipient, you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately and destroy all copies of this message and
any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should
check this email and any attachments for the presence of viruses. The company
accepts no liability for any damage caused by any virus transmitted by this
email.
www.wipro.com_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
