[zeromq-dev] Unsure of the best topology

Kieran Evans keyz182 at gmail.com
Thu Oct 3 12:04:40 CEST 2013


Hi Artem,

Sorry, I think I was unclear. All the workers are identical, I just 
meant that currently, if I were to add a new method to the REST API 
exposed by the Workers, I'd have to add that call to the public end 
point, and the proxy too, whereas all they really need to do is pass a 
message.

I'm currently looking through examples, mainly with pyZQM for now.

I got this (https://gist.github.com/keyz182/6807542) hacked together 
from examples, and it seems to do what I want.

queue_client.py would run inside the NAT.
queue_device_left.py also runs inside the NAT but can connect externally.
queue_device_right.py is exposed publicly.
queue_server.py connects to queue_device_right.py and handles requests.

Does this seem sensible?

To me it appears to be exactly what I want, but before I embark on a 
rather large refactoring effort, I just want to get some expert opinion 
to tell me "Looks good" or "MY EYES! Give up programming before you hurt 
someone!".
Though preferably not to that extreme :P

Thanks,
/Kieran


On 02/10/2013 17:31, Artem Vysochyn wrote:
> Hi Kieran,
>
> >>>/The way it's done currently means that if we add new functionality, it
> />>>/has to be replicated at all points, rather than a ZMQ solution, where
> />>>/just at the client and worker would be aware of the message format,
> />>>/everything in between would just be for moving messages.
> /
> I would recommend you looking at LRU mechanism which zmq allows to
> build very cheaply by yourself.
> You said you add new functionality and don't want it to be replicated
> on every worker. Ok, so in this case you have
> clients which have to go via "old route" and via "new route".
> Correct? If so, then client(s) and worker(s) have to be
> "identifyable"/"recognizable", which
> would allow you to make assertions in the code, like if
> "client-1.0.14" then go to "worker-1.3.17".
>
> So, essentially, you should know next things:
> - what's DEALER
> - what's ROUTER
> - what's a "device"
> - why ROUTER/DEALER device is cool, but ROUTER/ROUTER is a "rock star"
> - what's socket identity
>
>
> -artemv

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


More information about the zeromq-dev mailing list