## 4 Multiprocessing: Models and Architectures
### Communication, Synchronization, and Data Sharing
\begin{table}
\begin{tabular}{c c c c c} \hline \hline
**Host** & **Matrix** & **Data (Bytes)**\(\times N\) & **RXTX (Bytes)** & **OF** \\ \hline HPG3-WS/CFLX3-WB & 2 \(\times\) 2 & (30 + 80) \(\times\) 500,000 & 66,309,928 & 1.21 (1.65) \\ HPG3-WS/CFLX3-WB & 10 \(\times\) 10 & (30 + 1955) \(\times\) 20,000 & 42,468,779 & 1.07 (1.09) \\ HPG3-WS/CFLX3-WB & 1000 \(\times\) 100 & (30 + 1,929,253) \(\times\) 20 & 40,784,371 & 1.06 (1.06) \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Communication overhead for TCP-WebSocket channels by sending serialized matrix data (initialized with random numbers) between a shell worker and a WorkBook. The raw network RX-TX data load was measured by and collected from the LAN device. Overhead factor OF in parenthesis: pure payload. Figure 3: Different communication methods are used to connect the cluster nodes and their worker processes. The Web Service port is used for remote worker control. Channel- and stream-based WebSocket communication relies on a state-based connection using TCP between both communication endpoints. That is, any temporary network failure or transmission disturbance can result in a permanent disconnect of the communication channel. A WebSocket channel is provided by an upgrade process over an HTTP(S) connection. After a disconnect, this upgrade has to be performed again. This state-based communication is a limiting factor in the design of distributed systems and in the access of remote-worker processes. Shell workers created via the WorkShell Web service are automatically terminated if there is a disconnect from the master process (e.g., a WorkBook session). All data and computation of this worker are lost permanently. To overcome this limitation, there are three solutions:  
1. Using state- and connectionless communication via UDP/WebRTC;
2. Workers (or the WorkerShell Web service) can be kind and tolerate temporary connection loss, and wait for a reconnect;
3. A persistent snapshot by check-pointing the worker state using secondary storage. Solution (1) is not suitable for distributed systems. The communication channels are used for master-worker synchronization. UDP is not reliable; there is no information if the other communication endpoint is still alive and, therefore, synchronization over such unreliable channels is not free from deadlocks and there is no starvation freedom. Solution (2) shifts the problem only temporarily, but this is the most suitable method, while solution (3) results in high communication overhead. Moreover, the state of a JS execution context cannot be dumped fully (free variables cannot be resolved programmatically), but long-running tasks should explicitly dump their intermediate results to enable the reincarnation of a crashed worker process. For example, in ML training, the iteratively trained model is serialized and is saved periodically. Our distributed SQL data base can be a valuable storage point. At any particular moment, this time-consuming training process can be restarted from the last snapshot. Finally, Example 3 shows some WorkBook/WorkShell operations to perform synchronous master-worker communication and synchronous RPC execution. // Create worker with RPC var worker = new Worker(  rpc : {  function foo (x) { return x*x }  } ) // In worker process var ma = Math.Matrix.Random(10,10),  mas = serialize(ma.data);