Fault Tolerant distributed coordination (ID:1576)
Project Creator: |
fouair
FC Member For 6676 Days
Credits 60 Completed Proj. Num. 0 / 1 Total payment USD Avg Daily Online 0.00 h (From 21/5/2007) Available on MSN/Skype No Last Login 11/20/2006 Peers Rating 0.00% ![]() ![]() ![]() |
---|---|
Budget: | Less than 250 |
Created: | 11/16/2006 9:24:18 PM EST |
Bidding Ends: | 11/19/2006 9:24:18 PM EST ( Expired ) |
Development Cycle: | 10 Days |
Bid Count: | 1
|
Average Bid: | 250.00 |
Project Description:
Language: C/C++ Platform: Unix Please check attached file for complete details about the projet Deliverables include ALL of the following: 1. All source files + Makefile. 2. Operational information, regarding how to modify the configuration (e.g. initial topology and IP/port numbers), how to inject faults, how to have a faulty node re-join the system, and so on. It is suggested that you include all this info in a README file 2. A write-up summarizing the design and operation principles of your system 3. An accurate description of the fault model that you assume (The extent and number of faults that your system can tolerate: explain further if multiple faults can be injected simultaneously) 4. Details of protocols and algorithms you use to achieve distributed mutual exclusion, fault tolerance and re-configuration/re-organization. In particular, (a) provide an in-depth explanation of how your system detects and recovers from: i. the crash of a single node ii. the loss of the token iii. the simultaneous crashes of multiple nodes, with or without token (in case that you address this case) (b) explain how it is re-configured after a fault has (and, multiple faults have) been detected, how a new tree structure is obtained and when the system resumes operation, (c) evaluate (preferably quantify, as a function of the number of nodes and other parameters) the run-time messaging overhead of your fault detection/recovery/reorganization solutions, (d) explain how and when a recovering node can re-join the system. 5. Justification of major design decisions you made (including the factors that led you to work with processes (or threads), the principle based on which you determined the timeout interval T, the reason you chose to adopt the solutions you listed in item 3. above, etc.) 6. An evaluation of your project, which may include the objectives you failed to reach (if any) and suggestions for further enhancements to your system 7. The pseudo-code of your programs |
|
Job Type | C/C++ |
Attached Files: | 20061116212359.doc |