Hi,
instead of sending only the pid in the request to protocol B, you can
pass further information and send them back in the reply.
We do this in our transactional key-value store Scalaris, which is
written in Erlang, to ease use of asynchronous protocols
stacks. (scalaris.googlecode.com). There, protocol B does not have to
know anything special. The trick is, that a pid in Scalaris can either
be a native pid or it can be a tuple with the pid and what we call an
'envelope'. Our send method does the rest transparently. It detects
whether pid is native or is a tuple of a pid and an envelope. If it is
a tuple, the actual reply message is embedded in the envelope and the
pid is extracted and used for a recursive call to send(Pid,
Message). So envelopes can be nested.
The receiver than has to cope with messages its envelopes generate.
How does such an envelope look like? The envelope is just a tuple and
a number at which element of the tuple the reply message should be
filled in:
{envelope, 2, {reply1, '_'}}
or
{envelope, 3, {reply2, SomeProtocolAState, '_'}}
In the call send(ReplyPid, Msg) at the end of protocol B
ReplyPid equals {ActualReplyPid, {envelope, 2, {reply1, '_'}}}.
the send function changes that to:
send(ActualReplyPid, {reply1, Msg})
So, the caller can define how an asynchronous protocol replies to it.
(And even better: the caller can pass some state information in the
envelope and may avoid some separate bookkeeping for small volume
data)
Florian
> Hi,
> I was reading recently some information about asynchronous protocols (For
> example byzantine agreement, reliable broadcast and some more). I noticed
> that there are many articles about these subjects, some date back to year
> 2000, though I haven't found any examples of making such code work.
>
> I refer you to
> http://www.shoup.net/papers/abba.ps
> for an example of such article.
>
> In this article it seems like the author has the ability to call one
> asynchronous protocol from the execution of another asynchronous protocol,
> Though I could not find any specific explanation to the design of such a
> system.
>
> I will try to be more specific:
> If protocol A calls protocol B twice during its execution, and during the
> second execution of protocol B it sends some message, how does the node on
> the other side of the line know whether the message sent refers to the
> first execution of the B protocol, or to the second one?
>
> I assume some of you had the opportunity to think about these kind of
> challenges. Do you have an idea for a simple solution to resolve this, or
> maybe do you know about an existing implementation?
>
> Regards,
> real.
> _______________________________________________
> p2p-hackers mailing list
> [email protected]
> http://lists.zooko.com/mailman/listinfo/p2p-hackers
Florian Schintke
--
Florian Schintke <[email protected]>, http://www.zib.de/schintke/
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
