Read Original First

ECS 152B: Communication Networks

Due: 5:00 p.m. Dec. 3, 2003

Basic Bulletin Board and Chat Server

Please read all sections of this document before you begin coding.

In this project, you will develop a TCP-based client-server architecture that allows individuals to meet and talk. The server will keep such files in a directory, and clients will be able to get and put files on demand as well as look at the current contents of the directory. Multiple processes/threads in the server will allow logically concurrent operation between many clients.

Processes in the server will not be completely independent. In particular, supporting the ability to “talk” will require processes to have access to each other's sockets, and the possibility of concurrent get's and put's to the same file will require synchronization of file operations from distinct processes. You will need to make use of locks to protect these data structures.

Objectives The goals of this machine problem are to introduce you to the basics of data structure management in the context of a multi-process server and to reinforce your understanding of managing multiple connections.

Guidelines For this project, you are encouraged to work in teams of two, although you may work alone if desired. Please find a partner as soon as possible. We will allocate a few minutes of the lecture on Wed, Nov. 19 to pair of people without partners. If you attend the lecture and make your lack of a partner known, we will pair you with another person or will make suitable accommodations. If you do not attend the lecture or fail to make your lack of partner known, you may have to work alone. Collaboration, discussion, code sharing, and any other form of group work with persons other than your P2 partner is forbidden. Offenders will be dealt with appropriately (see the general information sheet available from the class home page).

You are required to make sure that your programs compile on machines in the computer lab. Programs suffering compilation errors when tested will earn no credit. You may also find Ch. 23 in the second edition of Stevens (Unix network programming) useful in thread programming.

Please indent and document your code. Use meaningful names for variables and follow other style guidelines that enhance the clarity of your code.

Follow the guidelines in the “Hand In” section below when turning this assignment.

Specification Again you will develop both a client and a server. Make a directory called P2 to hold your code somewhere inside your main directory. Call the code for your server code server.c and call the executable server. Follow the same convention for the client. Note that both source file names and file names are requirements. Create a Makefile that automatically generates the executables from your sources.

As before, this problem consists logically of three components: a client, a main server, and a per- client server process/thread.

All interactions between the client and server should use TCP connections. You should use separate TCP connections to transfer file data, as communication between users may otherwise be delayed by file transfers.

Users will interact with the system through a set of five commands and arbitrary text. The client should provide a prompt to indicate that it is ready to receive input from the user.

The commands include the following:

@ls: List the files in the bulletin board directory.

@who: List the logins of users currently logged into the server. @get: Transfer a file from the bulletin board directory to the client’s current directory. Takes one argument, the name of the file.

@put: Transfer a file from the client’s current directory to the bulletin board directory. Takes one argument, the name of the file. Overwrites existing files.

@delete: Delete a file from the bulleting board directory. Takes one argument, the name of the file.

Any input not prefixed with one of the commands should be delivered to all other users online prefixed with the identity of the user, e.g.,

Lumetta: Where is my server.c file?

A newline character serves as the delimiter. Only complete messages, i.e., messages with a newline character, will be sent to the server and then to other users. Commands must cause the client to issue appropriate requests to the server across the TCP connection, and reasonable messages must be returned to the user. For example, “@get myfile” should return “No such file. Try @ls” or “read myfile successfully.” after transferring the file data.

Client: The client must accept two non-optional command-line arguments -- the name of the server and the login identity of the user:

client

After connecting to the server (and providing appropriate responses to the user on error), the client enters an infinite loop that prints a prompt, waits for input from the user, and handles the input. If the server closes the client's connection, the client must inform the user of the situation and terminate.

Server: The server must execute without command line arguments. Control begins in the main server process, which must initialize the data structures, a process that includes examining its current directory (the bulletin board directory; see opendir(3c) and readdir(3c)). The server must maintain at least two concurrent data structures: a list of clients logged into the system and a list of files in the bulletin board directory. The client list must include both the name and the socket file descriptor for each client as well as a lock to protect accesses and changes to the data structure and a client lock for each client to protect delivery of responses (writes to the client's socket). The file list must include the name of each file, a directory lock to protect changes to the list, and a file lock for each file to protect concurrent reading and writing. Dealing with concurrency can be tricky; we suggest the following locking strategy for the necessary operations:

@get: get directory lock, locate file entry, get file lock, release directory lock, read file data from disk and send to client, release file lock.

@put: get directory lock, locate file entry (create new entry if necessary), get file lock, release directory lock, receive file data from client and write to disk, release file lock

@delete: get directory lock, locate file entry, get file lock, delete file from disk and remove file entry, release directory lock (file lock was destroyed, so no need to release)

@ls: get directory lock, send all file names to client, release directory lock

@who: get name list lock, send all login names to client, release name list lock

log in: get name list lock, add new name, release name list lock

log out: get name list lock, remove name, release name list lock

talk: get name list lock; get client lock, send text, and release client lock for each client; release name list lock

respond: get client lock, send response to client, release client lock

The operations given above are not optimal in the sense that processes that need only read data structures are not allowed to do so simultaneously.

Optional Extras for individual: For those of you who feel particularly motivated to hone your server programming skills, this section provides some ideas for extensions to the main problem. Additional credit will be given for any of them, and you might find them fun. For teams, these options are required. Use a reader-writer lock for the directory lock rather than a mutual exclusion lock. Specifically, if one user is writing, no other access to the file is allowed. However, multiple readers can read a file at the same time.

Require passwords to log into the system. Encrypt passwords (see crypt(3c)) and keep them in a file outside of the bulletin board directory. Decide how you will manage entries in the file.

Track the name of the creator of each file and prevent people from deleting or rewriting files that they did not create. Store the file to creator name map in a separate file outside of the bulletin board directory.

Options for teams:

Allow people to move around the directory structure below the server’s current directory (be careful not to let them move upwards past the server’s current directory, or they can explore your whole filesystem). Keep track of each person’s current location and display it in “@who” output. Limit delivery of typed lines to others in the same directory, and add a new command to deliver a typed line to everyone online.

Add a client-like front end to the server, but give the person using the server directly super- user privileges, such as removing anyone’s files, adding and deleting logins from the password database, etc.

Allow people to create a private chat room. Create a list of available chat rooms at the server. A login can request to join a chat room if the owner of the chat room agrees.

Anything fun, e.g., options that are not described here, but the yahoo/MSN messengers have.

Hand In

Place your source code in your P2 directory along with a Makefile that, on execution of the command make, causes the executable code for the programs client and server to be generated by the compiler. Next, create a PARTNER file with the names and ID's (logins) of both partners. Only one partner should turn in the MP (we will grade only the most recent if both turn in copies), thus the PARTNER file is essential for proper credit. Finally, create a file README containing two parts.

Part 1: Implementation Log This part should briefly describe and justify your design and implementation decisions, including all message formats and details of your data structures. Also discuss any other interesting aspects of your implementation. As always, you should acknowledge the authors if you copied sections of your code from elsewhere (even if you modified it later).

Part 2: Concurrency Analysis Outline a scenario in which the locking strategy given in the Server section above can result in a long delay in response to an @ls" request.

Part 3: A commercial system Suppose you are designing a large commercial bulletin board and chat server, e.g. yahoo messenger. Consider an efficient scalable database management scheme at the server. Write down the issues you need to consider and possible options to implement them.

When you get the C programs, README, Makefile, and PARTNER files within the directory P2 in good working order, you are to transfer the directory electronically as follows. First, remove all object files and executables from the directory, leaving only the source code, the Makefile, and the README file. Submission of executables will reduce your grade. Then mail all the above- mentioned files to TA ([email protected]).