This assignment will have you implement a simple database. You are required to use block I/O to store player entries for the game that we have been making in class. The intention is to make the data persist while the program is not running. This is by far the most programming-intensive assignment, so you should get started immediately.

Interface

We have provided an interface by which you should design the database. This is to get you familiar with programming to interfaces as well as to provide consistent functionality for testing your solution.

Do not change the interface in any way! We will use this file exactly when compiling your code, not the sdbm.h file you supply.

Player Struct

The datebase will store player entries. The way information is laid out in a struct is fixed based on the following header file.

Do not change the struct in any way! We will also use this file exactly when compiling your code.

Implementation

Your job is to implement the interface. How you do that, however, is up to you. You are required to store the players sequentially on the disk according to their playerID, but beyond that there are no requirements. You may use a single file or many. The file extension and its headers and footers are also left to you.

You may have noticed that keys are strings, not playerIDs. Each player's name is its key. This implies that you will have to come up with some sort of method to look up a playerID based on a name so that you can locate it in the database.

Caching

Accessing a file for every operation can be slow so you are also required to load the database into memory using dynamic memory operations. The space allocated in memory must be able to increase and decrease as elements are added and removed from the database. We recommend doubling the space each time it fills and decreasing it by half each time it is reduced to a quarter. This should prevent realloc from being called on every sdbm_get and sdbm_remove. You are only required to sync the cache with the disk when the database calls on sdbm_open, sdbm_close, and sdbm_sync.

Game Interoperation

The database should work with the game that we have been developing in class. When the game is started it requests the number of players and their names. Your database must be able to load the players from file. Note that only a subset of the players in the world will be in any given game. The database must be able to support thousands of players, but our game will never load that many at a time. You should not have to change the game implementation.

Testing

You must also supply code that tests your solution. We want to test both for coverage and for stability. Therefore, you must write unit tests for every function that you write. When grading your assignment we will use the tool gcov to ensure that you have 100% test coverage. 100% coverage will get you full credit.

You should also test the stability of your database. Inserting a single element and removing it might make you think that your solution is "perfect", but you might not notice bugs until you actually put the database through its paces. Randomly generate 10,000 players (names and stats), insert them into the database, and remove them all. We will be using gprof to verify the number of function calls.

Each of these tests should have its own executable, built by a rule in the makefile. make coverage should build the coverage executable and

make
stability

should build the stability executable. The Makefile rules for coverage and stability must compile them with -fprofile-arcs -ftest-coverage and -pg, respectively. Of course, make game should build the game executable. Use the game.c file from Tuesday's lecture in the blockio folder on bitbucket once we have modified it in class to use sdbm.

Grading

General assignment requirements, style and submission details:

Readings: Make sure you do the reading for each week, preferably before lectures and attempting homework.
Reflections: Reflect briefly on each program you write, as a comment at either the beginning or end of each main file. Comment on things like: how hard was the program and why? what did you learn from it? where did you need help? how long did it take to complete? what was the best part of the assignment and why? how would you redesign this assignment if you were the teacher? You should have a paragraph of well-written (properly formed English) reflections for each program. These reflections are part of your assignment grades.
Style: All files with main must be named according to the assignment number they solve (and part if relevant), such as pg1a.c or pg5.cpp. Other files should be named descriptively. Use a consistent layout style for your programs, as well as recommended naming practices for variables and functions. For C programs, we suggest following Kernighan & Ritchie's style.
Identification: You must include a header comment with your name, this course number (600.120), the date, the assignment number, your phone number, Blackboard login, and preferred email address in every source file you write.
Compilation: Source code must compile with our standard compilers and options, on the ugrad machines. These are:
```
gcc -std=c99 -pedantic -Wall -Wextra -O
g++ -std=c++98 -pedantic -Wall -Wextra -O 
```
Remember: you will receive NO credit for programs that do not compile. Use incremental coding to insure that you always have a working program, even though it might be incomplete.
Electronic Submission: Submit an electronic copy of all assignment parts on Blackboard, together in one zip file. You may submit on Blackboard multiple times for any assignment - we will only grade the last (most recent) submission unless you request otherwise. You must include all parts for an assignment in each zipped submission attempt. If you need to explain anything in general about an assignment, include a README plain text file with your submission.
Deadlines: Assignments will be due at 9am on the due date. There is a 1/2 hour grace period for program submission from 9-9:30. If you submit in this timeframe, you will get a standard 5 point late penalty, even if it is only 10 seconds late. After the grace period, programs will not be accepted and you will receive no credit. Exceptions will be given only for illness, and only by Joanne.
Printouts: Submit a printout of all your original program source files (C code, not the program output) for each assignment part when you come to class on the due date. You must staple together all the printouts for each assignment.
Ethics: Assignments will be individual unless otherwise noted. Remember that you may use or adapt code from your texts and lectures, but you MUST include a comment to cite the original source. You may not use code from other sources. This not a research course, it is a skills development course.

sdbm Functionality	30
sdbm Implementation (cache)	20
Test Coverage	30
Test Stability	15
Makefile	5

600.120 Intermediate Programming
Summer 2013 -- Assignment 4
Due by 9am on Friday, 6/14

SDBM Database

Interface

Player Struct

Implementation

Caching

Game Interoperation

Testing

Grading

600.120 Intermediate Programming Summer 2013 -- Assignment 4 Due by 9am on Friday, 6/14

SDBM Database

Interface

Player Struct

Implementation

Caching

Game Interoperation

Testing

Grading

600.120 Intermediate Programming
Summer 2013 -- Assignment 4
Due by 9am on Friday, 6/14