[Haskell-cafe] Question about rpc design

[lysgaard]

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.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Question about rpc design

[Vladimir Zlatanov]

snip 
 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
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.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe