I’m using PyZMQ to create a request/reply server, and I’m trying to figure out if the act of creating a thread for each new client connection is handled by PyZMQ automatically. Ultimately, I’m trying to figure out if a request from one client that takes a long time to reply to will block requests from all other clients.
Normally, I would call accept on a Python socket instance, block until a new connection is made, and handle any new connections in separate threads. However, PyZMQ sockets do not seem to support such a workflow. So, how is this handled in PyZMQ? If a PyZMQ REP socket has multiple clients connected to it, how does it go about correctly routing replies back to the clients that made the requests? And, how can I go about designing my code such that requests from other clients aren’t blocked when a client makes a long-running request?
I know I could use the Tornado-based EventLoop provided with PyZMQ, I’m just trying to better understand how it would work if that weren’t an option.
ZeroMQ exposed as “sockets on steroids”, but there is another approach for implementing a communciation.
First of all, forget about wire that links peers in traditional sockets. In 0mq, you have a “quantum teleporter”, which delivers your messages from one piece of code to another, hiding actual delivery work from you. You can’t just ask 0mq how many clients are connected to the socket or if you have clients at all. ZeroMQ cannot be used as a drop-in replacement for sockets because of that.
Instead, 0mq gives you a magician hat you take some white rabbits from. Imagine that bottom of that hat connected with a gigantic network of pipes with multiple factories of wonderful things on the other side. These factories sometimes send some stuff to your hat, and when you get from the hat you can find yourself with a rabbit in your hands, or bouquet of flowers or something other. You cannot determine from what factory that thing had been sent unless there was an explicit sticker on that thing (i.e. one part of multipart message points to origin of the message).
After you take the rabbit from the hat, you may want to send something back, and 0mq will behave differently for different socket types. For REP sockets, it will send answer directly to origin of message, for DEALER will round robin answers across connected peers, and ROUTER gives you immense knowledge of exact internal address of peer when receiving message and allows you to set explicit destination while sending message.
To sum it up, if you want a separate thread for each communicating client you need the following things:
This is a way to implement “multi-client socket server on zeromq” with classic socket knowledge in mind.
But it is not a 0mq approach for the problem.
In 0mq you can just put your processing logic in one thread (dispatcher from the example above) and implement it as a loop
receive request -> process -> send answer -> receive .... Fits perfectly when processing time is not a question. But when it is, 0mq-style solution involves task-queue broker between clients and workers (which perform actual work). And then, broker logic is a little more complicated than a receive-answer loop mentioned above, and the worker is implemented in the same way. See examples in zguide – A Request-Reply Message Broker