## 4 Multiprocessing: Models and Architectures
### Communication, Synchronization, and Data Sharing  
Processes (either the WorkBook or WorkShell main loop, and web or shell worker) can communicate and synchronize by using either message-based communication \(M\) or shared memory \(S\), as shown in Figure 3:  
1. Native messages \(M_{\text{native}}\) provided by the browser or by the node.js platform; these can only be used within the same process class and by a parent-worker process group on the same node \(\rightarrow\) synchronization and data transport. 2. WebSocket messages \(M_{\text{ws}}\) can be used between all process classes and different nodes \(\rightarrow\) Synchronization and data transport. 3. Shared memory segments \(S_{\text{sms}}\) (SMS), implemented either with shared array-buffers in the browser or with native externally mapped shared memory at system-level in node.js; these can only be used within the same process class and on the same node \(\rightarrow\) data sharing without data-driven synchronization. 4. Shared buffer objects (BO) \(S_{\text{smo}}\) are implemented in SMS with static typing, supporting atomic core variables, structure variables, and arrays \(\rightarrow\) data sharing without data-driven synchronization. 5. A shared matrix \(S_{\text{sma}}\) implemented by shared memory and object-wrapper replications; these can only be used within the same process class \(\rightarrow\) data sharing without data-driven synchronization. 6. Queued and synchronized data channels \(M_{\text{ch}}\) built on native streams, Unix or WebSocket messaging, using (1/2), or shared memory (4). 7. Remote procedure calls over message channels. A combination of \(M\) and \(S\) methods can be used for efficient inter-process communication in typical numerical, simulation, and machine learning tasks. Bidirectional master-worker communication is performed by message-based channels, using _send_ and _receive_ operations on message channels. Additionally, a worker process can perform asynchronous (event streams) to synchronous remote procedure calls in the master process. Worker-worker synchronization (limited to the same worker class and the same host) can be established with Atomics-based operations on shared array buffers, implementing the following IPC objects:  
1. Mutex;
2. Semaphore;
3. Barrier;
4. Data Queues. Local workers (instantiated from the same parent process) communicate via UNIX sockets or data pipes. Remote workers (or those not instantiated from the same parent process) communicate via HTTP WebSocket (WS) channels. The protocol overhead of TCP-based WS channels is relatively low (except for the upgrade protocol), being below 5-10% depending on the payload size per message transfer, as shown in Table 1. The constant message overhead (JSON format) is always 30 Bytes. In the case of very small payload data, the overhead increases (about 20% for 80 bytes/message, or 65% if considering the pure payload only). The advantage of WS channels over other more efficient protocols is the capability to connect web browser processes with remote shell-worker processes (and by using a proxy server for web worker-web worker communication). This is a key feature for the deployment of distributed heterogeneous systems. A theoretical discussion of the protocol overhead of WebSocket connections can be found in [25]. Examples of bandwidth and message latency measurements for local worker process communication (typically via UNIX sockets or pipes) are shown in Table 2. The node.js platform provides low-latency and high-bandwidth communication. The current Chromium browsers offer very high bandwidth and very low latency for master-worker communication.