DSMS Deployment with 3 Computers

This guide shows how to run our actively replicated DSMS (with Front End, Sequencer, Replicas, and Replica Managers) using only three physical machines on a local network. We will also demonstrate how to test crash failures.

1. System Overview

We need:

• 3 Replicas (+ a Replica Manager attached to each replica),
• 1 Front End (FE) process, and
• 1 Sequencer process.

Because we have only 3 physical machines, one of them must host the FE + Sequencer alongside one Replica (and its RM). The other two machines each host a Replica and its RM. That gives us 3 replicas total and a single FE/Sequencer instance. Below is how you can distribute them:

1. Machine 1:
   • Front End (FE)
   • Sequencer
   • Replica A + RM(A)
2. Machine 2:
   • Replica B + RM(B)
3. Machine 3:
   • Replica C + RM(C)

Each block (Replica + RM) can be run as separate processes or combined logic, but they should communicate on the same machine (e.g., via localhost ports).

Machine 1 hosts:

• The Front End (FE) that clients contact.
• The Sequencer (SQ) that assigns sequence numbers and multicasts requests.
• One instance each of NYK server, LON server, and TOK server, plus their respective replica managers (RM_NYK, RM_LON, RM_TOK).

Key Points:

• All three city server processes run locally on Machine 1, each with its own Replica Manager.
• The Front End and Sequencer are also on Machine 1. Clients only connect to the FE, which delegates requests to the Sequencer for total ordering.

Machines 2 and 3 do not host the FE or Sequencer. They only run:

• The TOK server instance + RM_TOK
• The LON server instance + RM_LON
• The NYK server instance + RM_NYK

That way, each city code has a replica on Machine 1, 2, and 3. The Sequencer on Machine 1 sends requests to all nine processes (3 per machine).

Key Points:

• Each machine has three DSMS processes (TOK, LON, NYK) plus three RMs—one per process.
• The Sequencer and Front End both reside on Machine 1, but they must send/receive data from all replicas (on M1, M2, M3).

Summary

In this final deployment:

• We have 9 total server processes (3 for each city code: TOK1,2,3; LON1,2,3; NYK1,2,3) across **3 physical machines**.
• Each server has a local Replica Manager that monitors it.
• Machine 1 additionally runs the Front End and Sequencer, the only singletons in this system.
• Clients talk only to the FE. The FE delegates requests to the Sequencer, which ensures total ordering and multicasts to all 9 server processes. Each process returns results to the FE for a majority vote (or first-two-match approach), depending on your chosen replication strategy.

2. Running the System and Demonstrating Functionalities

Below is a typical startup order for the system:

1. Machine 1:
   1. Start the Replica Manager A and the corresponding Replica A.
   2. Start the Sequencer (listening on some port, e.g., 7000).
   3. Start the Front End (listening on another port, e.g., 7100) that clients connect to.
2. Machine 2:
   • Start Replica Manager B + Replica B.
3. Machine 3:
   • Start Replica Manager C + Replica C.

Once the system is up, you can point any Admin or Buyer Client to connect to the Front End (on Machine 1). The FE will pass requests to the Sequencer, which multicasts them to all three Replicas in total order.

3. Example Operations to Demonstrate

Your DSMS includes both Admin operations and Buyer operations. Below are the main ones you’ll want to test:

1. Admin Ops:
   • addShare(adminID, shareID, shareType, capacity)
   • removeShare(adminID, shareID, shareType)
   • listShareAvailability(adminID, shareType)
2. Buyer Ops:
   • purchaseShare(buyerID, shareID, shareType, count)
   • getShares(buyerID)
   • sellShare(buyerID, shareID, shareCount)
   • swapShares(buyerID, oldShareID, oldType, newShareID, newType)

When an admin or buyer client runs these operations, they’ll connect to the FE on Machine 1. The FE forwards the request to the Sequencer, which distributes them to all replicas. Each replica returns its local “agreed-upon” result. The FE compares results, detects mismatches or timeouts, and responds to the client.

4. How to Test Crash Failures

This document lists comprehensive test cases to verify your Distributed Share Market System (DSMS) functionality, covering both **normal operations** and **crash scenarios** (process crash). The DSMS includes:

• Three replicated servers (Replicas + Replica Managers)
• One Sequencer
• One Front End (FE)

We also show **visual diagrams** depicting where a crash might occur and how the system recovers.

1. Normal Operation Test Cases

Below is a listing of core admin and buyer operations, covering typical edge cases. These assume **all replicas are running** and no process crashes occur.

**Note**: For cross-city purchases (if you have that limit of 3 shares across different cities), add an additional test verifying the limit is enforced.

2. Crash Failure Test Cases

In the following scenarios, at least one **replica** is forcibly terminated during or right after a request is broadcast by the Sequencer. We assume your DSMS is in crash-failure tolerance mode (i.e., not the software-fault mode). The system should continue to operate with the remaining replicas.

In each crash case, once the Replica Manager detects or is notified of the crash, it spins up a new instance (or restarts) so the system returns to having 3 replicas. The FE can respond to requests as soon as it has at least 2 matching responses from the healthy replicas.

3. Visual Diagrams of Crash and Recovery

Below are two sample sequence diagrams illustrating crash scenarios and the subsequent recovery. The first focuses on a crash during an admin operation (e.g., addShare), the second focuses on a buyer operation (e.g., purchaseShare).

4. Additional Observations

• For software failure tolerance mode (non-malicious Byzantine), you’d do a similar set of tests but with incorrect results instead of crashes. The FE would detect a mismatch and notify the RMs.
• In each test, ensure logs confirm that the correct operations were processed by at least two replicas, and the system recovers once the crashed replica restarts.
• When verifying cross-city limits (if applicable), you can also force a crash mid cross-city purchase to confirm that the final state remains consistent across the surviving replicas.

Conclusion

The test cases above (normal operations + crash scenarios) will help you verify correctness, robustness, and recovery in your actively replicated DSMS:

1. Normal Tests: Check that basic admin and buyer operations behave correctly under no failures.
2. Crash Tests: Forcibly terminate one replica during or just after receiving a request. Confirm the FE obtains matching results from the remaining replicas, and the Replica Manager replaces or restarts the crashed replica.

Together, these tests ensure the DSMS achieves the **high availability** goal under a single crash failure.

5. Minimal Pseudo-code Adjustments for 3 Computers

You can keep the same pseudo-code from the earlier design. The only difference is how you assign host IP addresses and ports to each component. For example:

Machine1_IP = "192.168.0.10"
Machine2_IP = "192.168.0.11"
Machine3_IP = "192.168.0.12"

// On Machine 1
startReplica("A", "192.168.0.10", port=9000)
startRM("A", "192.168.0.10", port=9100)
startSequencer("192.168.0.10", port=7000)
startFrontEnd("192.168.0.10", port=7100, sequencerIP="192.168.0.10", seqPort=7000)

// On Machine 2
startReplica("B", "192.168.0.11", port=9000)
startRM("B", "192.168.0.11", port=9100)

// On Machine 3
startReplica("C", "192.168.0.12", port=9000)
startRM("C", "192.168.0.12", port=9100)

Each replica knows the IP address and ports of the other replicas and the Sequencer. The Front End is the only one the client ever contacts (via 192.168.0.10:7100 in this example).

6. Verifying All Functionalities

After deployment, you can verify:

• Admin functions: Log into the system with a valid Admin ID (like LONA9999) via the FE. Perform:
  • addShare
  • removeShare
  • listShareAvailability
• Buyer functions: Perform:
  • purchaseShare
  • getShares
  • sellShare
  • swapShares

Confirm each replica’s data (e.g., capacities and buyer records) remain consistent. If you forcibly stop any single replica process (on Machine 2 or Machine 3), the FE should continue returning correct results (via the other two healthy replicas).

Conclusion

By following this setup, you can:

• Run a 3-replica active DSMS with limited hardware (only 3 machines).
• Keep the Front End and Sequencer together on Machine 1, plus one local replica/manager.
• Have each of the other two machines host the second and third replicas and their managers.
• Demonstrate all DSMS functions (add/remove/list shares, purchase/sell/swap shares) and test crash failures by forcefully killing one replica to ensure the system remains available.