diff options
Diffstat (limited to 'requirements/architecture/ard-011.md')
| -rw-r--r-- | requirements/architecture/ard-011.md | 47 |
1 files changed, 47 insertions, 0 deletions
diff --git a/requirements/architecture/ard-011.md b/requirements/architecture/ard-011.md new file mode 100644 index 0000000..6fb47d3 --- /dev/null +++ b/requirements/architecture/ard-011.md @@ -0,0 +1,47 @@ +# ard-011: Unix sockets for IPC on the server machine + +## Problem + +The architecture already grants that the CRDT sync server, REST API and SMS API +will run on the same machine (ard-008). Given that the REST API and SMS API are +needed for read and write operations on the domain data (see e.g. req-031, +req-047, req-021, req-048), and given that the domain data is stored in an +SQLite file, the REST API and the SMS API need some way of accessing that SQLite +file. + +## Options + +- The CRDT sync server does not run as an independent process + - The APIs access the SQLite file directly using file and SQLite APIs + - The APIs access the SQLite file using a CRDT sync library +- The CRDT sync server runs as an independent process + - The APIs communicate with the CRDT sync server via Unix sockets + - The APIs communicate with the CRDT sync server via Unix pipes + - The APIs communicate with the CRDT sync server via TCP/UDP + - The APIs communicate with the CRDT sync server via files + +## Decision + +The APIs must communicate with the CRDT sync server running as an independent +process via Unix sockets. + +## Discussion + +The option to have the CRDT sync server not running as an independent process +implies that both the SMS API and the REST API will access the same SQLite file +directly. I assume that it is not feasible to have the SMS API and the REST API +run in the same process. It follows that this option implies the possibility of +two processes trying to access the same file at the same time, which is very +risky. That rules out that option. + +Unix pipes work best as one-directional, but we need two-directional +communication, so that rules out that option. + +File-based communication is not great for real-time two-way communications. That +rules out that option. + +There's not a huge amount between Unix sockets and TCP/UDP. But (a) I suspect +that Unix sockets is simpler to implement, (b) I would like to try it out, as I +haven't used Unix sockets before, and (c) Unix sockets is a standard solution +for two-way ICP, and I'm not aware of any special requirements for this case, so +this is therefore good enough. |