Bulletin Board Messages And Distributed Agreement: A CSC 590 Challenge

Bulletin Board Messages and Distributed Agreement:
A CSC 590 Challenge

Introduction
This challenge consists of two phases. In the first phase you will construct a simple network server. The next phase will consists of convincing multiple such servers to work together. Read the document completely before starting any coding; everything in the document is part of the specification and it is your responsibility to ensure that you have implemented the whole server as specified. The challenge is set up so that it gives you the opportunity to showcase your skills at system programming in a POSIX1 environment. Indeed, you must implement the server as a UNIX service (“daemon”) and you further must use the POSIX API provided by the UNIX standard C library. Therefore your server must be written in C or C++.

1. In case you are wondering, POSIX originally came from “Portable Operating System Interface for uniX”. As time went by the standard was adopted by other operating systems, so that the “for uniX” part is no longer pertinent. Thus many people claim that nowadays POSIX stands for “Portable Operating System Interface with an X added at the end for coolness”.
1 Throughout the handout we will refer to the following configuration parameters. How these parameters are obtained will be described in Section 3.1.
• bp is the port number for client-server communication (positive integer), see Section 1;
• sp is the port number for inter-server communication (positive integer), see Section 2;
• bbfile is the name of the bulletin board file that will be manipulated throughout this project (string),
see Section 1;
• Tmax is the number of preallocated threads (positive integer), see Section 1.4;
• peers the list of peers participating in synchronization (possibly empty list of pairs host name–port
number), see Section 2;
• d is a Boolean flag controlling the startup of the server, see Section 1.5;
• D is a Boolean flag controlling debugging facilities, see Sections 1.3 (last paragraph) and 

3.2.
1 Phase 1: A Bulletin Board Server
Your first task is to construct a simple bulletin board server. The server accepts one-line messages from multiple clients, stores them in a local file, and serves them back on request. The name of the file is given by the parameter bbfile. Messages are identified upon storage by an unique number established by the server, and by the “sender” of the message (as provided by the USER command explained below). The clients connect to our server on port bp. We also assume a production environment so that we implement concurrency control.

1.1 Application Protocol
Below is a description of the basic application protocol i.e., of the commands send by the clients as well as the answers returned by the server (fixed-width font represents text which is well, fixed for the given command or response, while parameters that may vary are shown in italics). Every command and response consists of a single line of text. The server should handle any combination of the characters ’\n’ and ’\r’ as line terminator and should send back responses terminated by a single ’\n’.

Greeting

At the beginning of the interaction the server send the following text to the client that just connected:
0.0 greeting
where greeting is some (possibly empty) message intended for human consumption. There is no particular format for the greeting text, but it is strongly suggested for this text to summarize the commands available to clients.

USER name
This commands identifies the client. The argument name is a string not containing the character /.
Future messages posted by the respective client will be identified as posted by name. Normally, a client will send this command at the beginning of the session, but the server should handle the case in which this command is sent more than once during the interaction with a particular client, as well as the case when a client does not send a USER command at all (case in which the poster will be nobody).

The server response is the line
1.0 HELLO name text where text is some (possibly empty) message intended for human consumption.
2

READ message-number
This command asks for the message number message-number. In the event that this message exists on the bulletin-board, the server will send in response one line of the form
2.0 MESSAGE message-number poster/message where message represents the requested message, prefixed by its poster (as identified by the USER
command in effect at the time of posting).
If message message-number does not exist, then the server sends the line:
2.1 UNKNOWN message-number text
where text is a message for human consumption. If the server encounters an internal error while serving the request (e.g., the unavailability of the bulletin board file), then the following response is sent back to the client:
2.2 ERROR READ text
Again, text is an explanatory message with no particular structure.
WRITE message
This command sends message to the server for storage. The server will store the message into the bulletin board file as a line of the form: message-number/poster/message
where message-number is a unique number assigned by the server, and poster is the poster of the message as specified by a previous USER command issued by the respective client (nobody if no USER command has been issued by that client). Upon successful storage, the server returns the following message to the client:
3.0 WROTE message-number
When an error occurs during the storage process, the server responds with this message instead:
3.2 ERROR WRITE text
The receipt of such a response must guarantee that no message has been written to the bulletin board.