Programming Assignment 2
This assignment is to be done individually. Do not show your code to others
and do not look at other students' code. Prevent other students from accessing your code (do not put it in a public directory). However, you are free to use any
tools you like (library, search engines), to discuss problems with others, and
to seek the help of the TA or the instructor.
Objective
The objective of this assignment is to familiarize yourself with the
socket API and file I/O and to implement
both a client and a server program (C or C++), where the
server uses multiple techniques for request handling.
Assignment: Client-Server Programming
The idea is to create a calendar server based on TCP. You need to define a
protocol (i.e., define how messages are formatted and transmitted),
implement it, and write a client and a server that communicate
using your new connection-oriented protocol.
Your protocol should support the
following functionalities:
1. Add a new calendar event.
2. Remove a calendar event.
3. Update an existing calendar event.
4. Get the events for a specific time or time range.
There are no other requirements regarding the protocol, i.e., you are free
to decide the protocol details, e.g., the message structure and content
for the client/server communication.
Client Implementation
The client is a simple program that takes several arguments and contacts
the server and prints the response received from the server. The syntax for
the client should be:
A: Adding an event: ./mycal hostname port myname add 031505 0800 0900 Exam
B: Removing an event: ./mycal hostname port myname remove 031505 0800
C: Updating an event: ./mycal hostname port myname update 031505 0800 1000 OralExam
D: Getting an event 1: ./mycal hostname port myname get 031505 0800
E: Getting an event 2: ./mycal hostname port myname get 031505
In all cases 'myname' is a string that identifies a user (e.g., login name).
In (A), you specify the date, the beginning and end time of the event, and
a single word identifying the type of event (e.g., exam, doctor, trip, meeting, ...).
You can assume that no event can go beyond 2400 of the same day (i.e., every
event has to be finished by midnight at the latest).
If there is a conflict with another already
stored event, the client will be notified by the server and the client informs
the user (e.g. "Conflict detected!"). In (B), you specify
the date and the beginning time of an event, if successful the client will
receive an acknowledgment from the server, if the event does not exist, the
client will be notified by the server and the client informs the user. In (C),
you specify an event as in (A), however, either the ending time or the event
type has to be different (or both). Again, the client will inform the user
if the operation was successful. In (D), the server returns the type of
the event requested, if the event does not exist, the client informs the user.
Finally, in (E), if only the date is specified, all events of that day are
returned.
Further, the server's hostname and port number have to be passed to the
client as command line arguments.
Server Implementation
The server waits for requests from clients. Each user ('myname') has a file
at the server (e.g., 'myname.cal') whenever the user hast at least one
current event. That is, when the first event is set, the file has to be
created, when the last event is deleted or expired, the file has to be
deleted too. You can place the files wherever you want (e.g., your home
directory or /tmp). You also have to decide on how to manage the files
(e.g., how to structure the content, if to order the event list, etc.).
Whenever a server accesses a file (e.g., to add or remove an
entry) it also checks for expired events and removes such events from the file.
If the file is empty, it will be removed. You are required to provide two
different server implementations, the first server uses an iterative approach,
i.e., only one request can be handled at any time and only one server process or
thread exists at any time. The second server uses
a multiprocess/multithreaded approach, where
each new request is handled by a newly
created process/thread (it is up to you to decide between processes and
threads).
In the second approach, each slave process/thread should sleep for
3 seconds before responding to a request.
Extra Credit (15%)
Provide a third server implementation based on the select()
approach. A single-threaded server uses select() to monitor multiple open
socket
connections (hint: use the iterative server as basis for the implementation of
the select() server) and the protocol has to support one additional functionality: "Get all event for a given client".
The syntax of the new command is:
./mycal hostname port myname getall
Here, the client first asks
the server how many entries the calendar file for client
'myname' has and if the response is nonzero, the client requests each entry
individually, with 2 seconds delay between requests. Once all events have been
received, the client notifies the server of the end of the connection.
Error Handling
The following error handling is expected: all return values of the system
calls have to be checked, the correct number of command-line parameters for
the client, the correct date and time format (also make sure that the end
time of an event is later than the begin time). Compile your code with the
'-Wall' flag and make sure to remove all warnings.
Evaluation
Run your program for the following scenarios (in the given order, host names
have been omitted in the example shown here):
./mycal steve add 031505 0900 1100 Test1
./mycal steve add 031505 1300 1400 Meeting1
./mycal steve add 031505 1600 1830 Class
./mycal tim add 031505 1500 1630 Class
./mycal tim add 031605 1500 1530 Seminar
./mycal steve add 031605 0800 0930 Dentist
./mycal tim add 031505 1430 1530 Gym
./mycal tim remove 031505 1500
./mycal martin add 031705 0900 1130 Shopping
./mycal steve update 031605 0800 1000 Dentist
./mycal tim add 031705 0900 1200 Squash
./mycal martin update 031705 0800 1130 Shopping
./mycal tim get 031605 1500
./mycal martin get 031705 0800
./mycal steve get 031505
Provide the output of your client program for this input sequence in your
'readme' document. Write one script that contains the input sequence
described above in the correct order. If you submit the third (optional)
server implementation, provide a second script with again the same
sequence from above plus an additional command using the 'get all'
operation for each of the users in the example (steve, tim, martin).
Provide the client output for EACH server implementation, make sure to remove
all client files before you start a server (or let a server remove the
files for your automatically when you stop a server).
Write a document (ps, pdf, ascii) and add the output of these scenarios
to the evaluation part of the document (for all server implementations).
If you made any specific assumptions or encountered problems or have unresolved
issues,
mention them in the document. The page limit is 2 pages.
Grading
The grading will be according to the grading policy on the course webpage.
Remember that documentation and exception handling are each worth 20% of the
assignment's grade!
Submission
The due date for this assignment is February 18, 2005, 11.59pm EST.
You will use the drop-off boxes (you will find a box with your login name). Make
a directory called "project2" and place all required files into this directory
(either individually or as one tar file). The required files are: all source
files, a Makefile, one run script for the required test case (two if you also
submit the optional part), and a document
called README (ASCII file) or readme.ps or readme.pdf (postscript file), which
contains a project summary, your solution approach, a description of your
protocol implementation, any encountered problems
and how you solved them, any unresolved issues, an evaluation with the output
of the program for the test cases mentioned above (for all server
implementations), and a usage explanation. The
document should be not more than 2 pages.
Late submissions: 25% penalty after the deadline and another 25% for every 24h
after the deadline.