Hi Russell, Thanks for going through the draft.
1)Does the finger table only include the primary virtual node ID? The finger table only includes the primary virtual IDs. Routing always happens in two steps. In the first step, you can just imagine that you don’t have the secondary virtual node IDs and just have the primary ones. Then, as in the case of Chord, you would use the primary IDs to route the request to the primary ID closest to the object. At this point, the node that receives the request checks if it owns that part of the ID space. If yes, it simply returns the object/response. If no, then it uses the neighbor tables to route the requests. This would take a maximum of O(log N) additional hops. 2)How to change the estimated N parameter and keep the services non-stopping? Supposing that it has been far away from the actual network scale. I don’t think there will be a situation where it is far away from the actual network scale since the fingers keep updating as and when the network grows. In some ways, the update algorithm will ensure that this situation would not arise. In the worst case, if the situation happens to arise, then that would imply that this particular node is highly imbalanced and is handling a very large amount of load. Therefore, it would be of benefit for the node to offload some of its load. The change can be done by leaving joining the network with a new set of virtual ids and leaving the network with the old ones. This can be done slowly without afffecting services (not leave and join at the same time with all the virtual node ids). 3)Could the imbalance factor be reduced further? Yes. The simplest way is by increasing alpha or by increasing delta. However, if you increase alpha or delta too much then routing would become less efficient requiring more than O(log N) hops. A more complicated way to reduce the imbalance factor is by employing a hierarchical approach and building Y0 over another Y0. Thanks Saumitra From: [email protected] [mailto:[email protected]] Sent: Tuesday, March 03, 2009 10:59 PM To: Das, Saumitra Cc: [email protected]; [email protected] Subject: 答复: [P2PSIP] New Load balancing in RELOAD draft I have read your article, and agree that load balancing is a key issue especially when we deploy the backend server systems built by p2p technology. Some questions following: 1)Does the finger table only include the primary virtual node ID? 2)How to change the estimated N parameter and keep the services non-stopping? Supposing that it has been far away from the actual network scale. 3)Could the imbalance factor be reduced further? Russell Wang [email protected] 写于 2009-03-04 09:10:51: > Hi all, > > I just submitted a draft that proposes a load balancing solution for > the default DHT in RELOAD. Comments are appreciated. > > http://www.ietf.org/internet-drafts/draft-saumitra-p2psip-loadbalance-00.txt > > Best, > Saumitra > > > > > www.saumitra.info > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
