Due: Friday, December 11th, 2009 12:25pm
HW7 replaces the originally planned Mid-Term 3. This is an individual assignment.
Start with the code in dist-field.zip. It contains three versions (v1, v2, and v3) of a distributed variant of the program from HW3. You can pick just one of the variants to work with, or you can work with multiple variants.
Modify the code to implement some of the tasks listed below. Each task has an estimated difficultly rating in ★s. Perform enough tasks to that the total number of associated ★s is at least six. Each additional two ★s are worth extra credit. More options may appear, so check for updates. If you have an idea that is not on this list, send e-mail to the instructor, and maybe your idea will be added to the list.
In addition to submitting the code for you changes, include a clear prose description of all changes that you made, including the reason for each change.
| ★ 1. | Make the v1 and/or v2 implemenation continue to function when a non-coordinator site that is holding the lock fails (i.e., does not respond within a suitable amount of time). Implementing this task for both v1 and v2 counts the same as implementing it for one. |
| ★ 2. | Change the v1 and/or v2 implementation so that a non-coordinator site sends field changes to the coordinator instead of the entire field state. Implementing this task for both v1 and v2 counts the same as implementing it for one. |
| ★★★ 3. | Make the v3 implemenation continue to function when a site that is holding the lock fails (i.e., does not respond within a suitable amount of time). Of course, you should not solve the problem by introducing a single coordinator site (which could itself fail). |
| ★★ 4. | Change the v1 implementation to continue operating reasonably even if UDP messages are sometimes lost, perhaps by using acknowlegdment and retry messages. In principle, messages really can be lost with the current UDP implementation, but it will be easier to create message loss by changing send_msg to randomly return without sending a message (1% of the time on average, say). |
| ★ 5. | In addition to option 4, change the v2 implementation to continue operating reasonably even if UDP messages are lost. |
| ★★ 6. | For the v2 implementation, adjust the way that a newly started site becomes coordinator so that it gets the current field state from the current coordinator, instead of starting with a fresh board. |
| ★ 7. | Simplify the v2 start-up process so that fewer “elect” messages are sent when a site starts up, none of the other sites fail right away, and the new site will not be the coordinator. |
| ★★ 8. | Make the v1 and/or v2 game fairer by ensuring that players take turns, but still accomodating failure of sites (where a failed site is skipped on its turn). Implementing this task for both v1 and v2 counts the same as implementing it for one. |
| ★★★★ 9. | Implement a new variant of the program that uses a token ring to designate priviledge to modify the field. The ring should reconfigure itself when a site appears or disappears. |
| ★★★★★ 10. | Distribute the game activity among sites based on regions of the field, instead of players on the field. This change may require considerable reworking of the code. |
| ★★★★ 11. | Adapt the v3 implementation to define “majority” as “majority of running sites,” where the site count must adjust apprpriately as sites fail or return online. |
| ★ 12. | Change the v1 and/or v2 implementation to use TCP instead of UDP. Implementing this task for both v1 and v2 counts the same as implementing it for one. |
| ★ 13. | Change the v1 and/or v2 implementation so that non-coordinator sites can survive and continue playing if the coordinator fails and then is resumed later. Implementing this task for both v1 and v2 counts the same as implementing it for one. |
| Last update: Tuesday, December 8th, 2009mflatt@cs.utah.edu |