## 2 Literature Review  
Parallel and distributed simulation refers to technologies that enable a simulation model to execute on multiple processors [4]. Its benefit includes reduced execution time, larger model scale, and integration with other simulators [5; 6; 7]. Parallel and distributed simulations can be distinguished by the geographical distribution, the composition of the processors used, and the network to interconnect the processors. While the processors in a parallel simulation are homogeneous machines and located in close physical proximity, the processors in distributed simulation are often composed of heterogeneous machines that may be geographically distributed (Table 1). For communication between processors, parallel simulation uses customized interconnection switches and distributed simulation uses widely accepted telecommunication standards including LAN (Local Area Network) and WAN (Wide Area Network) [4]. \begin{table}
\begin{tabular}{c c c} \hline \hline  & **Parallel** & **Distributed** \\ \hline Physical Extent & Machine room & Single building to global \\ Processors & Homogeneous & Often heterogeneous \\ Communication Network & Customized switch & Commercial LAN or WAN \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Parallel and distributed computing [4]. When a simulation program is distributed over multiple processors in parallel and distributed simulation, several _LPs_ (logical processes) execute simulations concurrently. In such simulations time stamp ordered processing is not guaranteed, as in a sequential execution on a single machine. Errors resulting from out-of-order processing are referred as causality errors. Out-of-order execution must be prevented to ensure the parallel and distributed simulation produces the same results as a sequential execution. To avoid causality errors, synchronization algorithms are required which refer to the coordination of simulation processes in a time stamp order to complete a task. Under the synchronization algorithms, _LPs_ execute simulations while obeying a rule known as Local Causality Constraint (LCC). Two different synchronization approaches have been proposed to satisfy the local causality constraint, conservative execution, and optimistic execution [4; 5; 6; 7; 8; 9; 10; 11; 12]. LPs in conservative synchronization protocols strictly avoid violating LCC. Each LP only advances when it is safe to proceed after satisfying LCC. However, optimistic algorithms assume \"optimistically\" that there are no causality errors and allow LPs to process asynchronously. LCC violation can occur, since optimistic execution does not determine when it is safe to proceed for each LP. Instead, when a causality error is detected, a mechanism to recover is provided in the optimistic approach. Once a causality error is detected simulation states prior to the causal violation are recalled and the simulation is executed forward from that state, with the LCC violation corrected. The operation of recovering a previous state is known as a rollback and this recovering process requires state-saving and anti-message. State-saving stores state variables values prior to an event computation. Two widely used techniques for state-saving are Copy state-saving and Incremental state-saving. Copy state-saving creates an entire copy of the modifiable state variables, whereas Incremental state-saving records (1) the address of the state variables that was modified and (2) the value of the state variable prior to the modification. If a small number of state variables are changed, incremental state-saving is more efficient, reducing the time and memory overheads. However, incremental state-saving does not perform well when most of the state variables are modified by each event. Infrequent state-saving is an alternative to reduce the overheads by decreasing frequency of LP state-saving [13]. When a rollback event happens, the simulation state being rolled back may have sent messages which are not consistent with the rolled back state.