[zeromq-dev] Explicit patterns

Brian Granger ellisonbg at gmail.com
Fri May 28 05:13:58 CEST 2010

On Thu, May 27, 2010 at 6:18 PM, Mark V <mvyver at gmail.com> wrote:
> On Fri, May 28, 2010 at 12:30 AM, Martin Lucina <mato at kotelna.sk> wrote:
>> sustrik at imatix.com said:
>>> >> So your view is that there is no need to rename/fixup the socket type
>>> >> names, that won't make things any clearer...?
>>> >
>>> > Yes, definitely.  I think it would confuse the situation.
>>> I agree with Brian.
>> +1
> Hmm I actually quite liked what Pieter proposed - as a
> messaging-architectures novice.
> I've re-read what Pieter proposed, and the difference of opinion seems
> deeper than naming.
> Pieter proposed making patterns '1st class entities'.

I agree pretty much agree with you that Pieter's proposal was a move
in this direction.

> With this
> elevation (logical and consistent) naming of sockets and devices
> becomes (in my mind) an issue.
> It seems the objections are less about the naming, and more about
> keeping sockets as the primary building blocks.

Yes, definitely, this summarizes my point well.  I do think that
socket are the primitive building blocks in 0MQ and should remain so.
Part of the reason I feel this way is that 0MQ sockets are uniquely
positioned just above raw POSIX sockets in the network stack.  The
"patterns" in my mind are way up the stack at the application level.

> From my POV: When I come to 0MQ I have a problem in mind.  The sooner
> 0MQ's building blocks can match my mental picture of the problem the
> more likely I am to commit time and effort to addressing the
> inevitable wrinkles.

What is the problem you are trying to solve with 0MQ?  Maybe we can
help think through how it maps onto the socket abstraction...oh wait I
just saw below that you give some details...

> Scenario:
> I have a many-clients one-server application in mind.  There are other
> latent behaviors, but they are not yet recognized as influencing the
> architecture I choose.  I come to 0MQ wondering, "Is this worth
> looking into?"

Can you say more about what the clients need to do with the server.
Or what functionality does the server provide to the server?  We have
used 0MQ in this capacity and here are some observations:

* You probably want to have an XREP(server)/XREQ(client) channel.
This will allow clients to make RPC calls to the server.  You want the
"X" versions of REP/REQ to support multiple clients and also to allow
clients to have multiple requests on the fly.

* It also might be useful for the server to have a
PUB(serveR)/SUB(client) channel that the clients can subscribe to to
receive out-of-channel events.  For us, this worked absolute magic.
Once we had a PUB/SUB channel many things that we had previously tried
to hack with RPC and polling made perfect sense and were easy.

For more sophisticated things you might need channels for clients to
declare their presence/register with the server.

My main point:  I am not sure this usage of XREP/XREQ + PUB/SUB
qualifies as a "pattern", but, it may be the type of thing you are
looking for.  Thus, I don't think that having patterns promoted to
first class abstractions would help you.

> So my questions are:
> If patterns are not first class building blocks how do I,
> _more_easily/quickly_ 'recognize', using generic/ambiguous
> sockets/device names that 0MQ fits my problem?

I simple started to play with the various sockets types in Python
interactively because it is so easy to use and see exactly what is
going on.  I could have done this with C++, but the edit/compile/run
cycles are painful for exploration.

I would love to hear more about your problem though.



> Otherwise, if patterns are first class building blocks, how do
> generic/ambiguous socket and device names allow me to avoid time and
> effort investigating socket/device features/behaviors not directly
> relevant to my problem?
> Or perhaps I've misunderstood the intent of the changes Pieter has canvassed?
> Mark
>> Pieter, a tutorial with examples is really missing right now so
>> contributing one will be most appreciated. Provided we can find a way to
>> get it into AsciiDoc format we can also bundle a version as e.g. a
>> zmq_tutorial man page with the released tarball.
>> My objective with the API reference is to keep it very much as a
>> comprehensive "dry" reference manual. This would be complemented very well
>> by a good tutorial + cookbook with examples.
>> Patches to the API reference are welcome! The source is in doc/*.txt in
>> Git.
>> I will try to update and clarify the most problematic parts; after all it
>> was written some time ago when we were still deciding on correct
>> terminology for the main concepts with Martin.
>> -mato
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com

More information about the zeromq-dev mailing list