[zeromq-dev] Explicit patterns

Mark V mvyver at gmail.com
Wed Jun 9 00:57:39 CEST 2010


On Fri, May 28, 2010 at 1:13 PM, Brian Granger <ellisonbg at gmail.com> wrote:
> 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.

I certainly appreciate the insights and details you raise. I was
really describing my prior experience with Pieter's pattern
descriptions in, I think, RestMS.
I suppose I thought Pieter's pattern descriptions for ZMQ might reduce
the need for this type of 'problem detail' exchanges for the more
common use cases.
Anyway, I'm not passionate about this. Having cut my messaging
baby-teeth I'll be satisfied with clear documentation of ZMQ sockets
and devices.

Has a decision been reached on having patterns as first class entities?

Cheers
Mark


>
> Cheers,
>
> Brian
>
>> 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