1

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?

user3666197
  • 1
  • 6
  • 50
  • 92
kakyo
  • 10,460
  • 14
  • 76
  • 140
  • 1
    Your approach of clients PUSHing to single inproc PULL server is right. – Shishir Pandey Nov 07 '19 at 04:28
  • 1
    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 Nov 07 '19 at 04:35

1 Answers1

0

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.

user3666197
  • 1
  • 6
  • 50
  • 92
  • Thanks for the thorough answer. What I care the most is the received message order. It must be the same order as happened. Clients don't need to confirm the delivery. Performance and other things are not considered here. – kakyo Nov 08 '19 at 00:16