Skip to content

buddiex/High-Availability-Processes

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

63 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

High-Availability-Processes

Implementation of client, proxy, and server with high availability:
Fault-Tolerant Tuple Space Service
The specifications are in specs.doc
this spec where written by my Dr. Phil Pfeiffer.

Details

CSCI 5150: Phil Pfeiffer
Software-based final exam – fault-tolerant tuple space service
Terms: As individuals or in pairs
Due date: Monday, 10 December, close of business, with interviews to follow

Background:

One reason for implementing a distributed system is to assure a service's fault-tolerance: i.e., its ability to operate after component failures. One classic architecture for ensuring fault tolerance, the active-passive architecture, uses a second, hot-swap server to back up a primary server (Figure 1). This configuration operates as follows:

  • The primary (i.e., active) server, in normal operation,
    • Receives and responds to all requests from client computers
    • Relays all requests for updating the primary's internal state to the backup, which maintains a duplicate of the primary's internal state.
  • The primary and backup servers, in normal operation, monitor each other's status, using "heartbeat" messages.
  • If one of the servers detects that the other has failed:
    • If the primary detects a failure of the backup
      • It notifies an operator that a failure has occurred and keeps operating.
      • The operator should then
        • restore the backup
        • initiate a procedure for resynchronizing its state with the primary server
    • If the backup server detects a failure of the primary
      • It triggers the computer-controlled switch, rerouting of client requests from the failed primary to itself.
      • It notifies an operator that a failure has occurred and keeps operating.
      • The operator should then
        • restore the primary, which becomes the backup
        • initiate a procedure for resynchronizing its state with the primary

This assignment asks you to implement a comparable configuration, using a proxy server in place of the "deadman" switch (Figure 2).

Requirements:

The requirements for this assignment are divisible into requirements for

  • The service
  • Primary and backup servers;
  • Proxy server
  • Client application

Functional Requirements for Service

  • The service shall provide a database service in the form of a tuple space: i.e.,
    • a collection of (key, value) pairs, where
      • keys and values are n-tuples of alphanumeric strings
      • the space has at most one value per key
    • together with four operators:
      • GET - given a (keyexp, valexp) pair,
        • if the (keyexp, valexp) pattern is malformed, return an empty list. Note: assume Python regular expression syntax for keyexp and valexp.
        • else, return all (key, value) pairs such that
          • key matches keyexp
          • value matches valexp
      • PUT -given a purported list of (key, value) pairs,
        • if the list is malformed, return an indication to this effect

        • else

          • for every pair such that
            • key and value are well-formed and
            • key is not yet present in the tuple space

          add (key, value) to the tuple space The specification (specs.doc) and was written by Dr. Phil Pfeiffer.

About

implementation of client, proxy, and server with high availability

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages