From obn.chord at offbynull.com Wed Mar 13 00:20:04 2013 From: obn.chord at offbynull.com (obn.chord) Date: Tue, 12 Mar 2013 21:20:04 -0700 Subject: [chord] Dealing with bad nodes Message-ID: <513FFE74.4040009@offbynull.com> Does anyone know of any strategies to prevent, identify, or work-around malicious nodes in the chord overlay? A couple of examples ... 1. Imagine someone wanted to prevent others from accessing a key-value pair. They could create a node and have the id be set to hash(key). Then, when others query that key, the node would simply ignore the query or respond that the key doesn't exist. 2. This is similar to the one above. Imagine someone wanted to prevent others from accessing a key-value pair, but a node already existed with an id of hash(key). They could create a node and have the id be set to hash(key) - 1. Then, when others ask to be routed to that key, the node wouldn't respond with its successor. 3. Imagine someone wanted to cut out a portion of the nodes in the overlay. They could simply add a node and adjust its finger table to skip over a bunch of nodes. I'm sure there are more scenarios, but I think these 3 are the most obvious ones I can think of. From arman.didandeh at uwo.ca Tue Mar 19 14:44:24 2013 From: arman.didandeh at uwo.ca (Arman Didandeh) Date: Tue, 19 Mar 2013 14:44:24 -0400 Subject: [chord] Fwd: Question about Chord algorithm In-Reply-To: References: Message-ID: Dear Chord list members, I was just thinking about the case when each processor's finger table keeps only two entries. Of course one needs to be the successor of each processor. But what about the other one? Since we need to minimize the number of messages passed in the network, as well as to ensure any key to be findable, which other processor do you suggest to keep? - the predecessor's ID? - its own ID n? - the farthest processor's ID, which is successor(n+2^(m/2))? - etc Thanks in advance for the reply. Best, Arman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://amsterdam.lcs.mit.edu/pipermail/chord/attachments/20130319/f66c16a4/attachment-0001.htm