[zeromq-dev] Proper place to ask about architecting programs with zmq

Laurent Alebarde l.alebarde at free.fr
Thu Mar 20 17:25:04 CET 2014


If your middleware it trusted, you can just use libzmq/CURVE between 
clients and the portion of the middleware that has high security 
posture, and libzmq/NULL between middleware that has low security 
posture and your broker, and also NULL between the broker and the 
agents. Then you don't need libcurve.

But without a diagram, I am not sure to understand your architecture.

As far as I know, libcurve does not have any bindings.

Le 20/03/2014 16:44, Dave Quigley a écrit :
> Well the middleware is trusted. The idea is that one portion has a high
> security posture while the other has a low security posture and the
> middleware mediates messages across that boundary. I had an idea of
> taking the message off the broker wrapping it in the middleware message
> and sending it across the boundary and unwrapping the replies and
> sending them back. However I'm not sure if I have to do some of the
> stuff mentioned in the advanced rep/req section and handle the frames
> instead of entire messages. There is a lot of good information in the
> guide so its taking a while to internalize it all. I need to find out if
> there are python bindings for the libcurve stuff.
>
> Dave
>
> On 3/20/2014 9:31 AM, Laurent Alebarde wrote:
>> If you have to go through untrusted nodes, then you need libcurve on top
>> of libzmq. You cannot use CURVE inside libzmq since it does not permit
>> proxying as is. Though I have managed to do it with the help of
>> ZMQ_STREAM, it is heavy and I finally prefer putting security on top of
>> libzmq.
>>
>> As your middleware is untrusted, it should not be used to dispatch the
>> jobs. I would allow it only for minimal proxying. Then, I suggest you
>> keep your first idea of a broker/dealer server with agents in the
>> trusted area.
>>
>> Keep in mind that using libcurve or libzmq/CURVE through proxy requires
>> being statefull. So your broker shall perform sticky pairing between
>> clients and agents. If you cannot aford being stateful, you have to
>> consider other security solutions.
>>
>>
>> Le 20/03/2014 14:01, Dave Quigley a écrit :
>>> I read through the guide so I have some idea of what I need to get the
>>> job done. Unfortunately I'm having some odd middle ware being pushed on
>>> me so its not as straight forward as I had originally planned. I
>>> originally have a client using a req/rep socket to a management server
>>> which would use a broker/dealer socket pair to pass the messages along
>>> to the local portion of the management agents. However now I'm told that
>>> I have a hard separation between components sitting in a
>>> trusted/privileged zone vs untrusted zone and I have to use their
>>> middleware messaging system to communicate across that boundary. However
>>> I still want to use zmq from the client to the trusted management
>>> component and then from the untrusted management component to the local
>>> servers it starts for interacting with the remote agents. I'm not sure
>>> if I need the broker/dealer pairs for that anymore or if I make the
>>> components on each side of the middleware just be normal servers that
>>> are reponsible for proxying the requests through the middleware.
>>> Unfortunately this middleware makes it go from a clear cut picture to
>>> very murky waters.
>>>
>>> Dave
>>>
>>> On 3/20/2014 6:04 AM, Laurent Alebarde wrote:
>>>> My two cents:
>>>>
>>>> Do architect your system roughly, then perform minimal tests of the
>>>> library features you expect to use, consider what's available in a
>>>> second choice library, then abstract what's useful for you in the
>>>> library of your choice in a layer of your own, keeping the second choice
>>>> in mind, for easier move and independence. Build your system with an
>>>> iterative process, refining your design and adding features, but the
>>>> main ones shall be in the architecture at the very beginning, or you
>>>> will have to iterate from scratch several times or end with a spaghetti
>>>> code.
>>>>
>>>> It is not the opposite of Pieter's bottom-up advice, but a top-down and
>>>> bottom-up approach in an iteration process.
>>>>
>>>> But none of us have answered your question. As far as I know, this list
>>>> is the only one. But as Pieter points it out, reading the Guide is a
>>>> very good mandatory start.
>>>>
>>>> Laurent
>>>>
>>>> Le 20/03/2014 08:45, Pieter Hintjens a écrit :
>>>>> Hi Dave,
>>>>>
>>>>> For the most part, reading the Guide and learning ZeroMQ by working
>>>>> through various examples will teach you everything you need. There is
>>>>> some general advice: don't architect systems, then build them. Rather,
>>>>> start with minimal end-to-end proofs of concept, then work them out
>>>>> incrementally.
>>>>>
>>>>> -Pieter
>>>>>
>>>>>
>>>>> On Thu, Mar 20, 2014 at 6:24 AM, Dave Quigley<dpquigl at davequigley.com>   wrote:
>>>>>> I'm working on developing a framework for management and tasking of
>>>>>> remote administration agents. I've chozen zmq as my messaging library
>>>>>> since it is lean and gives me an abstraction that I like. Is this the
>>>>>> right place to ask about how I'm architecting the system or is there a
>>>>>> better venue? The freenode channel is pretty quiet and I've noticed this
>>>>>> list is mostly questions about c/c++. I'm currently using pyzmq just as
>>>>>> a way to quickly prototype something with the hopes of transitioning it
>>>>>> over to C when I figure everything out.
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>> _______________________________________________
>> 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

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


More information about the zeromq-dev mailing list