CODEWITHSUNDEEP
csocketszeromq
McPhie
McPhie

Reputation: 25

ZeroMQ - Send and receive multiple messages to a client before accepting new client from queue

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

Upvotes: 1

Views: 1366

Answers (1)

user3666197
user3666197

Reputation: 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)

Upvotes: 1

Related Questions