1

Is it possible to utilise ZeroMQ with a Request-Reply style architecture where the server accepts an initial message from a client and then exclusively talks to that client until it has done all it needs to do? With a standard socket this is easily achieved as a new socket is created when the server accepts a client connection. Is there an approach I could implement in ZeroMQ that would give the same result whilst gaining the large queue handling capabilities?

This follows on from my previous query where my initial question was too open. My situation involves potentially thousands of clients all talking to the server at the same time in an attempt to attest and be issued a key to decrypt a library. The attestation process has multiple challenge-response style checks. This server cannot be threaded as the key provisioning is not threadsafe as it utilises an Intel SGX enclave.

ZeroMQ - Emulating standard socket for multiple clients to one server

McPhie
  • 25
  • 5

1 Answers1

1

Let's imagine a solution like this:

1 ) Client No.[1~10000] calls REQ.send() to request a reply from Attestation-server

2 ) Attestation-server in an infinite loop REP.poll( 0, ZMQ_POLLIN )-s to detect any new request arrival and if any present in the incoming-queue, it REP.recv()-s the next request-to-reply

3 ) upon the Attestation-server's decision, it may, yet need not, deliver a meaningful or meaningless response to the Client, who asked for attestation and prepares and sets a new server-side AccessPoint for "Out-of-Band"-private-channel communication as requested above. A pool-of-one-time-used AccessPoints or a rotating-pool ( where feasible and safe ) of connection-ready AccessPoints may help reduce any latency for this phase down to almost zero add-on setup-time.

4 ) Client, be it a POSACK'd or a NACK'd one, REQ.recv()-s a reply from the Attestation-server, which in case it was POSACK-attested contains a new AccessPoint definition ( a full set of transport-class specification, an address specification, a port specification (if meaningfull for the given transport-class ) ). The NACK'd cases shall be directed so as not to deteriorate any of the Attestation-server resources ( one element of the set of protection policies to better isolate the Attestation-server from willfully organised massive overloads and other sorts of DDoS attacks )

5 ) It is the Client's turn to try to .connect() a new private-channel to the Attestation-server proposed AccessPoint, at which it may fail to succeed, if it was NACK'd during any of the attestation-policy checks and directed to some sand-box target(s) if needed to cope in more detail the nature and the evolution of dynamics of the flow of the mix of NACK's and attack attempts.

6 ) POSACK'd Client(s) will keep conversation(s) in private channel(s) of whatever Archetype(s) and orchestration, so the tools for finishing the attestation process with the Attestation-server remain at the server's will and pace.

There are many other ZeroMQ feature that may get involved - per-channel encryption, whitelisting / blacklisting, other ISO/OSI-L2/L3/L4/L5/L7 configuration options, so as to improve the robustness of the Attestation-server's service provisioning.

EPILOGUE ( ... and a bit of late legal disclaimer ) :

Hope I did not just shortcut all the R&D of design & fabrication of the SGX-silicon just by opening a Pandora box of smart distributed-behaviour Troyan archetypes

:o)

user3666197
  • 1
  • 6
  • 50
  • 92
  • Will this all be possible through 1 port when using TCP, or would the private channels have to be on a separate one to the initial attestation request? Also reading the guidance they state that "In some cases socket handles won't be freed until you destroy the context" so I'm guessing it would be better to reuse the secondary sockets rather than rely on creating a new one each time? – McPhie Sep 05 '19 at 10:08
  • An attempt to `.bind()` a second AccessPoint onto a `port#`, where some other one has succeeded will for obvious reasons fail. The rest is driven more by security and performance than by an opinion or technical rationale. – user3666197 Sep 05 '19 at 12:06
  • How would you go about setting up one of these private channels? I started to code something just by setting up another TCP socket on a different port but then thought how could you ensure it was only used by the desired client, and not get unwanted messages either from other clients or even a malicious actor? – McPhie Sep 05 '19 at 12:41
  • Feel free to appreciate the provided solution for your original question and accept the best answer provided. Everyone is free to open another question on new subjects. StackOverflow is not a software consulting herd available for free and unlimited design coaching or architecture mentoring site. – user3666197 Sep 05 '19 at 13:44