Team #6: Team Slackers

18-749: Fault-Tolerant Distributed Systems
Spring 2006



Table of Contents
  1. Project Information
    1. Team Members
    2. Team Roles
    3. Project Title
    4. Baseline Application Description
    5. CVS
    6. Configuration
    7. Third-party software, if any (databases)
    8. Baseline Application Features
    9. Dependability Requirements
    10. Real-Time Requirements
    11. Performance Requirements
  2. Baseline Application
    1. Interfaces
      1. Tiers
      2. Methods
      3. Attributes
      4. Exceptions
      5. Servers and Ports
    2. Database Tables
      1. Client
      2. Level
      3. Lot
      4. LotDistance
    3. Code Documentation (JavaDoc)
    4. Scenarios/Interactions
    5. Current Status
    6. Downloads
    7. Feedback
      1. 2/11/2006: Feedback on project proposal
      2. Feedback on project interfaces and end-to-end use case
      3. Feedback on end-to-end use case
      4. 3/22/2006: Checkpoint 1 Presentation
  3. Fault-Tolerant Baseline Application
    1. Scenarios/Interactions
    2. Current Status
    3. Downloads
    4. Fault Tolerant Design
  4. Real-Time Fault-Tolerant Baseline Application
    1. Scenarios/Interactions
    2. Current Status
    3. Downloads
  5. High-Performance Real-Time Fault-Tolerant Baseline Application
    1. Scenarios/Interactions
    2. Current Status
    3. Downloads

Project Information

Team Members

Team Roles

Responsibility Hyunwoo Karim Puneet Tanmay Steven
Project Management       X X
Requirements Specification X   X    
Architecture Design X X   X  
Database Design   X X   X
Implementation - Client     X X  
Implementation - Server X X     X
Testing X X X X X
Tool Support         X
Performance Analysis   X   X X
Real-time Analysis X X X    
Reliability Analysis X   X X  
Presentation X X X X X

Project Title

Park'n Park

Baseline Application Description

A system that manages parking lots by keeping track of how many spaces are available in lots and recommends other lots when the lot a driver is at is full

CVS

Configuration

Third-party software, if any (databases)

Baseline Application Features

  1. User enters a lot at an entry level and gets the available levels. In the current version, the entry level is always the first level.
  2. The system will let the driver know at the entrance whether there is space available in the lot or not.
  3. If there is space available in the lot, the system will let the driver know which levels have available spaces after the driver enters the lot.
  4. If no space is available in the lot, the system will let the driver know the nearest parking lots that have available space.
  5. If no space is available in any of the lots, the system will display an appropriate message.
  6. Once in a lot, the user can move from one level to either the next higher or lower level when such a level exists.
  7. In a lot, the user can only exit at an exit level, which is currently defined as the first level.
  8. The user will get informed of attempts to enter nonexistent lots.
  9. The user cannot exit a lot if their car is not in one.
  10. The user cannot enter a lot if their car is already in a lot. The car must leave its current lot first.
  11. The server will report unrecoverable database conditions and other major problems to the client to inform them that service is unavailable.
  12. The client, which represents a car, can choose to drive up to any lot in the system.

Dependability Requirements

  1. The driver will experience at most a five second delay upon a single server failure. Service will continue after the five second delay.
  2. The system will be available 24x7 without any critical system failures, defined as failures that prevent the system from performing its duties to its clients.
  3. Every hour, the system will perform an integrity check to make sure that each lot's total counter synchronizes with its level counters.
  4. The result displayed to the driver will be within plus or minus one parking space of the actual physical state of the lot.

Real-Time Requirements

  1. At a parking lot entrance gate, the driver will receive a result within at most five seconds.
  2. The system will update a lot's counter within one second upon a car entering or leaving that lot.
  3. The system will automatically update a parking lot level's counter within one second of a car leaving that level.

Performance Requirements

  1. The system will support at least 50 simultaneous entry and exit transactions under normal working conditions.
  2. The system will allow at least 120 cars to enter each lot in one hour under normal working conditions, given that the lot does not become full.
  3. The system will support at least 25 parking lots.


Baseline Application

Interfaces

Tiers

Methods

Client Manager Factory (one per server)

Client Manager (one per client)

Attributes

Exceptions

Servers and Ports

Database

mahjongg:3306 for MySQL

Middle Tier

clue:7779 for IIOP

Replication Manager

boggle: 7780 for IIOP

Naming Service

boggle:7777 for bootstrap and 7778 for IIOP

Database Tables

Client

Level

Lot

LotDistance

Code Documentation (JavaDoc)

Scenarios/Interactions

  1. User enters a lot at an entry level and gets the available levels. In the current version, the entry level is always the first level.
  2. The system will let the driver know at the entrance whether there is space available in the lot or not.
  3. If there is space available in the lot, the system will let the driver know which levels have available spaces after the driver enters the lot.
  4. If no space is available in the lot, the system will let the driver know the nearest parking lots that have available space.
  5. If no space is available in any of the lots, the system will display an appropriate message.
  6. Once in a lot, the user can move from one level to either the next higher or lower level when such a level exists.
  7. In a lot, the user can only exit at an exit level, which is currently defined as the first level.
  8. The user will get informed of attempts to enter nonexistent lots.
  9. The user cannot exit a lot if their car is not in one.
  10. The user cannot enter a lot if their car is already in a lot. The car must leave its current lot first.
  11. The server will report unrecoverable database conditions and other major problems to the client to inform them that service is unavailable.
  12. The client, which represents a car, can choose to drive up to any lot in the system.

Current Status

Downloads

Feedback

2/11/2006: Feedback on project proposal

Feedback on project interfaces and end-to-end use case

Feedback on end-to-end use case

3/22/2006: Checkpoint 1 Presentation


Fault-Tolerant Baseline Application

Scenarios/Interactions

  1. User enters a lot at an entry level and gets the available levels. In the current version, the entry level is always the first level.
  2. The system will let the driver know at the entrance whether there is space available in the lot or not.
  3. If there is space available in the lot, the system will let the driver know which levels have available spaces after the driver enters the lot.
  4. If no space is available in the lot, the system will let the driver know the nearest parking lots that have available space.
  5. If no space is available in any of the lots, the system will display an appropriate message.
  6. Once in a lot, the user can move from one level to either the next higher or lower level when such a level exists.
  7. In a lot, the user can only exit at an exit level, which is currently defined as the first level.
  8. The user will get informed of attempts to enter nonexistent lots.
  9. The user cannot exit a lot if their car is not in one.
  10. The user cannot enter a lot if their car is already in a lot. The car must leave its current lot first.
  11. The server will report unrecoverable database conditions and other major problems to the client to inform them that service is unavailable.
  12. The client, which represents a car, can choose to drive up to any lot in the system.
  13. If the primary server gets killed, then the replication manager will notice the failure and select a new primary server if a backup server exists. The client will notice the failure when it tries to perform its next server call. The client will then periodically poll the name service for the registered primary server and retry the server call.
  14. If the primary server gets killed and no backup servers are running, the replication manager will notice the failure and remove the active server name from the name service. The client will notice the failure when it tries to perform its next server call. The client will notice that no primary server is registered in the name service, notify the user that the system is down, and then exit.

Current Status

Downloads

Fault Tolerant Design


Real-Time Fault-Tolerant Baseline Application

Scenarios/Interactions

Current Status

Downloads


High-Performance Real-Time Fault-Tolerant Baseline Application

Scenarios/Interactions

Current Status

Downloads