COP 5615 - Operating Systems

Project 1 - Simple Client-Server

NOTE: THIS DOCUMENT IS UNDER REVISION.
IT IS PROVIDED IN ADVANCE SO THAT YOU CAN GET STARTED

Overview

Your first programming project is to write a simple server and a client using socket programming. The program may be written in C, C++, or Java. There will be two assignments based on this project.

The client will send the server requests to upload, read-lock, write-lock, release a lock, read, write, or delete a file. The server will receive requests from the client, and carry out the request if possible. The client may persist to send a sequence of requests to one or more servers. Servers must persist until they receive a request to terminate, handling requests from clients one at a time.

Program Requirements:

• Your client and server must compile and run on the CISE lab hosts.
• Use TCP sockets on both ends of the connection.
• The client must be able to resolve the name of a machine into its IP address.
• Your client must have a simple command line interface (CLI) to allow for user interaction.
• The client must accept the server's address and port from the command line interface. The address and port must be determined at runtime. The address may either be the IP address or a fully qualified domain name.
• The client must be able to disconnect from one server and connect to another server from its CLI.
• The server must determine the port on which it will listen from the command line.
• The server must loop, accepting calls from clients indefinitely (one call service per loop) until it receives a request to exit. On each call service, the server must print to stdout information on the client it is servicing (IP, port#), then the request, followed by a newline.
• The server must accept and carry out requests if possible.
• A request for any lock shall be granted if the file has no locks on it.
• A read-lock will be granted if the file does not have a write-lock on it.
• A file that already had a write-lock cannot be locked again until the write-lock is released.
• Only the client that was granted a lock can release that lock.
• The server must accept and carry out requests to print out all files it currently has, any locks held on each file, and last modification time.
• The server must also accept and carry out a request to exit cleanly.
• All ports should be released before your program exits.
• The client should report and handle all reasonable error conditions.
• The server should report and handle all reasonable error conditions.

Documentation Requirements:

• The code must include reasonable comments describing its actions.
• Include a REPORT file. In addition to the elements described on the projects page, it should include:
  • 1. What your system does
  • 2. A description what processes are involved and how
  • 3. A description what state is maintained by each process
  • 4. A description of each message type that is exchanged
  • 5. A description what actions are taken upon receipt of each message
  • 6. A description when a given message type is generated
  • 7. User interface (if any) to each process type
  • 8. Test runs used to test elements of your system, along with expected (or actually generated) output.
• Include a README file:
  • 1. A synopsis, describing how your client/server is invoked
  • 2. A list of any known bugs
  • 3. A list of extra features
  • Please make sure your README is short and concise.
• If appropriate, include a makefile with the following targets:
  • 1. all, to compile both the client and the server
  • 2. clean, to remove *~ *.o and core files
• submit the project (all files) by creating a single archive file and submitting on Sakai.

Bonus

Q and A

Q:
I was under the impression multiple clients would not be connecting to a server simultaneously--which would mean the lock status and caller id would need to be persistent (saved on disk). Would you please clarify this?

A:
The key is that the server handles one *request* at a time, so that the following sequence (as seen by the server) can occur:
client A granted a read lock on file X
client B granted a write lock on file Y
client C denied write lock on file X
Client D granted read lock on file X
client B read file Y
Client D read file X
Client D release lock on file X
client A read file X
client B write file Y
client A release lock on file X
client C granted write lock on file X

Otherwise, a client just monopolizes the server for its entire session, and it makes no sense to have any kind of locks, since whichever client is connected to the server essentially locks ALL files as long as it remains connected.

Q:
My assumptions - please let me know if these are wrong.
read-lock: clients are not allowed to read this file
write-lock: clients are not allowed to write to this file but can read it

A:
These are related to the classical readers-writers synchronization problem. Any number of readers may read-lock the file and obtain read-only copies (or read a portion of the file). They must read-lock before reading, and should release the read-lock when they are done. Only one writer can write-lock the file at a time, and it can't be done with readers using the file (i.e., there can be no locks on the file). A writer must write-lock the file before modifying it, and should release the write-lock when they are done. Interesting policies arise concerning what to do when a writer is waiting to access the file: - if there are current readers using the file, are more readers allowed to read-lock and use the file also (reader-preference), or must readers arriving after the writer wait until the writer is done (writer-preference)? - if a writer releases its write-lock and there are both readers and writers waiting to access the file, who gets the lock? There are several variations, including fair (FCFS) and quasi-fair versions (more or less FCFS) that have been defined. The general idea is to allow concurrency when there is no conflict (multiple readers), but prevent concurrent accesses that could conflict (read-write and write-write conflicts). A read-lock entitles the client to read any or all of the file, while a write-lock entitles the client to read or write any or all of the file.

Q:
When a client sets the lock is it supposed to affect all other clients or all clients including itself? For example: client A sets a write-lock on file.txt. Does client A have permission to write to file.txt or is it locking the file out completely?

Additionally you say in the description, "a read-lock will be granted if the file does not have a write-lock on it". If the locks are only for locking out other clients, does this mean client A can set a read-lock even if it has already set a write-lock on it?

A:
Clients must be able to interleave requests with one another (see above). A client's lock affects other clients (may cause them not to get a lock that they request) as well as themselves (a client with a read lock is not allowed to write the file). Note that a client with a write lock is allowed both to read and to write the file.
A client with a read lock that desires a write lock must release the read lock and then request the write lock. Q:
What happens to locks when the client that created the lock disconnects from the server? I would think any locks generated by that client would be removed, but I want to double check.

A:
Clients must disconnect from the server after each request is serviced, so the locks must persist across connections.

Of course, this raises the question of what happens if a client never releases a lock (for whatever reason). Do not worry at this point about clients that die, etc., but do make sure that clients release all locks before terminating. You may include a generic "release all my locks" message to the server if you wish.

Hints:

Do not use ports numbered less than 1024, as these are reserved ports on most Unix systems, and require root access to open.

The client may use port 0 to allow the OS to determine the ephemeral port that it will use to communicate with the server. The server's port that the client contacts must match the port on which the server is listening.

You should start the server first, to determine that the port specified is available and to have the server waiting for a connection before the client tries to contact it.

You may want to read the man page for tar in order to create the archive file, by typing "man tar"