Client-Sever with Named Pipes

Description

Write two programs that communicate via named pipes in a client-server relationship.

General Specifications

• The default make target should create both executables.

• Your programs must all be properly modular and documented appropriately.

• The allowable languages for this assignment are: C, C++, OCaml (Unix module), Go (sys/unix package), Rust (nix:unistd crate).

server Specifications

• The name of the compiled program must be server.

• The input to the program must be in the form of command line arguments as follows:

  • -h (by itself with no other arguments) print the usage instructions
  • -p <string> (required) the name of the pipe
  • -m <string> (required) the name of the pokemon binary file
  • -t <string> (required) the name of the trainer file

  Note that the command line arguments must be able to be entered in any arbitrary order.

• The main steps for the server process should roughly be:

  1. Set up and open the binary data files. If the trainer file does not exist, create it.
  2. Open a named pipe.
  3. When a client sends a message to the named pipe, fork a child process to handle the client.
  4. Wait for the child process to finish before handling a new client.
  5. When a SIGINT signal is received, gracefully shut down the program (handle a currently connected client, close the named pipe, etc.)

• The child process should handle client requests until the client is done (or the server is interrupted.) The types of client requests are listed in the client section.

• Note when processing the binary files, only one record may be in memory at a time.

client Specifications

• The name of the compiled program must be client.

• The input to the program must be in the form of command line arguments as follows:

  • -h (by itself with no other arguments) print the usage instructions
  • -p <string> (required) the name of the server’s pipe

  Note that the command line arguments must be able to be entered in any arbitrary order.

• The client must be a read-eval-print loop (REPL) application, that is, is a simple interactive application that takes single user inputs, executes them, and returns the result to the user. These are the commands that the client must implement:

  • exit – quit the application (indicate this to the server)

  • get pokemon <id> – request data for a pokemon with the “number” equal to the <id> argument and display it in a well-labeled format if the “number” exists. The server responds with the appropriate data on success or indicates that the record does not exist.

  • get trainer – request all (valid) trainer data and display it in a well-labeled format. The server responds with the appropriate data.

  • get trainer <id> – get the data for the trainer with the ID equal to the <id> argument and display it in a well-labeled format if the <id> is valid. The server responds with the appropriate data on success or indicates that the record does not exist.

  • post trainer <name> <pokemon 1> [<pokemon> ...] – send data for a trainer that includes the trainer’s name and at least one pokemon (at most six) and send the data to the server. On success, the server responds with the ID of the newly created trainer data. Otherwise, the server responds with an indication of failure.

  • put trainer <id> <pokemon 1> [<pokemon> ...] – send data for a trainer that includes the trainer’s id and at least one pokemon (at most six) and send the data to the server. On success, the server indicates that the data was successfully updated. Otherwise, the server responds with an indication of failure.

  • delete trainer <id> – delete the record with the corresponding <id> On success, the server indicates that the data was successfully updated.

Notes

• Leaving any named pipes on the file system will result in a point deduction.

Turning in the Assignment

For this assignment, you must turn in a zip file of a directory named project3 containing the appropriate files (this should include the Pokemon binary file). Include a README file that discusses any design decisions that you made and a description of your protocol.

Submit the zip file to the appropriate folder on D2L.