Milestone 1

1. Milestone 1 Jan 12, 2010 Vinod Muthusamy

2. Agenda • Architecture and implementation tasks • Pre-submit test script • Development strategies ECE297

3. Architecture Server Client server.c main() { … } storage.c storage_connect() storage_disconnect() storage_get() storage_set() mytest main() { … storage_connect() storage_get() storage_disconnect() … } TCP Tables Configfile Client library Client application ECE297

4. Client apps use the client library Server Client server.c main() { … } storage.c storage_connect() storage_disconnect() storage_get() storage_set() test/a1_partial main() { … storage_connect() storage_get() storage_disconnect() … } TCP Tables storage.c storage_connect() storage_disconnect() storage_get() storage_set() mark_a1 main() { … storage_connect() storage_get() storage_disconnect() … } Configfile ECE297

5. Build process Output of “make” command in ~/ece297/storage/src 1. cc -g -Wall -c storage.c -o storage.o 2. cc -g -Wall -c utils.c -o utils.o 3. ar rcs libstorage.a storage.o utils.o 4. cc -g -Wall -c server.c -o server.o 5. cc -g -Wall server.o storage.o utils.o -o server 1. compile storage.c storage.o 3. package libstorage.a 2. compile utils.c utils.o 5. build server 4. compile server.c server.o ECE297

6. What to implement 2. Design network protocol 4. Modify handle_command() to process commands from the client library. Server Client library 5. Implement storage_get() and storoage_set() to communicate commands with the server. server.c main() { … } storage.c storage_connect() storage_disconnect() storage_get() storage_set() TCP Tables 3. Modify read_config() to read the table names from the config file. 6. Write a test client application. (Will not be marked.) 1. Design interface to lookup, modify tables Configfile ECE297

7. Pre-submit test ECE297

8. Pre-submit test • Run the testsubmit script on your submission before you submit • Script will • Check for required submission files • Verify directory structure within the .tgz files • Build your code • Run a few test cases on your code • … • Some errors are fatal (no .tgz or .diff file), others are warnings (e.g., test cases fail) • Script does not submit your code ECE297

9. Running the testsubmit script • Create the three submission files in ~/ece297/submit • storage-asst1.tgz • storage-asst1.diff • doxygen-asst1.tgz • Run testsubmit script: > cd ~/ece297/submit > /cad2/ece297s/public/testsubmitece297s 1 • Wait (several minutes) for test cases to finish • (Demo) ECE297

10. Notes on the testsubmit script • Don’t wait until the last minute to run the testsubmit script • Get in the habit of using SVN now • The testsubmit script will fail if you simply try to submit your working directory • There is no harm in running it as often as you want • Practice submission steps now (even with the skeleton code)! • Our auto-marking tests are similar to the testsubmit script • If your code fails the testsubmit tests, it will likely fail the marking tests as well • The testsubmit script only partially verifies your submission • You should still follow the instructions in the handout ECE297

11. Development strategies ECE297

12. What to implement 2. Design network protocol 4. Modify handle_command() to process commands from the client library. Server Client library 5. Implement storage_get() and storoage_set() to communicate commands with the server. server.c main() { … } storage.c storage_connect() storage_disconnect() storage_get() storage_set() TCP Tables 3. Modify read_config() to read the table names from the config file. 6. Write a test client application. (Will not be marked.) 1. Design interface to lookup, modify tables Configfile ECE297

13. 6. Write a test client application • Copy the a1-partial test • mkdir ~/ece297/storage/test/mytest • cd ~/ece297/storage/test/mytest • cp ../a1-partial/main.c ./ • cp ../a1-partial/Makefile ./ • Write a simple main.c and run it • gedit main.c • make • ./main • Use a “fake” server to interact with it • nc -l -p 1111 storage.c storage_connect() storage_disconnect() storage_get() storage_set() mytest main() { … storage_connect() storage_get() storage_disconnect() … } Client library Client application ECE297

14. Some points to remember • Don’t worry about multiple clients • No concurrent connections • No concurrent writes • Don’t change storage.h • Server should handle any tables specified in config file • Your test client applications will not be marked • Some useful size limits are in storage.h • E.g., MAX_TABLES, MAX_KEY_LEN ECE297

15. Split the work • Write server • Communication with client • Read from tables (counterpart to storage_get()) • Write to tables (counterpart to storage_set()) • (Use netcat to simulate the client: nc localhost 1111) • Write client library • Communication with server (storage_get(), storage_set()) • (Use netcat to simulate the server: nc -l -p 1111) • Write test code ECE297

16. When am I finished? • When you’ve implemented the requirements from the handout • Read the specification • Write your own tests • Run the given tests! • a1-partial tests (Section 4.7 of handout) • testsubmit script (Section 10 of handout) • Auto-marking scripts are based on this code ECE297

17. Partial marks • Some implementation attempt and code that builds • Client library only • Check for some error conditions (e.g., invalid parameters) • Client library and server communication • Client library and server communication with table management at the server ECE297

18. Reading the code • Relax • Build and run the code first • Read the code (especially the comments) • Browse the doxygen output if that helps • Try to match the code with what the program does • Understand the program flow • Make small changes to the code • Add your own output statements to see what’s happening • When you don’t understand a function • Use man, the Course Reader resources, or Google ECE297