Update content for html

author: Paul Buetow <paul@buetow.org> 2026-03-30 09:17:13 +0300
committer: Paul Buetow <paul@buetow.org> 2026-03-30 09:17:13 +0300
commit: ae6b3fde6d2ef130e2bb18dd2c6ee040687b143d (patch)
tree: f2b831df9f1377cf0579496e7e82a46472c81d5d /gemfeed
parent: 39b002074e735808daafa3b7f1fe960c9ab603b2 (diff)
6 files changed, 2017 insertions, 2074 deletions
diff --git a/gemfeed/2026-03-31-distributed-systems-simulator-part-1.html b/gemfeed/2026-03-31-distributed-systems-simulator-part-1.html
new file mode 100644
index 00000000..32fbf075
--- /dev/null
+++ b/gemfeed/2026-03-31-distributed-systems-simulator-part-1.html
@@ -0,0 +1,323 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+<title>Distributed Systems Simulator - Part 1: Introduction and GUI</title>
+<link rel="shortcut icon" type="image/gif" href="/favicon.ico" />
+<link rel="stylesheet" href="../style.css" />
+<link rel="stylesheet" href="style-override.css" />
+</head>
+<body>
+<p class="header">
+<a href="https://foo.zone">Home</a> | <a href="https://codeberg.org/snonux/foo.zone/src/branch/content-md/gemfeed/2026-03-31-distributed-systems-simulator-part-1.md">Markdown</a> | <a href="gemini://foo.zone/gemfeed/2026-03-31-distributed-systems-simulator-part-1.gmi">Gemini</a>
+</p>
+<h1 style='display: inline' id='distributed-systems-simulator---part-1-introduction-and-gui'>Distributed Systems Simulator - Part 1: Introduction and GUI</h1><br />
+<br />
+<span class='quote'>Published at 2026-03-31T00:00:00+03:00</span><br />
+<br />
+<span>This is the first blog post of the Distributed Systems Simulator series, written for the recent v1.1.0 release. It explores the Java-based Distributed Systems Simulator program I created as my diploma thesis at the Aachen University of Applied Sciences (August 2008). The simulator offers both built-in implementations of common distributed systems algorithms and an extensible framework that allows researchers and practitioners to implement and test their own custom protocols within the simulation environment.</span><br />
+<br />
+<a class='textlink' href='https://codeberg.org/snonux/ds-sim'>ds-sim on Codeberg (modernized, English-translated version)</a><br />
+<br />
+<span>These are all the posts of this series:</span><br />
+<br />
+<a class='textlink' href='./2026-03-31-distributed-systems-simulator-part-1.html'>2026-03-31 Distributed Systems Simulator - Part 1: Introduction and GUI (You are currently reading this)</a><br />
+<a class='textlink' href='./2026-04-01-distributed-systems-simulator-part-2.html'>2026-04-01 Distributed Systems Simulator - Part 2: Built-in Protocols</a><br />
+<a class='textlink' href='./2026-04-02-distributed-systems-simulator-part-3.html'>2026-04-02 Distributed Systems Simulator - Part 3: Advanced Examples and Protocol API</a><br />
+<br />
+<a href='./distributed-systems-simulator/ds-sim-screenshot.png'><img alt='Screenshot: The Distributed Systems Simulator running a Broadcast protocol simulation with 6 processes. The visualization shows message lines between process bars, with blue indicating delivered messages and green indicating messages still in transit.' title='Screenshot: The Distributed Systems Simulator running a Broadcast protocol simulation with 6 processes. The visualization shows message lines between process bars, with blue indicating delivered messages and green indicating messages still in transit.' src='./distributed-systems-simulator/ds-sim-screenshot.png' /></a><br />
+<br />
+<h2 style='display: inline' id='table-of-contents'>Table of Contents</h2><br />
+<br />
+<ul>
+<li><a href='#distributed-systems-simulator---part-1-introduction-and-gui'>Distributed Systems Simulator - Part 1: Introduction and GUI</a></li>
+<li>⇢ <a href='#motivation'>Motivation</a></li>
+<li>⇢ <a href='#installation'>Installation</a></li>
+<li>⇢ <a href='#fundamentals'>Fundamentals</a></li>
+<li>⇢ ⇢ <a href='#clientserver-model'>Client/Server Model</a></li>
+<li>⇢ ⇢ <a href='#processes-and-their-roles'>Processes and Their Roles</a></li>
+<li>⇢ ⇢ <a href='#messages'>Messages</a></li>
+<li>⇢ ⇢ <a href='#local-and-global-clocks'>Local and Global Clocks</a></li>
+<li>⇢ ⇢ <a href='#events'>Events</a></li>
+<li>⇢ ⇢ <a href='#protocols'>Protocols</a></li>
+<li>⇢ <a href='#graphical-user-interface-gui'>Graphical User Interface (GUI)</a></li>
+<li>⇢ ⇢ <a href='#simple-mode'>Simple Mode</a></li>
+<li>⇢ ⇢ <a href='#the-menu-bar'>The Menu Bar</a></li>
+<li>⇢ ⇢ <a href='#the-toolbar'>The Toolbar</a></li>
+<li>⇢ ⇢ <a href='#the-visualization'>The Visualization</a></li>
+<li>⇢ ⇢ <a href='#color-differentiation'>Color Differentiation</a></li>
+<li>⇢ ⇢ <a href='#the-sidebar'>The Sidebar</a></li>
+<li>⇢ ⇢ <a href='#the-log-window'>The Log Window</a></li>
+<li>⇢ ⇢ <a href='#expert-mode'>Expert Mode</a></li>
+<li>⇢ ⇢ <a href='#configuration-settings'>Configuration Settings</a></li>
+</ul><br />
+<h2 style='display: inline' id='motivation'>Motivation</h2><br />
+<br />
+<span>Distributed systems are complex—interactions between nodes, network partitions, failure scenarios are hard to debug in production. A simulator lets you experiment with architectures, observe how systems behave under failure, and learn consensus algorithms, replication strategies, and fault tolerance in a controlled, repeatable environment. No operational overhead, no real infrastructure—just focused exploration of system design.</span><br />
+<br />
+<span>In the literature, one can find many different definitions of a distributed system. Many of these definitions differ from each other, making it difficult to find a single definition that stands alone as the correct one. Andrew Tanenbaum and Maarten van Steen chose the following loose characterization for describing a distributed system:</span><br />
+<br />
+<span class='quote'>"A distributed system is a collection of independent computers that appears to its users as a single coherent system" - Andrew Tanenbaum</span><br />
+<br />
+<span>The user only needs to interact with the local computer in front of them, while the software of the local computer ensures smooth communication with the other participating computers in the distributed system.</span><br />
+<br />
+<span>This thesis aims to make distributed systems easier to understand from a different angle. Instead of the end-user perspective, it focuses on the functional methods of protocols and their processes, making all relevant events of a distributed system transparent.</span><br />
+<br />
+<span>To achieve this, I developed a simulator, particularly for teaching and learning at the University of Applied Sciences Aachen. Protocols from distributed systems with their most important influencing factors can be replicated through simulations. At the same time, there&#39;s room for personal experiments—no restriction to a fixed number of protocols. Users can design their own.</span><br />
+<br />
+<span>The original simulator (VS-Sim) was written in Java 6 in 2008 with a German-language UI. In 2025, I revamped and modernized it as ds-sim: translated the entire codebase and UI from German to English, migrated the build system from hand-rolled Ant scripts to Maven, upgraded from Java 6 to Java 21 (adopting sealed class hierarchies, record types, formatted strings, pattern matching), introduced a proper exception hierarchy and consistent error handling, added comprehensive Javadoc documentation, implemented a headless testing framework (208 unit tests covering core components, the event system, and all protocol implementations), reorganized the project structure to follow standard Maven conventions, and added architecture documentation. Total: 199 files, over 15,000 lines of new code. Back in 2008, I wrote every line by hand in Vim. For the 2025 modernization, Claude Code did most of the heavy lifting—translation, refactoring, test generation, documentation. Times have changed.</span><br />
+<br />
+<h2 style='display: inline' id='installation'>Installation</h2><br />
+<br />
+<span>The modernized ds-sim requires Java 21 or higher and Maven 3.8 or higher.</span><br />
+<br />
+<pre>
+# Clone the repository
+git clone https://codeberg.org/snonux/ds-sim.git
+cd ds-sim
+
+# Set JAVA_HOME if needed (e.g. on Fedora Linux)
+export JAVA_HOME=/usr/lib/jvm/java-21-openjdk
+
+# Build the project
+mvn clean package
+
+# Run the simulator
+java -jar target/ds-sim-*.jar
+</pre>
+<br />
+<span>For a faster development build without running tests:</span><br />
+<br />
+<pre>
+mvn package -DskipTests
+</pre>
+<br />
+<span>After building, the following artifacts are available in the <span class='inlinecode'>target/</span> directory:</span><br />
+<br />
+<ul>
+<li><span class='inlinecode'>ds-sim-1.1.0.jar</span> - Executable JAR with all dependencies bundled</li>
+<li><span class='inlinecode'>original-ds-sim-1.1.0.jar</span> - JAR without dependencies</li>
+</ul><br />
+<span>The project also includes 208 unit tests that can be run with <span class='inlinecode'>mvn test</span>. Example simulation files for all built-in protocols are included in the <span class='inlinecode'>saved-simulations/</span> directory.</span><br />
+<br />
+<a class='textlink' href='https://codeberg.org/snonux/ds-sim'>ds-sim source code on Codeberg</a><br />
+<br />
+<h2 style='display: inline' id='fundamentals'>Fundamentals</h2><br />
+<br />
+<span>For basic understanding, some fundamentals are explained below. A deeper exploration will follow in later chapters.</span><br />
+<br />
+<h3 style='display: inline' id='clientserver-model'>Client/Server Model</h3><br />
+<br />
+<pre>
++-----------------------------------------+
+|                                         |
+|   +--------+         +--------+         |
+|   | Client |&lt;-------&gt;| Server |         |
+|   +--------+         +--------+         |
+|                                         |
+|       Sending of Messages               |
+|                                         |
++-----------------------------------------+
+
+Figure 1.1: Client/Server Model
+</pre>
+<br />
+<span>The simulator is based on the client/server principle. Each simulation typically consists of a participating client and a server that communicate with each other via messages (see Fig. 1.1). In complex simulations, multiple clients and/or servers can also participate.</span><br />
+<br />
+<h3 style='display: inline' id='processes-and-their-roles'>Processes and Their Roles</h3><br />
+<br />
+<span>A distributed system is simulated using processes. Each process takes on one or more roles. For example, one process can take on the role of a client and another process the role of a server. The possibility of assigning both client and server roles to a process simultaneously is also provided. A process could also take on the roles of multiple servers and clients simultaneously. To identify a process, each one has a unique Process Identification Number (PID).</span><br />
+<br />
+<h3 style='display: inline' id='messages'>Messages</h3><br />
+<br />
+<span>In a distributed system, it must be possible to send messages. A message can be sent by a client or server process and can have any number of recipients. The content of a message depends on the protocol used. What is meant by a protocol will be covered later. To identify a message, each message has a unique Message Identification Number (NID).</span><br />
+<br />
+<h3 style='display: inline' id='local-and-global-clocks'>Local and Global Clocks</h3><br />
+<br />
+<span>In a simulation, there is exactly one global clock. It represents the current and always correct time. A global clock never goes wrong.</span><br />
+<br />
+<span>Additionally, each participating process has its own local clock. It represents the current time of the respective process. Unlike the global clock, local clocks can display an incorrect time. If the process time is not globally correct (not equal to the global time, or displays an incorrect time), then it was either reset during a simulation, or it is running incorrectly due to clock drift. The clock drift indicates by what factor the clock is running incorrectly. This will be discussed in more detail later.</span><br />
+<br />
+<pre>
++---------------------+     +---------------------+
+|    Process 1        |     |    Process 2        |
+|                     |     |                     |
+| +-----------------+ |     | +-----------------+ |
+| |Server Protocol A| |     | |Client Protocol A| |
+| +-----------------+ |     | +-----------------+ |
+|                     |     |                     |
+| +-----------------+ |     +---------------------+
+| |Client Protocol B| |
+| +-----------------+ |     +---------------------+
+|                     |     |    Process 3        |
++---------------------+     |                     |
+                            | +-----------------+ |
+                            | |Server Protocol B| |
+                            | +-----------------+ |
+                            |                     |
+                            +---------------------+
+
+Figure 1.2: Client/Server Protocols
+</pre>
+<br />
+<span>In addition to normal clocks, vector timestamps and Lamport&#39;s logical clocks are also of interest. For vector and Lamport times, there are no global equivalents here, unlike normal time. Concrete examples of Lamport and vector times will be covered later in the "Additional Examples" section.</span><br />
+<br />
+<h3 style='display: inline' id='events'>Events</h3><br />
+<br />
+<span>A simulation consists of the sequential execution of finitely many events. For example, there can be an event that causes a process to send a message. A process crash event would also be conceivable. Each event occurs at a specific point in time. Events with the same occurrence time are executed directly one after another by the simulator. However, this does not hinder the simulator&#39;s users, as events are executed in parallel from their perspective.</span><br />
+<br />
+<span>Two main types of events are distinguished: programmable events and non-programmable events. Programmable events can be programmed and edited in the event editor, and their occurrence times depend on the local process clocks or the global clock. Non-programmable events, on the other hand, cannot be programmed in the event editor and do not occur because of a specific time, but due to other circumstances such as:</span><br />
+<br />
+<ul>
+<li>Message receive events: Triggered when a message arrives at a recipient process</li>
+<li>Protocol schedule events (alarms): Triggered by a timer set by a protocol, e.g. for retransmission timeouts</li>
+<li>Random events: Such as random process crashes based on configured crash probability</li>
+</ul><br />
+<h3 style='display: inline' id='protocols'>Protocols</h3><br />
+<br />
+<span>A simulation also consists of the application of protocols. It has already been mentioned that a process can take on the roles of servers and/or clients. For each server and client role, the associated protocol must also be specified. A protocol defines how a client and a server send messages, and how they react when a message arrives. A protocol also determines what data is contained in a message. A process only processes a received message if it understands the respective protocol.</span><br />
+<br />
+<span>In Figure 1.2, 3 processes are shown. Process 1 supports protocol "A" on the server side and protocol "B" on the client side. Process 2 supports protocol "A" on the client side and Process 3 supports protocol "B" on the server side. This means that Process 1 can communicate with Process 2 via protocol "A" and with Process 3 via protocol "B". Processes 2 and 3 are incompatible with each other and cannot process messages received from each other.</span><br />
+<br />
+<span>Clients cannot communicate with clients, and servers cannot communicate with servers. For communication, at least one client and one server are always required. However, this restriction can be circumvented by having processes support a given protocol on both the server and client sides (see Broadcast Protocol later).</span><br />
+<br />
+<h2 style='display: inline' id='graphical-user-interface-gui'>Graphical User Interface (GUI)</h2><br />
+<br />
+<h3 style='display: inline' id='simple-mode'>Simple Mode</h3><br />
+<br />
+<a href='./distributed-systems-simulator/ds-sim-screenshot2.png'><img alt='Screenshot: The simulator showing the settings dialog. The visualization area displays process bars with message lines between them. The settings window allows configuring simulation parameters like number of processes, simulation duration, clock drift, message loss probability, and more.' title='Screenshot: The simulator showing the settings dialog. The visualization area displays process bars with message lines between them. The settings window allows configuring simulation parameters like number of processes, simulation duration, clock drift, message loss probability, and more.' src='./distributed-systems-simulator/ds-sim-screenshot2.png' /></a><br />
+<br />
+<span>The simulator requires JDK 21 and can be started with the command <span class='inlinecode'>java -jar target/ds-sim-VERSION.jar</span></span><br />
+<br />
+<span>The simulator then presents itself with a main window. To create a new simulation, select "New Simulation" from the "File" menu, after which the settings window for the new simulation appears. The individual options will be discussed in more detail later, and for now, only the default settings will be used.</span><br />
+<br />
+<span>By default, the simulator starts in "simple mode". There is also an "expert mode", which will be discussed later.</span><br />
+<br />
+<h3 style='display: inline' id='the-menu-bar'>The Menu Bar</h3><br />
+<br />
+<span>In the File menu, you can create new simulations or close the currently open simulation. New simulations open by default in a new tab. However, you can also open or close new simulation windows that have their own tabs. Each tab contains a simulation that is completely independent from the others. This allows any number of simulations to be run in parallel. The menu items "Open", "Save" and "Save As" are used for loading and saving simulations.</span><br />
+<br />
+<span>Through the Edit menu, users can access the simulation settings, which will be discussed in more detail later. This menu also lists all participating processes for editing. If the user selects a process there, the corresponding process editor opens. The Simulator menu offers the same options as the toolbar, which is described in the next section.</span><br />
+<br />
+<span>Some menu items are only accessible when a simulation has already been created or loaded in the current window.</span><br />
+<br />
+<h3 style='display: inline' id='the-toolbar'>The Toolbar</h3><br />
+<br />
+<span>The toolbar is located at the top left of the simulator. The toolbar contains the functions most frequently needed by users. The toolbar offers four different functions:</span><br />
+<br />
+<ul>
+<li>Reset simulation: can only be activated when the simulation has been paused or has finished</li>
+<li>Repeat simulation: cannot be activated if the simulation has not yet been started</li>
+<li>Pause simulation: can only be activated when the simulation is currently running</li>
+<li>Start simulation: can only be activated when the simulation is not currently running and has not yet finished</li>
+</ul><br />
+<h3 style='display: inline' id='the-visualization'>The Visualization</h3><br />
+<br />
+<span>The graphical simulation visualization is located in the center right. The X-axis shows the time in milliseconds, and all participating processes are listed on the Y-axis. The demo simulation ends after exactly 15 seconds. The visualization shows processes (with PIDs 1, 2, and 3), each with its own horizontal black bar. On these process bars, users can read the respective local process time. The vertical red line represents the global simulation time.</span><br />
+<br />
+<span>The process bars also serve as start and end points for messages. For example, if Process 1 sends a message to Process 2, a line is drawn from one process bar to the other. Messages that a process sends to itself are not visualized but are logged in the log window (more on this later).</span><br />
+<br />
+<span>Another way to open a process editor is to left-click on the process bar belonging to the process. A right-click, on the other hand, opens a popup window with additional options. A process can only be forced to crash or be revived via the popup menu during a running simulation.</span><br />
+<br />
+<span>In general, the number of processes can vary as desired. The simulation duration is at least 5 and at most 120 seconds. The simulation only ends when the global time reaches the specified simulation end time (here 15 seconds), not when a local process time reaches this end time.</span><br />
+<br />
+<h3 style='display: inline' id='color-differentiation'>Color Differentiation</h3><br />
+<br />
+<span>Colors help to better interpret the processes of a simulation. By default, processes (process bars) and messages are displayed with the following colors (these are only the default colors, which can be changed via the settings):</span><br />
+<br />
+<pre>
+Process Colors:
+  Black   - The simulation is not currently running
+  Green   - The process is running normally
+  Orange  - The mouse is over the process bar
+  Red     - The process has crashed
+
+Message Colors:
+  Green   - The message is still in transit
+  Blue    - The message has successfully reached its destination
+  Red     - The message was lost
+</pre>
+<br />
+<h3 style='display: inline' id='the-sidebar'>The Sidebar</h3><br />
+<br />
+<span>The sidebar is used to program process events. At the top, the process to be managed is selected (here with PID 1). In this process selection, there is also the option to select "All Processes", which displays all programmed events of all processes simultaneously. "Local events" are those events that occur when a certain local time of the associated process has been reached. The event table below lists all programmed events along with their occurrence times and PIDs.</span><br />
+<br />
+<span>To create a new event, the user can either right-click on a process bar and select "Insert local event", or select an event below the event table, enter the event occurrence time in the text field below, and click "Apply".</span><br />
+<br />
+<span>Right-clicking on the event editor allows you to either copy or delete all selected events. Using the Ctrl key, multiple events can be selected simultaneously. The entries in the Time and PID columns can be edited afterwards. This provides a convenient way to move already programmed events to a different time or assign them to a different process. However, users should ensure that they press the Enter key after changing the event occurrence time, otherwise the change will be ineffective.</span><br />
+<br />
+<span>In addition to the Events tab, the sidebar has another tab called "Variables". Behind this tab is the process editor of the currently selected process. There, all variables of the process can be edited, providing another way to access a process editor.</span><br />
+<br />
+<h3 style='display: inline' id='the-log-window'>The Log Window</h3><br />
+<br />
+<span>The log window (at the bottom) logs all occurring events in chronological order. At the beginning of each log entry, the global time in milliseconds is always logged. For each process, its local times as well as the Lamport and vector timestamps are also listed. After the time information, additional details are provided, such as which message was sent with what content and which protocol it belongs to. This will be demonstrated later with examples.</span><br />
+<br />
+<pre>
+000000ms: New Simulation
+000000ms: New Process; PID: 1; Local Time: 000000ms; Lamport time: 0; Vector time: (0,0,0)
+000000ms: New Process; PID: 2; Local Time: 000000ms; Lamport time: 0; Vector time: (0,0,0)
+000000ms: New Process; PID: 3; Local Time: 000000ms; Lamport time: 0; Vector time: (0,0,0)
+</pre>
+<br />
+<span>By deactivating the logging switch, message logging can be temporarily disabled. With logging deactivated, no new messages are written to the log window. After reactivating the switch, all omitted messages are subsequently written to the window. Deactivated logging can lead to improved simulator performance.</span><br />
+<br />
+<h3 style='display: inline' id='expert-mode'>Expert Mode</h3><br />
+<br />
+<a href='./distributed-systems-simulator/ds-sim-screenshot.png'><img alt='Screenshot: The Distributed Systems Simulator in expert mode, showing a Broadcast protocol simulation with 6 processes. The visualization shows message lines between process bars, with blue indicating delivered messages and green indicating messages still in transit.' title='Screenshot: The Distributed Systems Simulator in expert mode, showing a Broadcast protocol simulation with 6 processes. The visualization shows message lines between process bars, with blue indicating delivered messages and green indicating messages still in transit.' src='./distributed-systems-simulator/ds-sim-screenshot.png' /></a><br />
+<br />
+<span>The simulator can be operated in two different modes: simple mode and expert mode. The simulator starts in simple mode by default, so users don&#39;t have to deal with the simulator&#39;s full functionality all at once. Simple mode is clearer but offers fewer functions. Expert mode is more suitable for experienced users and accordingly offers more flexibility. Expert mode can be activated or deactivated via the switch of the same name below the log window or via the simulation settings.</span><br />
+<br />
+<span>In expert mode, the following additional features become available:</span><br />
+<br />
+<ul>
+<li>Global events: In addition to local events, global events can now also be edited. Global events are triggered when a specific global simulation time is reached, rather than a local process time. This only makes a difference when local process times differ from the global time (e.g. due to clock drift).</li>
+<li>Direct PID selection: The user can directly select the associated PID when programming a new event.</li>
+<li>Lamport and Vector time switches: If the user activates one of these two switches, the Lamport or vector timestamps are displayed in the visualization. Only one can be active at a time to maintain clarity.</li>
+<li>Anti-aliasing switch: Allows the user to activate or deactivate anti-aliasing for smoother graphics. Disabled by default for performance reasons.</li>
+<li>Log filter: A regular expression filter (Java syntax) that makes it possible to filter only the essential data from the logs. For example, <span class='inlinecode'>"PID: (1|2)"</span> shows only log lines containing "PID: 1" or "PID: 2". The filter can be activated retroactively and during a running simulation.</li>
+</ul><br />
+<h3 style='display: inline' id='configuration-settings'>Configuration Settings</h3><br />
+<br />
+<span>The simulation settings window allows configuring many aspects of the simulation. Key settings include:</span><br />
+<br />
+<ul>
+<li>Processes receive own messages (default: false): Whether processes can receive messages they sent to themselves.</li>
+<li>Average message loss probabilities (default: true): Whether to average the loss probabilities of sender and receiver processes.</li>
+<li>Average transmission times (default: true): Whether to average the transmission times of sender and receiver processes.</li>
+<li>Show only relevant messages (default: true): Hides messages sent to processes that don&#39;t support the protocol.</li>
+<li>Expert mode (default: false): Enables expert mode features.</li>
+<li>Simulation speed (default: 0.5): The playback speed factor. A value of 1 means real-time, 0.5 means half speed.</li>
+<li>Number of processes (default: 3): Can also be changed during simulation via right-click.</li>
+<li>Simulation duration (default: 15s): Between 5 and 120 seconds.</li>
+</ul><br />
+<span>Each process also has individual settings:</span><br />
+<br />
+<ul>
+<li>Clock drift (default: 0.0): By what factor the local clock deviates. A value of 0.0 means no deviation. A value of 1.0 means double speed. Values &gt; -1.0 are allowed.</li>
+<li>Random crash probability (default: 0%): Probability that the process crashes randomly during the simulation.</li>
+<li>Message loss probability (default: 0%): Probability that a message sent by this process is lost in transit.</li>
+<li>Min/Max transmission time (default: 500ms/2000ms): The range for random message delivery times.</li>
+</ul><br />
+<span>Read the next post of this series:</span><br />
+<br />
+<a class='textlink' href='./2026-04-01-distributed-systems-simulator-part-2.html'>Distributed Systems Simulator - Part 2: Built-in Protocols</a><br />
+<br />
+<span>Other related posts are:</span><br />
+<br />
+<a class='textlink' href='./2026-03-01-loadbars-0.13.0-released.html'>2026-03-01 Loadbars 0.13.0 released</a><br />
+<a class='textlink' href='./2022-12-24-ultrarelearning-java-my-takeaways.html'>2022-12-24 (Re)learning Java - My takeaways</a><br />
+<a class='textlink' href='./2022-03-06-the-release-of-dtail-4.0.0.html'>2022-03-06 The release of DTail 4.0.0</a><br />
+<a class='textlink' href='./2016-11-20-object-oriented-programming-with-ansi-c.html'>2016-11-20 Object oriented programming with ANSI C</a><br />
+<br />
+<span>E-Mail your comments to <span class='inlinecode'>paul@nospam.buetow.org</span></span><br />
+<br />
+<a class='textlink' href='../'>Back to the main site</a><br />
+<p class="footer">
+	Generated with <a href="https://codeberg.org/snonux/gemtexter">Gemtexter 3.0.1-develop</a> |
+	served by <a href="https://www.OpenBSD.org">OpenBSD</a>/<a href="https://man.openbsd.org/relayd.8">relayd(8)</a>+<a href="https://man.openbsd.org/httpd.8">httpd(8)</a> |
+	<a href="https://foo.zone/site-mirrors.html">Site Mirrors</a>
+	<br />
+	Webring: <a href="https://shring.sh/foo.zone/previous">previous</a> | <a href="https://shring.sh">shring</a> | <a href="https://shring.sh/foo.zone/next">next</a>
+</p>
+</body>
+</html>
diff --git a/gemfeed/2026-04-01-distributed-systems-simulator-part-2.html b/gemfeed/2026-04-01-distributed-systems-simulator-part-2.html
new file mode 100644
index 00000000..58027fa4
--- /dev/null
+++ b/gemfeed/2026-04-01-distributed-systems-simulator-part-2.html
@@ -0,0 +1,397 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+<title>Distributed Systems Simulator - Part 2: Built-in Protocols</title>
+<link rel="shortcut icon" type="image/gif" href="/favicon.ico" />
+<link rel="stylesheet" href="../style.css" />
+<link rel="stylesheet" href="style-override.css" />
+</head>
+<body>
+<p class="header">
+<a href="https://foo.zone">Home</a> | <a href="https://codeberg.org/snonux/foo.zone/src/branch/content-md/gemfeed/2026-04-01-distributed-systems-simulator-part-2.md">Markdown</a> | <a href="gemini://foo.zone/gemfeed/2026-04-01-distributed-systems-simulator-part-2.gmi">Gemini</a>
+</p>
+<h1 style='display: inline' id='distributed-systems-simulator---part-2-built-in-protocols'>Distributed Systems Simulator - Part 2: Built-in Protocols</h1><br />
+<br />
+<span class='quote'>Published at 2026-04-01T00:00:00+03:00</span><br />
+<br />
+<span>This is the second blog post of the Distributed Systems Simulator series. This part covers all 10 built-in protocols with examples.</span><br />
+<br />
+<a class='textlink' href='https://codeberg.org/snonux/ds-sim'>ds-sim on Codeberg (modernized, English-translated version)</a><br />
+<br />
+<span>These are all the posts of this series:</span><br />
+<br />
+<a class='textlink' href='./2026-03-31-distributed-systems-simulator-part-1.html'>2026-03-31 Distributed Systems Simulator - Part 1: Introduction and GUI</a><br />
+<a class='textlink' href='./2026-04-01-distributed-systems-simulator-part-2.html'>2026-04-01 Distributed Systems Simulator - Part 2: Built-in Protocols (You are currently reading this)</a><br />
+<a class='textlink' href='./2026-04-02-distributed-systems-simulator-part-3.html'>2026-04-02 Distributed Systems Simulator - Part 3: Advanced Examples and Protocol API</a><br />
+<br />
+<a href='./distributed-systems-simulator/ds-sim-screenshot.png'><img alt='Screenshot: The Distributed Systems Simulator running a Broadcast protocol simulation with 6 processes. The visualization shows message lines between process bars, with blue indicating delivered messages and green indicating messages still in transit.' title='Screenshot: The Distributed Systems Simulator running a Broadcast protocol simulation with 6 processes. The visualization shows message lines between process bars, with blue indicating delivered messages and green indicating messages still in transit.' src='./distributed-systems-simulator/ds-sim-screenshot.png' /></a><br />
+<br />
+<h2 style='display: inline' id='table-of-contents'>Table of Contents</h2><br />
+<br />
+<ul>
+<li><a href='#distributed-systems-simulator---part-2-built-in-protocols'>Distributed Systems Simulator - Part 2: Built-in Protocols</a></li>
+<li>⇢ <a href='#protocols-and-examples'>Protocols and Examples</a></li>
+<li>⇢ ⇢ <a href='#dummy-protocol'>Dummy Protocol</a></li>
+<li>⇢ ⇢ <a href='#ping-pong-protocol'>Ping-Pong Protocol</a></li>
+<li>⇢ ⇢ <a href='#broadcast-protocol'>Broadcast Protocol</a></li>
+<li>⇢ ⇢ <a href='#internal-synchronization-protocol'>Internal Synchronization Protocol</a></li>
+<li>⇢ ⇢ <a href='#christian-s-method-external-synchronization'>Christian&#39;s Method (External Synchronization)</a></li>
+<li>⇢ ⇢ <a href='#berkeley-algorithm'>Berkeley Algorithm</a></li>
+<li>⇢ ⇢ <a href='#one-phase-commit-protocol'>One-Phase Commit Protocol</a></li>
+<li>⇢ ⇢ <a href='#two-phase-commit-protocol'>Two-Phase Commit Protocol</a></li>
+<li>⇢ ⇢ <a href='#basic-multicast-protocol'>Basic Multicast Protocol</a></li>
+<li>⇢ ⇢ <a href='#reliable-multicast-protocol'>Reliable Multicast Protocol</a></li>
+</ul><br />
+<h2 style='display: inline' id='protocols-and-examples'>Protocols and Examples</h2><br />
+<br />
+<span>The simulator comes with 10 built-in protocols. As described earlier, protocols are distinguished between server-side and client-side. Servers can respond to client messages, and clients can respond to server messages. Each process can support any number of protocols on both the client and server side. Users can also implement their own protocols using the simulator&#39;s Protocol API (see the Protocol API section).</span><br />
+<br />
+<span>The program directory contains a <span class='inlinecode'>saved-simulations</span> folder with example simulations for each protocol as serialized <span class='inlinecode'>.dat</span> files.</span><br />
+<br />
+<h3 style='display: inline' id='dummy-protocol'>Dummy Protocol</h3><br />
+<br />
+<span>The Dummy Protocol serves only as a template for creating custom protocols. When using the Dummy Protocol, only log messages are output when events occur. No further actions are performed.</span><br />
+<br />
+<h3 style='display: inline' id='ping-pong-protocol'>Ping-Pong Protocol</h3><br />
+<br />
+<a href='./distributed-systems-simulator/ping-pong.png'><img alt='Visualization: The Ping-Pong Protocol showing two processes (P1 and P2) exchanging messages in a continuous back-and-forth pattern. Blue lines represent delivered messages bouncing between the process bars over a 15-second simulation.' title='Visualization: The Ping-Pong Protocol showing two processes (P1 and P2) exchanging messages in a continuous back-and-forth pattern. Blue lines represent delivered messages bouncing between the process bars over a 15-second simulation.' src='./distributed-systems-simulator/ping-pong.png' /></a><br />
+<br />
+<span>In the Ping-Pong Protocol, two processes -- Client P1 and Server P2 -- constantly send messages back and forth. The Ping-Pong client starts the first request, to which the server responds to the client. The client then responds again, and so on. Each message includes a counter that is incremented at each station and logged in the log window.</span><br />
+<br />
+<pre>
+Programmed Ping-Pong Events:
+
+| Time (ms) | PID | Event                          |
+|-----------|-----|--------------------------------|
+| 0         | 1   | Ping-Pong Client activate      |
+| 0         | 2   | Ping-Pong Server activate      |
+| 0         | 1   | Ping-Pong Client request start |
+</pre>
+<br />
+<span>It is important that Process 1 activates its Ping-Pong client before starting a Ping-Pong client request. Before a process can start a request, it must have the corresponding protocol activated. This also applies to all other protocols.</span><br />
+<br />
+<span>**Ping-Pong Storm Variant**</span><br />
+<br />
+<a href='./distributed-systems-simulator/ping-pong-storm.png'><img alt='Visualization: The Ping-Pong Storm variant with three processes. P1 is the client, P2 and P3 are both servers. The visualization shows an exponentially growing number of messages as each client message generates two server responses, creating a dense web of blue and green message lines.' title='Visualization: The Ping-Pong Storm variant with three processes. P1 is the client, P2 and P3 are both servers. The visualization shows an exponentially growing number of messages as each client message generates two server responses, creating a dense web of blue and green message lines.' src='./distributed-systems-simulator/ping-pong-storm.png' /></a><br />
+<br />
+<span>By adding a third process P3 as an additional Ping-Pong server, a Ping-Pong "Storm" can be realized. Since every client message now receives two server responses, the number of messages doubles with each round, creating an exponential message flood.</span><br />
+<br />
+<pre>
+Programmed Ping-Pong Storm Events:
+
+| Time (ms) | PID | Event                          |
+|-----------|-----|--------------------------------|
+| 0         | 1   | Ping-Pong Client activate      |
+| 0         | 2   | Ping-Pong Server activate      |
+| 0         | 3   | Ping-Pong Server activate      |
+| 0         | 1   | Ping-Pong Client request start |
+</pre>
+<br />
+<h3 style='display: inline' id='broadcast-protocol'>Broadcast Protocol</h3><br />
+<br />
+<a href='./distributed-systems-simulator/broadcast.png'><img alt='Visualization: The Broadcast Protocol with 6 processes (P1-P6). Dense crossing message lines show how a broadcast from P1 propagates to all processes, with each process re-broadcasting to others. Blue lines indicate delivered messages, green lines indicate messages still in transit.' title='Visualization: The Broadcast Protocol with 6 processes (P1-P6). Dense crossing message lines show how a broadcast from P1 propagates to all processes, with each process re-broadcasting to others. Blue lines indicate delivered messages, green lines indicate messages still in transit.' src='./distributed-systems-simulator/broadcast.png' /></a><br />
+<br />
+<span>The Broadcast Protocol behaves similarly to the Ping-Pong Protocol. The difference is that the protocol tracks -- using a unique Broadcast ID -- which messages have already been sent. Each process re-broadcasts all received messages to others, provided it has not already sent them.</span><br />
+<br />
+<span>In this case, no distinction is made between client and server, so that the same action is performed when a message arrives at either side. This makes it possible, using multiple processes, to create a broadcast. P1 is the client and starts a request at 0ms and 2500ms. The simulation duration is exactly 5000ms. Since a client can only receive server messages and a server can only receive client messages, every process in this simulation is both server and client.</span><br />
+<br />
+<pre>
+Programmed Broadcast Events:
+
+| Time (ms) | PID | Event                            |
+|-----------|-----|----------------------------------|
+| 0         | 1-6 | Broadcast Client activate        |
+| 0         | 1-6 | Broadcast Server activate        |
+| 0         | 1   | Broadcast Client request start   |
+| 2500      | 1   | Broadcast Client request start   |
+</pre>
+<br />
+<h3 style='display: inline' id='internal-synchronization-protocol'>Internal Synchronization Protocol</h3><br />
+<br />
+<a href='./distributed-systems-simulator/int-sync.png'><img alt='Visualization: Internal Synchronization with 2 processes. P1 (client, clock drift 0.1) shows a faster-running clock reaching 15976ms by simulation end. The blue message lines show P1 periodically synchronizing with P2 (server, no drift), with the time corrections visible as slight adjustments in P1&#39;s timeline.' title='Visualization: Internal Synchronization with 2 processes. P1 (client, clock drift 0.1) shows a faster-running clock reaching 15976ms by simulation end. The blue message lines show P1 periodically synchronizing with P2 (server, no drift), with the time corrections visible as slight adjustments in P1&#39;s timeline.' src='./distributed-systems-simulator/int-sync.png' /></a><br />
+<br />
+<span>The Internal Synchronization Protocol is used for synchronizing the local process time, which can be applied when a process time is running incorrectly due to clock drift. When the client wants to synchronize its (incorrect) local process time t_c with a server, it sends a client request. The server responds with its own local process time t_s, allowing the client to calculate a new, more accurate time for itself.</span><br />
+<br />
+<span>After receiving the server response
author	Paul Buetow <paul@buetow.org>	2026-03-30 09:17:13 +0300
committer	Paul Buetow <paul@buetow.org>	2026-03-30 09:17:13 +0300
commit	ae6b3fde6d2ef130e2bb18dd2c6ee040687b143d (patch)
tree	f2b831df9f1377cf0579496e7e82a46472c81d5d /gemfeed
parent	39b002074e735808daafa3b7f1fe960c9ab603b2 (diff)