Lab 6

Goals

Strengthen your skills in C programming, systems programming and network programming.

Credits

This lab was developed by Prof. L. Felipe Perrone. Permission to reuse this material in parts or in its entirety is granted provided that this credits note is not removed. Additional students files associated with this lab, as well as any existing solutions can be provided upon request by e-mail to: perrone[at]bucknell[dot]edu

Academic Responsibility

It should go without saying that all the work that you will turn in for this lab will be yours. You should try your best to debug your code on your own, but it’s fine to get help from a colleague as long as that means getting assistance to identify the problem and doesn’t go as far as receiving source code to fix it (in writing or orally).

Set Up

There is no skeleton code that will be given to you for this lab. Instead, you will start from your solutions to previous lab assignments. Feel free to leverage any code given to you and created by you in this class.

Context

In this assignment, you will continue turn the flight reservation system into a client/server application. You will start from the code you developed for Lab 3 and will combine and refactor it with code from Lab 4 or Lab 5 to create the two applications whose purposes are sketched out below:

flightServer – this will be a program that will hold all the flights and reservations in the system. It would be central to the business of a travel agency. It will aggregate all the knowledge of flights and make it available to travel agents who would create reservations.
flightClient – this will be a program that will hold little data and for little time. It would be the tool used by travel agents to investigate flights and to create new passenger reservations on existing flights.

You should envision that flightServer will be run on one computer and flightClient in another. The pattern of interactions with these programs will be as follows:

The system administrator runs flightServer on a given computer on a port number of your choice (choose a number greater than 5000 randomly to avoid conflicts with your colleagues applications). Through the application menus, the system administrator will be able to:
- Add new flights,
- View available flights,
- Save flights to a file,
- Load flights to a file, and
- View existing reservations.
After the server has been started on a computer, a travel agent will use that computers IP address and the flightServer port number to start a flightClient. Through the application menus, the travel agent will be able to:
- View available flights, and
- Make a new reservation.

Developing the server

In this problem you will create your flightServer program. The command line of this program will be as follows:

$ flightServer [port number]

If the user fails to provide a port number at startup, the application terminates showing the following message:

Usage: flightServer [port number]

Upon successful start, the application will display a text menu providing the options and functionalities below:

Add new flight – asks the user to provide information for each flight, creates a new instance of struct flight and inserts it in flight_list,
View available flights – traverses flight_list, a singly-linked list that aggregates all the flights on which the system has information, displaying on the screen the data for each flight,
Save flights to a file – traverses flight_list and adds the information for each flight into a file with name specified by the user,
Load flights to a file – using a file with name given by the user, extracts the information for each flight from the file, creates a new instance of struct flight and adds it to flight_list;
Exit menu – leaves the server interactive mode and enters the service loop.

From the menu above, the user enters their selection by pressing a key from 1 to 5 followed by return. This input is processed in a switch/case statement that dispatches each key press to the corresponding function as in your solution to Lab 3.

The behavior of the program should be as follows:

When the server starts to run, it will be in interactive mode. That is, it will display the menu and loop waiting for keypresses from 1 to 5, attending to the commands of the user. We will call this the “interactive mode loop.” During the execution of the server in interactive mode, the travel agent will be able to set up the data for all the flights in the system. It will be useful to have a collection of flights defined and saved to a file to make development and debugging of the system go most easily. (You wouldn’t want to have redefine all flights every time you run the server.)
When the travel agent selects the option to exit the menu, the program will leave the interactive mode loop and enters the “network service loop.” In this new mode of execution, the server will wait for a request from the flightClient program, will service the request (potentially sending data back to the client), and then will go back to wait for the next request. Requests received by the server can be of three types:
- View available flights – in response to this request, the server will send to the client all the flights that it knows of. This will mean, traversing the internal list of struct flight and sending to the client all the values in these structures. You will need to define how the server will send back to the client a variable number of flight structures.
- View existing reservations – in response to this request, the server will send to the client all the flights that it knows of. This will mean, traversing the internal list of struct reservation and sending to the client all the values in these structures. You will need to define how the server will send back to the client a variable number of reservations structures.
- Make a new reservation – this request will come from the client with the data to fill out an instance of struct reservation, which the server will simply add to its running list of reservations.

Since this program is a server (daemon), it must run on an infinite loop. In each iteration of the network service loop, the program will wait for a request to come from the client. You can choose the type of socket you believe will make your development easiest and the program most resilient to failure.

Developing the client

In this problem you will create your flightClient program. The command line of this program will be as follows:

$ flightClient [symbolic address of server] [port number]

By “symbolic address of server” we mean is a complete and specific domain name that uniquely identifies a host on the Internet, which is called fully qualified domain name; for instance: linuxremote.bucknell.edu. If the user fails to provide either the symbolic address or the port number of the server at startup, the application terminates showing the following message:

Usage: flightClient [symbolic address of server] [port number]