Autograder Output

For assignment 5, we provide the output of the autograder. This might be helpful for the review of the implementation part of the project, though you need not use the autograder output in the preparation of your report.

Findbugs. Make sure to check the supposed bugs given by findbugs. Some bugs may indicate implementation errors (e.g. untested corner cases). Other bugs may indicate an inefficient or dangerous implementation. Other bugs can be safely ignored.

Test1 of VotingSystem.This was the test provided on Dropbox. The output should be self-explanatory. If the code under tests is correct, the test output should be:

[card_AAA] Card creation process complete.
[card_AAA] Encoder call output [should be: null] : null
[card_AAA] Machine call output [should be: Allowed one vote] : Allowed one vote.
[card_AAA] Machine call output [should be: null] : null
[card_AAA] Encoder call output [should be: null] : null
[card_AAA] Machine call output [should be: Allowed one vote] : Allowed one vote.

[card_AAA] Card creation process complete.
[card_BBB] Card creation process complete.
[card_AAA] Encoder call output [should be: null] : null
[card_BBB] Encoder call output [should be: null] : null
[card_BBB] Machine call output [should be: Allowed one vote] : Allowed one vote.
[card_BBB] Encoder call output [should be: null] : null
[card_BBB] Machine call output [should be: Allowed one vote] : Allowed one vote.
[card_AAA] Machine call output [should be: Allowed one vote] : Allowed one vote.
[card_AAA] Encoder call output [should be: null] : null
[card_BBB] Machine call output [should be: null] : null
[card_AAA] Machine call output [should be: Allowed one vote] : Allowed one vote.

The autograder is NOT fully tested. If a group's output does not match the text above, it may still be correct. Please email me (jhug@cs.) if you find functioning code that does not produce the above output. Please post on Piazza if you need any help debugging submitted code.

Test 2 of VotingSystem.This test determines whether or not a newly-created card is enabled by default. If the card is disabled by default, the output should be:

[card_XXX] Card creation process complete.
[card_XXX] Output with fresh card: null

==> Test has completed.

If it is enabled by default, the output should be:

[card_XXX] Card creation process complete.
[card_XXX] Output with fresh card: Allowed one vote.

==> Test has completed.

It is not necessarily a design error for a fresh card to be enabled by default (so long as an adversary can't somehow exploit this fact to get more votes than allowed by encoder insertions).

Test 3 of VotingSystem. This test randomly inserts a single card into the encoder and machine, and records the result of each insertion. Every time a card is inserted into the encoder an "E" appears. Every time a card is inserted into the machine, either an "M" or an "m" appears. If an "M" appears, this means the card was allowed to vote. If an "m" appears, this means the card was not allowed to vote. For example, consider the output below.

[card_XXX] Card creation process complete.
Transcript of calls to encode (E), machine and vote allowed (M), machine and vote not allowed (m):

mmmmm mEEMm EMEMm EMEMm mEEEM EEEEE MEEME MmEEM mmEEM EEEMm EEEME EEEEM EEEEE EEEE
M EMEEM EMEME EEMEE MEEEE MEEME EMmEM

In the above output, the card is inserted in the machine 6 times, and a vote is denied every time. Next, the card is inserted into the encoder twice. Next, the card is inserted into the machine twice and a vote is allowed the first time but not the second. Tracing through the entire output, we see that the voting system behaves as required. Specifically, correctness is assured by the fact that we never see Em or MM. This test relies on test 1 working correctly. If your report shows incorrect output for test 1, you should not trust test 3.

Test 3 also provides a crude speed benchmark. When the test was run, the autograder gave the code only 60 seconds to complete the 3 tests. Test 1 involves 14 insertions. Test 2 involves 1 insertion. Test 3 involves 100 insertions. A particularly fast implementation (like the one above) will show all 100 insertions in test 3. Slower implementations will time out before all 100 are completed. If your submission under review shows fewer than 100 insertions, try to identify the bottleneck -- specifically which device (machine, encoder, smartcard) and which part of their design (most likely something to do with RSA).

You can calculate the time taken per insertion on a modern 4 GHz processor by dividing the number of insertions by 60 seconds (if the submitted code completes all 115 total insertions, this is an upper bound). A SmartCard is likely to be considerably slower. Consider whether or not a user of the reviewed voting machine is going to have to wait a long time to cast a vote.



Copyright 2000-2004, Edward W. Felten.  All rights reserved.