2

I am trying to solve the following problem and was wondering what is the best approach to apply?

I'd like to setup a versioned communication via ZeroMQ, which effectively means that any client first makes a handshake stating the version of its messaging protocol and than all subsequent requests are forwarded only to specific set of workers, i.e. the ones which can understand this protocol.

I saw the example of Router/Dealer but there forwarding occurs always to all workers.

IMO this is something like a session, which is established based on handshake and all future requests are made in a particular context. Can this be done with ZeroMQ?

I understand that I can send back some ID to the client and ask it to put in all future requests, but would like to avoid that kind of intrusiveness.

Just a side note: I implement this approach in C++. I don't mind if you answer represents a general idea taking in account features available in either in ZeroMQ C API or cppzmq wrapper. No need to write a fully fledged solution, just how it might be done.

ovanes
  • 5,483
  • 2
  • 34
  • 60

1 Answers1

2

Yes, this seems doable:

With a full respect not to enter into "in-band" signalling via ID/multipart message-processing, one may build the wish-to-have infrastructure using a mix of static and dynamic use of as-is ZeroMQ resources.

Step 0: your central authority handles initial "client" contact / handshaking / identity validation
Step 1: each "client" receives a set of directions, as it's identity/version got approved, based upon 0)
Step 2: ad-hoc instructed "client" may { .connect() | .bind() } with appropriate access-point
Step 3: as an architecture bonus, this can be enjoyed as distributed platform with re-negotiation(s) and node re-discoveries for even more robust, scalable-performance and raised security motivated scenarios

Our own imagination is the only ceiling:

In a few word, one may soon forget about the standard Scalable Formal Communication Patterns, these serve as rather a set of building blocks for ad-hoc defined architectures. That is the biggest power of the ZeroMQ or nanomsg to realise.

enter image description here

May read more on advanced use-cases in this ( and check the book there ... ).

user3666197
  • 1
  • 6
  • 50
  • 92
  • Thanks for your reply! As I properly understand your answer, you suggest to implement a sort of a registry, which after the handshake sends the response which backend is going to serve further requests for that particular version. Do I properly understand the suggestion? – ovanes May 22 '17 at 23:45
  • Yes. Be it a static registry, or an adaptive dispatch ( static/dynamic address:port# mapping, be it latency-, performance-, security- or otherwise-motivated ), the key message is a freedom to design one's own service plane, atop the toolbox elements. – user3666197 May 23 '17 at 00:20