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
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
