1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
|
# ard-011: Unix sockets for IPC on the server machine
Satisfied by: task-018, task-019
## 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.
|
