Question about rpc design

Hi, I'm tinkering with making a DHT im my spare time this summer. For this i need to do some unusual rpc calls. You see in a dht a query (rpc) is first sent from you (node "a") to a node "b" which probably doesn't know the answer. If it still does know the answer it returns the value of the query to node "a". This gives the latency: 2*latency(a,b) On the other hand, if i t doesn't it sends a new rpc to a node "c" more probable to know the ansver. Then the latency is: latency(a,b) + 2*latency(b,c) + latency(b,a) While what I would like is this: latency(a,b) + latency(b,c) + latency(c,a) you see that for many forwards this adds considerable latency and also many more calls than nessesary. Is this way of sending messages already known? Does it have a name? And if not, how hard do you think it would be to hack some rpc library to implement this? -- View this message in context: http://old.nabble.com/Question-about-rpc-design-tp29356441p29356441.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

Is this way of sending messages already known? Does it have a name? And if not, how hard do you think it would be to hack some rpc library to implement this? I think you are describing telescopic routing. Of sorts. The easiest way to achieve your goal is by making the communications asynchronous and
<snip> the party which has an answer to send it directly to the originator. It won't necessarily reduce the latency though, and you would probably get multiple answers, unless you have no redundant data in the network.
participants (2)
-
lysgaard
-
Vladimir Zlatanov