[zeromq-dev] design communication protocols

Andrew Hume andrew at research.att.com
Fri Aug 17 13:00:10 CEST 2012

you have discovered that devising a distributed computation is almost isomorphic
to designing the protocol the distributed parts use to communicate.

this is, in general, quite hard, and i know of no useful shortcuts other than
to try and build on existing patterns (such as in teh Guide).
i have used one method which, although somewhat tedious, did actually work.

the protocol part of teh code was written in pseudocode with m4 macros.
when you "compiled" the pseudocode, it produced two outputs:
1)  working C code 
2) working Spin code (this language used to be called Promela).

Spin is a protocol verifier which can handle fairly large protocols.
the build process verified that the protocol was "correct" (taht is,
it had no deadlocks etc) and then built the executable.

there were occasional missteps in ensuring the two parts were equivalent,
but i will say we never had a protocol botch. that is, we never deadlock'ed
or wedged because of a protocol error. these had all been caught
during compiling.

obviously, none of this was specific to spin; any protocol verifier would work, i think.

On Aug 17, 2012, at 3:41 AM, andrea crotti wrote:

> So now I reached the point where (almost) all my processes are nicely
> configured and they communicate with each other.
> But now I would like to design good communication protocols between
> them, because otherwise it will be a mess..
> I thought about a protocol between each of the communicating couples, as
> for example the worker and the sink:
> class WorkerSinkProtocol:
>    """Communication protocol to communicate between the worker and
>    the sink, sending results and the actual status.
>    TODO:Does it make sense to send also the actual status?
>    """
>    def __init__(self, action, message):
>        self.action = action
>        self.message = message
>    def __eq__(self, other):
>        return (self.action == other.action) and (self.message == other.message)
>    def serialise(self):
>        return DELIMITER.join([self.action, self.message])
>    @classmethod
>    def unserialise(self, st):
>        act, msg = st.split(DELIMITER)
>        return WorkerSinkProtocol(act, msg)
> But I'm not sure it makes sense, because I still have to match on
> self.action in the code that does the job.
> So the alternative might be to have a class for every message type, for
> example
> class Action(Message):
>    def __init__(self, task):
>       ...
> and then in the protocol create the right action objects, but I'm still
> not sure how to proceed.
> Any suggestions, ideas on the topic (which looks quite important but I
> don't find any useful info around)?
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Andrew Hume  (best -> Telework) +1 623-551-2845
andrew at research.att.com  (Work) +1 973-236-2014
AT&T Labs - Research; member of USENIX and LOPSA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120817/1fe65516/attachment.htm>

More information about the zeromq-dev mailing list