Which bi-directional ZeroMQ pattern should I use for multiple clients connecting to a single server?

Question

I have multiple ( 1000s ) of clients connecting to a single server and sending some log data.

The server analyses the data and responds, if necessary.

PUB/SUB is one directional (monitor example ).
REQ/REP cannot identify the peer and reply specifically to a peer ( it is more for ACK and such only ).

I need to register these clients, identify them and be able to respond after analysis of their logs.

With sockets, I have the client sockets, after accept and I can respond using that socket and the clients can receive on the same socket that I connected to.

I am not finding such a thing in ZeroMQ in my first week of 0mq.

ROUTER socket can print peer's id, but how do I reply to that peer using that id ?

Is there a better way to deal with this?

Answer 1

None of them -- meaning not a single one !
_{. . . rather use more of 'em with some logic on a higher level of abstraction.}

Why ?

Because of Maslow's hammer:

_{“When the only tool you have ( ... want to use )
is a hammer,
every problem begins to resemble a nail.”}

ZeroMQ is a lovely set of fine-tuned building blocks universally equipped ( as per their neutrality as to what transport-class will be used in the final implementation mix ) that is available for re-using 'em inside one's High-Level Logic of the distributed system design & prototyping.

Thus expecting that the very PUB/SUB, PAIR/PAIR or any other Formal Scaleable Communication Archetype Primitive will right match the system requirements is rather missing the core of the benefits, we mortals have received from the genuine Martin SUSTRIK & Pieter HINTJENS' smart messaging Team.

Proposal

One can imagine a following mock-up concept:

using:

• Server .bind()-s and handles one SUB port, known to all clients, that was subscribed well-enough for receiving all "log"-data to process from all id#-hashed clients ( and ignoring any other ingress of data -- even the older versions of the ZeroMQ implemented a SUB-side filtering for the PUB/SUB archetype would allow for this at an acceptable performance load on the server node ). ( Sure, one may object, there may be also other requirements, so as to better handle or avoid completely DDOS-sort of atacks et al, but let's stay trivial in this mock-up )

• client .connect()-s it's PUB role, on-demand, and introduces itself to the Server listening on the SUB-role + moves log-data and either "hangs" or keeps the line silent (a scaling & performance issues ougth be field-tested prior to deciding this group of architecture issues ).

• server may decide to require some ad-hoc conversation with an id#-hashed specific client, but does not want to have an a-priori port publicly exposed by another .bind() associated with a static port#, thus server uses another .connect()-ed role, a PUB, sending ad-hoc a very short, thus having an acceptable footprint of the system-wide associated overhead, signalling, telegramme to the id#-hashed client ( alike a software manner to initiate a port-knocking security behaviour ), telling it where to .connect() to the server and solve the additional tasking et al ( client re-discovery and registration and maintenance is doable this way, so the global scheme meets the stated requirement, not to expose any other port statically exposed to external intruder )

• client has another .bind()-ready SUB role, subscribed to listening to server id#-hashed signalling announcement + setup instructions, what an appropriate client ought .connect()-against-.bind() ( while a reversed .bind()/.connect() scheme requires just a bit extended client re-discovery maintenance ) and upon a server-side signal, such ex-post processing may take place on a separate ( even a one-time used ( a fully disposable ) ) ad-hoc communication infrastructure ( be it an XREQ/XREP or other bilateral Formal Communication Pattern Archetype or some kind of a smarter-mix of several such, intelligently orchestrated ones ), which does not require server to have a statically exposed port but suffice for an ad-hoc server/client request processing.

Not happy with the sketched mock-up? ^{... no doubts, it's so primitive here}

The Best Next Step:

After (cit.:) "my first week of 0mq" the best next step one may do is IMHO to get a bit more global view, which may sound complicated for the first few things one tries to code with ZeroMQ, but if you at least jump to the page 265 of the [Code Connected, Volume 1] [available asPdf >>> http://hintjens.wdfiles.com/local--files/main%3Afiles/cc1pe.pdf ], if it were not the case of reading step-by-step thereto.

The fastest-ever learning-curve would be to have first an un-exposed view on the
Fig.60
Republishing Updates
and
Fig.62 HA Clone Server pair for a possible High-availability approach and then go back to the roots, elements and details.

---

Anyway, enjoy the powers of ZeroMQ
and
might find interesting to read other ZeroMQ-related Q/A-s here >>>