modernize

[jimmywarting]

Would you be up for some several PR if i tried to modernize this a bit?

I would change stuff to newer javascript syntax such as
classes, async/await, const, let, using BigInt, import/export etc

...or is this project totally abandoned? nothing has happened in 5 years.

[jimmywarting]

I would like to verify one thing. when i want to send a message to another node (that i'm not connected to) and expect an answer back, those the answer traverse back the same route it was requested from or dose the response get sent back by other peers in a always clockwise direction?

[oxyflour]

Hello! AFIK the messages will be always routed in a clockwise manner in Chord. According to this article (Page 20), a better solution might be switching from an iterative lookup to a recursive lookup procedure.

[jimmywarting]

I know messages will be always routed in a clockwise manner in the Chord specification.
But I wonder if your api diverge somehow...?

a quick glance From the look of your api when i call something like chord.get(key) then it will not loop around in a hole circle? or am I wrong?

it looks more like it's asking the next person on your behalf...?

say that the max id is 16 and you only have the peer 0,1,2,3,4 & 15

• 0 is connected to 1,2,4 and 15
• 0 ask for the value from key 3, so it first has to ask peer 2
• 2 now has to make the query/request to 3

dose 3 respond back to 2 and 2 back to 0? or do 3 really send it to 4 -> 15 and then 0?

[oxyflour]

Well, the api like chord.get(key) was like RPC calls and was performed in a recursive manner (i.e. peer 0 sends key 3 to peer 2 then peer 2 replies to peer 0) in this case:

• when peer 0 ask for value from key 3, it first call node.recQuery and found itself not responsive for key 3, so it redirect the request to chord.query, then to next peer 2 in hub.query
• when peer 2 received the query, it will do the same thing like peer 0 in here and the response is sent back from 2 to 0 in the following line.

If you use publish/subscribe then the messages should be always dispatched in a clockwise manner.

[jimmywarting]

the api like chord.get(key) was like RPC calls and was performed in a recursive manner (i.e. peer 0 sends key 3 to peer 2 then peer 2 replies to peer 0) in this case:

• when peer 0 ask for value from key 3, it first call node.recQuery and found itself not responsive for key 3, so it redirect the request to chord.query, then to next peer 2 in hub.query
• when peer 2 received the query, it will do the same thing like peer 0 in here and the response is sent back from 2 to 0

ok, thanks for the clarification, then my theory of it being more like a RPC call was correct... this means if the chain breaks (someone leaves) then the response would not be able to get back to the callee, but if the res from chord.get() would have kept on going in a clockwise direction to the person who requested it, the it could in theory be safer agains lost connections - correct?

[oxyflour]

I'm not sure if it would be safer 😄. I just guess it will be better to reuse established connections, because WebRTC is too expensive on browsers.

[jimmywarting]

it would still use already established connections it would just go another route to avoid "churn" (peers that comes and goes)