ZeroMQ: Recommended pattern for inproc clients from multiple threads pushing ordered messages to a server?

1
votes

My requirements

  • Clients from different threads in the same process
  • Server in a separate thread in the same process
  • Clients produces messages to Server
  • Server consumes messages by printing them out in the send-order by world clock on the source side, transparent to threading and any scheduling.

Answers to questions like

give different opinions. So should I simply ask clients to PUSH to a single inproc PULL server created in another thread or use a router-dealer pattern?

And in one of the comments of the second question, I get STREAMER pattern that seems to exist in pyzmq, but I'm not sure if it's the right solution or is it available with C API at all?

1
multithreadingdesign-patternszeromqdistributed-systempyzmq
Your approach of clients PUSHing to single inproc PULL server is right. – Shishir Pandey
pyzmq adds more things on top of the base libzmq library. I looked at the streamer mentioned, it is just a pattern not a basic socket provided by zmq and is used when you want to distribute the message to many servers. – Shishir Pandey

1 Answers

0
votes

Q : Recommended pattern for inproc clients from multiple threads pushing ordered messages to a server?

Any answer to such formulated question is dependent on a missing piece of information: what is the set o preferences, that lead to distinguish between insufficient, sufficient, better and best solution to the above described operations.

Do you need a confimatory feedback from server to client as there is Zero-Warranty for a message delivery?

Do you need to handle a static or a dynamic set of clients?

Do you prefer performance to RAM-footprint?

Without any of these "criteria" expressed a serious man would never "recommend", as any such statement would be a just opinion.

PUSH/PULL may suffice for unconfirmed delivery ( an optimistic blindness use-case, if an out-of-sight out-of-mind design philosophy is acceptable in production )

PAIR/PAIR may suffice for a fast .poll( ZeroWait, ZMQ_POLLIN ) server-side scanner, with server-side POSACK-responses being possible to dispatch to respective client-threads, whose messages were delivered and accepted for server-side processing ( user-defined message-confirmation handshaking protocol, handling POSACKs / NACK-timeouts / out-of-order escallations etc, goes beyond the scope of this post )

PUB/SUB or XPUB/XSUB may suffice for some more tricky management of topic-based signalling, bidirectional in the X-versions, if that justifies the add-on costs of topic-filtering overheads ( depending on ZeroMQ version, whether distributed over all client-threads, or centralised on the server-thread side )

The decision is yours.