Distributed Booth Overview We implemented a distributed electronic voting system according to the course project description. The system consists of booths (implemented as individual processes) that can sentience with each other to maintain a total vote result consistently and robustly. This is a course project as required by the CS271 fall 2006, Computer Sciences Department, UCSB. [Project description] DownLoad The source code and executable files can be download from here. The program is written in C# and .Net 2.0 [Source Code Download]
Project Objective
We implement a distributed electronic voting system according to the course project description. The system consists of booths (implemented as individual processes) that can sentience with each other to maintain a total vote result consistently and robustly.
Features
Dynamic booth connection
Individual booths can open and close at any time. When a booth joins the voting system, other booths will get noticed and begin to communicate with it. When a booth closes or crashes, the other booth will also exclude it from the connection list until it revives again. Crash-tolerant against complete data loss in local nodes
We use a slightly-modified replicated log protocol to maintain the system consistency. A crashed booth may lose voting information completely, but later when it opens again, the voting information can be fully recovered, as long as any other machine is alive. Automatic account maintenance for multiple voting
Voters can go to different booths to vote. When he/she signs in at one booth, his/her account will be signed out automatically in another booth Updated tally
After tally officer is signed in at one booth, he/she can keep querying and get the newest voting results, without signing out and signing in repeatedly. Commit result feedback
After a voter commits, the booth will tell him/her the commit result, either success or fail due to inconsistent voting.
|
System Design
There are three layers in our system: the communication layer, the ReplicatedLog protocol layer, and the voting layer. The Communication layer
Basic communications between layers are conducted by this layer. There are three operations:
Send(ip, port, packing)
Broadcasting(packing)
Receive(packing, ip) The ReplicatedLog Layer
In this layer, the Replicatedlog protocol [1] is exactly implemented based on the previous layer. In this layer, we have similar operations while the messages delivered are piggyback with event log information.
Send(boothid, package)
Broadcasting(package)
Receive(boothid, package); The Application Layer
We design the voting system based on the previous two layers. The protocol is designed as the following figure. | Operations | Actions | | User A signs in at Booth B | Booth B Broadcast(‘lock A’); Wait until Receive(‘acklock A’) from all other booth, or timeout, update A’s status and determine the legal operations for A. Other Booths When Receive(‘lock A’, B), Send(‘ack lock A’, B); If user A is currently signing in, sign out A. | | User A signs off at Booth B | Booth B Sign Off A | | User A casts a vote Booth B | Booth B Append an event E(‘A votes C’, time, processor id) into B’s log list; Broadcast(‘vote’); Other Booth When Receive(vote, B), Send(ackvote, B) | | User A Commits at Booth B | Booth B Append an event log E(‘A commits C’, time, processor id) into B’s log list; Broadcast(‘commit’) Other Booth When Receive(‘commit’, B), Send (ackcommit, B) | | Tally officer requests Tally at booth B | Booth B
Broadcast(‘tally’); wait until Receive(‘acttally’) from all other Booth, or timeout, and then do tally. Other Booth
when Receive (‘tally’, B), Send(‘acktally’, B) | | Booth B boots | Booth B Broadcast(‘boot’); Other Booths when Receive(‘boot’, B), change TimeTable about Booth B and Send(‘ackboot’, B); | Reference
[1]T. J. W. Gene and J. B. Arthur, "Efficient solutions to the replicated log and dictionary problems," in Proceedings of the third annual ACM symposium on Principles of distributed computing, Vancouver, British Columbia, Canada, 1984, pp. 233-242.
|