1

I'm struggling with the following problem:

I'd like to make bidirectional asynchronous requests/replies between N clients and 1 server with ZeroMQ.

This means that any client can make a request to the server and the server must reply to the client.

In the other way, the server must be able to make a request to any of the identified clients and the client to reply to the server.

I think I must use routers/dealers, but I'm not sure I need them in both ways.

Moreover, is there a way to have this whole paradigm using only one port on the server side and on each client side?

enter image description here

Benjamin Barrois
  • 2,566
  • 13
  • 30

1 Answers1

0

Q: is there a way to have this using only one port on the server / client side?

Well, this is the simpler part. No, this is not achievable. Having just one telephone box in the college will ring in the hallway, but will never help to address a call to the required department ( it would not correctly reach the intended professor of Quantum Mechanics instead of the one in Fine Arts ).

Using but one port means having a chance to expose for public access a one and only one ZeroMQ Scalable Formal Communication Pattern Archetype AccessPoint and ( except the very specific PAIR/PAIR distributed behaviour Archetype ) there is always some kind of hard-wired distributed-behaviour of the interconnected agents' AccessPoint-s.

This means, using one port gives just one and only one kind of such distributed-behaviour, not a mix of them.

This also answers your first part. If a REQ/REP distributed-behaviour Archetype was used in a direction from client-nodes towards the server, and another REQ/REP distributed-behaviour Archetype was to be used in an opposite direction from server towards the client-nodes, these ( directed ) services cannot co-exist on the same address:port.

BONUS PART : A kind of Life-Saving, but a bit dirty Trick
( Not to be used for Medical and/or Emergency Systems )

one may sort of supersample one and only one of the REQ/REP messaging directions and add a tricky "quasi-protocol" so as to serve this same channel for the both intended signalling directions. If sending sufficiently enough protocol-messages from one side, be it { client | server } the REQ/REP message initiator will simply send NOP-messages often enough to permit the REP-side replying party to "quasi-initiate" its "quasi-REQ-message" when still being the authentic-REP-AccessPoint in the single REQ/REP distributed-behaivour Archetype.
Yes, performance and resources use are a cost for doing this, but a careful soft-real-time system design practices will help to make this work, if your needs are extremely dependent on using but one port and if your consciousness and your deployment ecosystem may tolerate the increased traffic patterns of such supersampled-REQ/REP data-flows

You might also like posts, here on Stack Overflow, about unavoidable mutual deadlocks, the distributed REQ/REQ FSA-s will fall into.

ZeroMQ hierarchy explained in less than a five seconds

UN-AVOIDABLE DEADLOCKS

halfer
  • 19,824
  • 17
  • 99
  • 186
user3666197
  • 1
  • 6
  • 50
  • 92