CS代写 EE450 Socket Programming Project

EE450 Socket Programming Project
Spring 2024
Friday, April 26, 2024, 11:59PM
(Hard Deadline, Strictly Enforced)

Copyright By PowCoder代写 加微信 powcoder

The objective of this assignment is to familiarize you with UNIX socket programming. It is an individual assignment and no collaborations are allowed. Any cheating will result in an automatic F in the course (not just in the assignment). If you have any doubts/questions, post your questions on D2L. You must discuss all project related issues on the Piazza discussion forum. We will give those who actively help others out by answering questions on the Piazza discussion forum up to 10 bonus points.
PROBLEM STATEMENT
Dormitory Reservation Systems are key for managing student housing efficiently. They help organize room bookings, make finding and booking rooms easier, speed up the booking process, and give useful information for making decisions. These systems make it easier and quicker for students to find housing and for staff to understand which rooms are most wanted. This helps manage room assignments better and respond faster to student needs, making sure everyone finds a place to stay.
Security is very important too. It’s essential to make sure the system is safe by requiring usernames and passwords. This stops people who are not students from booking rooms and keeps housing available for actual students. So, building a safe, reliable, easy-to-use online booking system is very important for our dormitory to work well.
For this project, you’ll make a simple dormitory booking system. We’ll divide the dormitory into three types of rooms: Single Rooms, Double Rooms, and Suites, to keep things organized.
Students can look up if the type of room they want is available and book it if it is. They use a client interface to reach the main dormitory server, which then connects with the specific section server corresponding to a specific room type. Each section server has information on the rooms it handles. The main server also checks the user’s identity.
● Client: The system features include checking if rooms are available and booking them, with two types of clients: Guest and Member.
○ Members: can log in, search for room availability, and book a room.
■ Book a room, which will then decrease the room availability by 1 in the
backend server’s data structure (this change is only in the data structure
and not written back to the input file).
■ Members’ usernames and passwords are stored in a file named
“members.txt.”
○ Guests: can only search for room availability.

■ Users who skip the password input by pressing “Enter” will be treated as a Guest.
● Main Server (ServerM): Verifies the identity of the students and coordinates with the backend servers.
● Backend Servers (Single (S), Double (D), Suite (U)): Store the information of a specific room type.
This dormitory reservation system aims to provide a seamless and efficient process for students seeking on-campus housing, ensuring a positive experience from search to reservation.
Figure 1: Illustration of the system
Source Code Files
Your implementation should include the source code files described below, for each component of the system.
● Client: The name of this piece of code must be client.c or client.cc or client.cpp (all small letters) and the header file (if you have one; it is not mandatory) must be called client.h (all small letters).
● serverM (Main Server): You must name your code file: serverM.c or serverM.cc or serverM.cpp (all small letters except ‘M’). Also, you must include the corresponding header file (if you have one; it is not mandatory) serverM.h (all small letters except ‘M’).
● Backend Servers S, D, U: You are required to create three distinct files, choosing from the following naming conventions: ServerS.c, ServerS.cc,

ServerS.cpp or ServerD.c, ServerD.cc, ServerD.cpp or ServerU.c, ServerU.cc, ServerU.cpp. The filename must utilize one of these formats, substituting “#” with the specific server identifier (either “A” or “B”) to reflect the server it represents, resulting in filenames like serverA.c, serverA.cc, serverA.cpp, serverB.c, serverB.cc, or serverB.cpp (note that the name should be entirely in lowercase except for the letter replacing “#”). If available, you should also include a corresponding header file named server#.h, adhering to the same naming rule for the “#” replacement. This ensures a clear, organized naming structure for your code and its associated header file, if any.
Note: You are not allowed to use one executable for all four servers (i.e. a “fork” based implementation).
Input Files
member.txt: contains encrypted usernames and passwords. This file should only be accessed by the Main server.
single.txt: contains single room information categorized in roomcode, and number of the available rooms. Different categories are separated by a comma. This file should only be accessed by the Backend Server S.
double.txt: contains double room information categorized in roomcode, and number of the available rooms. Different categories are separated by a comma. This file should only be accessed by the Backend Server D.
suite.txt: contains suite room information categorized in roomcode, and number of the available rooms. Different categories are separated by a comma. This file should only be accessed by the Backend Server U.
Note: member_unencrypted.txt is the unencrypted version of member.txt, which is provided for your reference to enter a valid username and password. It should NOT be touched by any servers!
DETAILED EXPLANATION Phase 1: Bootup
Please refer to the “Process Flow” section to start your programs in the order of the main serverM, server S, server D, server U, and two Clients. Your programs must start in this order. Each of the servers and the clients have boot-up messages that must be printed on the screen. Please refer to the on-screen messages section for further information.
When three backend servers (server S, server D, and server U) are up and running, each backend server should read the corresponding input file (single.txt, double.txt, and suites.txt) and store the information in a certain data structure. You can choose any data structure that accommodates your needs. After storing all the data, server S, server D, and server U should then send all the room

statuses they have to the main server via UDP over the port mentioned in the PORT NUMBER ALLOCATION section. Since the room statuses are unique, the main server will maintain a list of room statuses corresponding to each backend server. In the following phases, you have to make sure that the correct backend server is being contacted by the main server for corresponding room statuses. You should print correct on-screen messages onto the screen for the main server and the backend servers indicating the success of these operations as described in the “ON-SCREEN MESSAGES” section.
After the servers are booted up and the required room statuses are transferred from the backend servers to the main server, the client will be started. Once the client boots up and the initial boot- up messages are printed, the client waits for the user to check the authentication, login, and enter the room layout code.
Please check Table 3 and 4 Client on-screen messages for the on-screen message of different events You should store the above room statuses. Once you have the book statuses list stored in your backend server and send the book code list of each backend server to the main server, you can consider phase 1 of the project to be completed. You can proceed to phase 2.
Phase 2: Log in and confirmation
In this phase, the client will be asked to enter the username and password on the terminal. There are two types of clients: guest and member. A member can be authenticated by the Dormitory Reservation System by inputting the member’s username and password. The client will encrypt this information and forward this request to the Main server. The Main server would have all the encrypted credentials (both username and password would be encrypted) of the registered users. Still, it would not have any information about the encryption scheme. The information about the encryption scheme would only be present on the client side. A guest can input the username while skipping the password input, but a guest can only query the room status but cannot reserve a room.
The encryption scheme for member authentication would be as follows:
● Offset each character and/or digit by 3.
● character: cyclically alphabetic (A-Z, a-z) update for overflow ● digit: cyclically 0-9 update for overflow
● The scheme is case-sensitive.
● Special characters (including spaces and/or the decimal point) will not be encrypted or changed.
A few examples of encryption are given below:

Example Original Text
#1 Welcome to EE450!
Encrypted Text Zhofrph wr HH783!
Constraints:
● The username will be of lower case characters (5~50 chars). ● The password will be case sensitive (5~50 chars)
A member client sends the authentication request to the main server over TCP connection. Upon running the client using the following command, the user will be prompted to enter the username and password. This unencrypted information will be encrypted at client side and then sent to the main server over TCP. A guest client can skip the password authentication and directly login.
(Please refer to the on-screen messages)
Please enter the username:
Please enter the password (“Enter” to skip for guests):
Main server receives the encrypted username and password from the client. ServerM sends the result of the authentication request to the client over a TCP connection. If the login information was not correct/found:
(Please refer to the on-screen messages)
Please enter the username: Please enter the password: Failed login. Invalid username/password
After the successful login:
Welcome member/guest !
Please enter the room layout code:
Multiple clients
In phase 2, Main server will have to receive requests from both the clients. For a server to receive requests from several clients at the same time, the function fork() should be used for the creation of a new process. Fork() function is used for creating a new process, which is called child process, which runs concurrently with the process that makes the fork() call (parent process).

For a TCP server, when an application is listening for stream-oriented connections from other hosts, it is notified of such events and must initialize the connection using accept(). After the connection with the client is successfully established, the accept() function returns a non-zero descriptor for a socket called the child socket. The server can then fork off a process using fork() function to handle connection on the new socket and go back to waiting on the original socket. Note that the socket that was originally created, that is the parent socket, is going to be used only to listen to the client requests, and it is not going to be used for communication between client and Main server. Child sockets that are created for a parent socket have the identical well-known port number IP address at the server side, but each child socket is created for a specific client. Through using the child socket with the help of fork(), the server can handle the two clients without closing any one of the connections.
Phase 3: Forwarding request to Backend Servers
Phase 3A: Query
Both a member client and a guest client can query the current statues of a specific room layout. Upon user input of a room code for a type and layout, the client is responsible for transmitting the request to the server M (the Main server) via a TCP connection. The server M parses the received roomcode to determine the appropriate destination server for request forwarding. Specifically, when the roomcode commences with “S,” the request must be routed to Server S. Similarly, if the roomcode initiates with “D,” the request is directed to Server D. In the event that the roomcode originates with “U,” the request must be forwarded to Server U. All the valid book codes are eligible for forwarding to their respective servers from the Server M via a UDP connection.
RoomCode from Client
S146 D111 U211 A111
Phase 3B: Reservation
Source Server
Server M Server M Server M Server M
Destination Server
Server S Server D Server U None
Only the member client can reserve a room. Each server will have a dedicated database file. This file should be read only once at server startup to ensure that if a user reserves a room, the corresponding book’s inventory count is updated accurately in the respective data structure and must not be overwritten by reading the database file over and over. The updated room number will be printed on the member client screen.
If a guest is requesting a reservation, a “permission denied” prompt will show on screen.

Phase 4: Reply
The corresponding room type server will check its input file and find the count of the requested roomcode. If the count is greater than 0, then the respective server will reply to the main server using UDP – “The requested room is available”. And if the count of the room is 0, then the server will reply to the main server using UDP – “The requested room is not available”. It is also possible that the roomcode entered by the client is not there in the system, in that case, the server will respond with a message – “Not able to find the room layout”.
For a reservation request, after sending the reply to the main server the room type server will decrement the count of the corresponding roomcode by 1 so that when a client requests a book a second time, the availability is updated and correct. And at last, the main server will print the on- screen message and will forward the reply from the room type server to the client using TCP. And the client will print the on screen message which gives the availability of the requested roomcode.
See ON-SCREEN MESSAGES table for more details.
Extra credit:
In this section, we will enhance the security of this system by applying more powerful encryption algorithms. You are encouraged to search the Internet for any existing security encryption/decryption algorithms to substitute the simple character shifting method in Phase 2, or you can even create some complicated methods as long as the transmitted message is not in plaintext. If you use symmetric or asymmetric encryption with public/private keys, you can assume they are known by the host and servers, and the keys can be hardcoded in the code.
To get full credit for this part, you are required to explain the algorithm with all details as well as show an example of the original text and encrypted text in the Readme.txt file (you can create an extra credit section), and you also need to provide clear instructions to tell graders how to compile and execute the system using upgraded encryption algorithms. (For example, you can add an argument to programs indicating which encryption protocol you are using, as shown in the sample code below. Then in Makefile, you can create another entry — “make extra” to compile and run the program using this more secure and complicated encryption/decryption algorithm.)
int main( int argc, char *argv[] ) {
if( argc == 1 ) {
printf(“no arguments, use character shifting protocol\n”);
else if( argc == 2 ) {
printf(“Using encryption protocol %s.\n”, argv[1]);

Process Flow/Sequence of Operations:
● Your project grader will start the servers in this sequence: serverM, serverS, serverD, serverU, and two Clients in 6 different terminals.
● Once all the ends are started, the servers and clients should be continuously running unless stopped manually by the grader or meet certain conditions as mentioned before.
Required Port Number Allocation
The ports to be used by the clients and the servers for the exercise are specified in the following table (Major points will be lost if the port allocation is not as per the below description):
Static and Dynamic assignments for TCP and UDP ports.
serverS serverD serverU serverM
Dynamic Ports
Static Ports
UDP, 41000+xxx
UDP, 42000+xxx
UDP, 43000+xxx
UDP (with servers), 44000+xxx TCP (with clients), 45000+xxx
NOTE: xxx is the last 3 digits of your USC ID. For example, if the last 3 digits of your USC ID are “319”, you should use the port: 41000+319 = 41319 for the Backend-Server (A). It is NOT going to be 41000319. Note that the serverM has only one UDP port. The same port is used to connect to all the backend servers.

ON-SCREEN MESSAGES
Table 1. Backend-Server S/D/U on-screen messages
Booting up (Only while starting):
Sending the room status to Main Server:
(a) Availability query
After receiving an availability request from Main Server
If the count of the room is greater than 0 If the count of the room is 0
If the room code is not in the system After sending the results to Main Server
(b) Reservation query
After receiving a reservation request from Main Server
If the count of the room is greater than 0
If the count of the room is 0
If the room code is not in the system
After sending the results to Main Server (if the count of the room changes)
After sending the results to Main Server (if the count of the room does not change)
On-screen Messages
The Server is up and running using UDP on port .
The Server has sent the room status to the main server.
The Server received an availability request from the main server.
Room is available.
Room is not available.
Not able to find the room layout.
The Server finished sending the response to the main server.
The Server received a reservation request from the main server.
Successful reservation. The count of Room is now .
Cannot make a reservation. Room is not available.
Cannot make a reservation. Not able to find the room layout.
The Server finished sending the response and the updated room status to the main server.
The Server finished sending the response to the main server.