'ZeroMQ pattern for request/response via intermediate server
We're working on a project which requires the following:
- One web server to create user interface for end user;
- Many Raspberry devices, all have internet access;
- One intermediate server for an always-on service, which keep connections with RPi devices.
[1] Web server <=> [1] Intermediate server <=> [0..*] Raspberry Pi
We want the web server to communicate with RPi devices in the request/response manner via the intermediate server using ZeroMQ. The program running in RPi has its own Id string. The requests from the web server also carry the Id of the RPi program it wants to talk with. The intermediate server will see the Id of the RPi and forward the request to that connection. When receiving the response from RPi, the intermediate server will send the message back to the web server. Please recommend a suited pattern in ZeroMQ to this problem. Thank you very much!
Solution 1:[1]
Q : "... pattern for request/response via intermediate server"
A :
Kindly be warned, that the key problem is not in re-using a read-made ZeroMQ pattern, as there problems you also have to solve, that go way beyond of what the ZeroMQ-native patterns covers ( a deadlock-avoidance, a mutual live-lock avoidance, a lost-agent handling robust enough to permit for lost-forever-agent ).
The as-is REQ/REP
would be the most dangerous pattern to deploy for doing this ( see many posts on un-salvageable deadlock the REQ/REP
dFSA is sure to fail into ).
Given your scheme, you can easily off-load the logic from ZeroMQ layer and use the simplest archetypes that meet the needs.
Using, for example, a set of PUSH/PULL
-relations, one for application-driven agent-to-intermediary telemetry ( intial-RPi-welcome, continuous-RPi-keepalives, RPI-health-telemetry and likes ), another one for agent-DATA transfers, can help you design signalling-and-messaging meta-plane that meets your system-wide robustness needs.
Using one, complicated, deadlock-prone pattern will never solve all that at one shot.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
Solution | Source |
---|---|
Solution 1 | user3666197 |