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

Dave Quigley dpquigl at davequigley.com
Thu Mar 20 16:44:35 CET 2014


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
>




More information about the zeromq-dev mailing list