EE450 Introduction to Computer Networks - Final Project: Conference booking system
Late submissions only for this assignment: Will be accepted after the
deadline with a maximum penalty of 30% per day: For each day, submissions
between 12 and 1am: 2% penalty, 1 and 2am: 4%, 2 and 3am: 8%, 3-4am:
15%, 4am and later: 30%. Note that sometime early 4th day, the lab would
be worth 0.
Download
Expand All
Collapse All
Problem Description
20 % 1 of 5 topics complete
Conference Room Reservation Systems are essential for efficiently managing conference rooms in EE/CS buildings. They streamline room bookings, simplify finding and reserving rooms, expedite the booking process, and provide valuable information for decision-making. These systems enable students to quickly locate available rooms for homework discussions or midterm preparations.
Security is crucial for these systems. Ensuring system safety by requiring usernames and passwords is vital. Only the client should access their username and password to prevent unauthorized individuals from booking rooms, ensuring availability for actual students. Building a secure, reliable, and user-friendly online booking system is of utmost importance. Specifically, messages containing personal information (e.g., username and password) should be encrypted before being sent over the Internet.
For this project, you will develop a simple conference booking system for two buildings, RTH and EEB, available to students. Students can check the availability of conference rooms and make reservations for the following week. They need to specify the room, day (e.g., Monday, Tuesday), and time (e.g., 4 pm) to reserve a room.
Students can check room availability and book if it's free. They use a client interface to connect with the main booking server (serverM), which interfaces with backend servers for credential verification and room information. The credential verification server (serverC) holds user information (username/password pairs), while the room information servers (serverRTH and serverEEB) store room details for their respective buildings. The main server forwards requests to the appropriate server and relays responses back to the client.
This conference room reservation system aims to provide a seamless and efficient process for students seeking study spaces, ensuring a positive experience from search to reservation.
Major Functionalities of Servers and Clients
Client: The system accommodates two types of users: Guests and Members.
Members: Members have the ability to log in, search for room availability, and book rooms.
Once a room is booked by a member, it becomes unavailable for further bookings to prevent double bookings.
All member credentials, including usernames and passwords, are securely stored in a file named "members.txt."
Guests: Guests, on the other hand, are limited to only searching for room availability.
Users who bypass the password input by pressing "Enter" during the login process are automatically treated as Guests, maintaining system security while allowing limited access.
Main Server (serverM): The main server (serverM) serves as the hub
of the system, interfacing with clients and coordinating interactions
with the backend servers.
Credential verification Server (serverC): The credential verification
server (serverC) securely stores and manages user information,
ensuring that access is granted only to valid members.
Room Information Servers (serverRTH/serverEEB): The room information servers, serverRTH and serverEEB, maintain detailed records of room availability in their respective buildings, facilitating accurate and up-to-date information for bookings.
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 C, RTH, EEB: You are required to create three distinct files, choosing from the following naming conventions: serverC.c or serverC.cc or serverC.cpp, and serverRTH.c or serverRTH.cc or serverRTH.cpp, and serverEEB.c or serverEEB.cc or serverEEB.cpp. 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
Note:
member.txt: contains encrypted usernames and passwords. This file should only be accessed by the credential verification server. RTH.txt: contains room information categorized by room number, available day, and available time. Different categories are separated by a comma. This file should only be accessed by serverRTH. EEB.txt: contains room information categorized by room number, available day, and available time. Different categories are separated by a comma. This file should only be accessed by serverEEB.
-
The format of each category is following:
Room Number: The room number will be the building name followed by three numbers (e.g., RTH419).
Day: Monday, Tuesday, ..., Sunday.
Time: From 8 am to 8 pm.
Please refer to the sample input files for the details. -
You need to dynamically decide how many rows are in each input file. There are at most 50 rows in each input file, and input files cannot be empty.
-
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!
EEB
Text File
member
Text File
RTH
Text File
unencrypted_member
Text File
Detailed Explanation
Phase 1: Bootup
Please refer to the Process Flow/Sequence of Operations section to start
your programs in the order of the main serverM, serverC, serverRTH,
serverEEB, 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 Message for further information.
When three backend servers (serverRTH, serverEEB, and serverC) are up and running, each backend server should read the corresponding input file (RTH.txt, EEB.txt, and member.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, serverRTH, serverEEB, serverC, should then inform the main server they have booted up via UDP over the port mentioned in the Required Port Number Allocation section. Without this step, the main server is not able to know the servers it is connecting to. 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 Message section.
After the servers inform the main server that they have been booted up, 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 number, day, and time.
Please check Table 4. Member Client on-screen messages and Table 5. Guest Client on-screen messages for the on-screen messages of different events. Once you have the list of room statuses stored on your backend servers and the users’ information stored on the credential verification server, you can consider phase 1 of the project to be completed. You can proceed to phase 2.
Phase 2: Login and confirmation
In this phase, clients are prompted to enter a username and password via
the terminal. The system supports two types of clients: guests and
members. Members are authenticated by entering their username and
password. Upon entry, this information is encrypted by the client before being sent to the main server. The main server then forwards the encrypted
credentials to the Credential Verification Server (serverC). ServerC holds all
registered users' encrypted credentials but does not have access to the
encryption scheme used, enhancing security. The encryption scheme is
managed exclusively on the client side to ensure confidentiality.
Guests, on the other hand, may enter a username while opting to skip the password input. This allows guests to query room statuses but prevents them from making room reservations. This two-tiered approach ensures that sensitive user information remains encrypted throughout the process and limits room booking capabilities to authenticated members only, thereby maintaining the integrity and exclusivity of the system.
This phase solidifies the system's security and operational efficiency by delineating clear roles and capabilities for different user types and ensuring that all transmitted data is securely encrypted.
The encryption scheme for member authentication would be as follows:
Offset each English alphabet letter and digit by a value n, where n corresponds to the character's position within the username or password.
n-th character from the left-hand side of the username or password is offset by n. This method ensures a unique transformation for each character based on its position. English alphabet: this encryption is cyclically alphabetic for both uppercase (A-Z) and lowercase (a-z) letters, meaning that if the offset moves beyond 'Z' or 'z', it wraps around to 'A' or 'a', respectively.
digit: the scheme cyclically updates for overflow, so an offset
beyond '9' wraps around to '0'.
This encryption approach is case-sensitive, maintaining the case of
each alphabetic character as originally presented.
Special characters, including spaces and decimal points, are not
encrypted or altered, preserving their original form in the encrypted
output.
Comma (,) will be in the username and password
A few examples of encryption are given below:
Example #1 #2
Original Text Jam!e?w 199xyz@$
Encrypted Text Kcp!j?d 212bdf@$
Constraints:
Both username and password are case-sensitive (5~20 chars).
Phase 2A:
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 on the client side and then sent to the main server over TCP, and then the main server will forward this request to the credential verification server over UDP. A guest client can skip password authentication and log in directly.
./client
Please enter the username: <unencrypted_username>
Please enter the password (“Enter” to skip for guests):
<unencrypted_password>
Phase 2B:
The credential verification server receives the encrypted username and password from the main server. The credential verification server sends the result of the authentication request to the main server over a UDP connection, and then the main server forwards the response to the client over a TCP connection. If the login information was not correct/found:
./client
Failed login. Invalid username/password
After the successful login:
Phase 3: Forwarding request to Backend Servers
Phase 3A: Query
Both a member client and a guest client can query the current status of a specific room. Upon user input of a room number, data, and time for a room availability on the specific day and time, the client is responsible for transmitting the request to serverM (the main server) via a TCP connection. The serverM parses the received room number to determine the appropriate destination server for request forwarding. Specifically, when the room number commences with "RTH," the request must be routed to Server RTH. Similarly, if the room number initiates with "EEB," the request is directed to Server EEB. All the valid room number are eligible for forwarding to their respective servers from ServerM via a UDP connection.
Welcome member/guest <username>!
Please enter the room number: <room number>
|
Room number from Client |
Source Server |
Destination Server |
RTH103 ServerM EEB204 ServerM THH111 ServerM
Phase 3B: Reservation
ServerRTH ServerEEB 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 room’s availability is updated accurately in the respective data structure and must not be overwritten by reading the database file over and over. The updated
Please enter the username: <unencrypted_username> Please enter the password: <unencrypted_password> room availability will be printed on the member client screen.
If a guest requests a reservation, a “permission denied” prompt will appear on the screen.
Phase 4: Reply
The corresponding room type server will check its input file and find the
availability of the requested room on the specific date and time. If the room
is available on the selected day and time, then the respective server will
reply to the main server using UDP - “The requested room is available.” If
the room is not available on the selected day and time, then the server
will reply to the main server using UDP - “The requested room is not
available.” It is also possible that the room number 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.”
For a reservation request, after sending the reply to the main server, the room information server will change the status of the room to unavailable so that when a client requests a book a second time, the availability is updated and correct. Finally, the main server will print the on-screen message and forward the reply from the room information server to the client using TCP. The client will print the on-screen message, which gives the availability of the requested room on the selected day and time.
See On Screen Message for more details.
Extra Credit
As part of our ongoing efforts to enhance the Conference Room
Reservation System, Phase 3A introduces advanced query capabilities
specifically designed for members, enabling them to retrieve room
availability information more efficiently. This enhancement is part of the
extra credit initiative and is available only in the member mode.
In the basic mode, members continue to provide the room number, day, and time to check the availability of a specific room. However, the advanced mode introduces more flexible querying options that allow members to access room availability with fewer inputs, speeding up the information retrieval process.
Query by Room Number Only:
In this scenario, a member may choose to enter only the room number. Upon receiving such a request, the main server (Server M) will forward it to the corresponding room information server (either Server RTH or Server EEB, depending on the room number prefix). The designated server will then respond with a comprehensive list of all available days and times for the specified room. This allows the member to quickly see when the room is free without specifying a date or time.
Query by Room Number and Day:
If the member inputs both the room number and the day but omits the time, the main server will route the request in a similar manner to the corresponding server. The server will then provide a list of all available time slots for the specified room on the chosen day. This targeted query helps members plan their schedules more efficiently by focusing on a specific day.
Please refer to On Screen Message for more details.
Process Flow/Sequence of Operations
Your project grader will start the servers in this sequence: serverM,
serverC, serverRTH, serverEEB, 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 if
certain conditions, as mentioned before, are met.
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
Process
serverC serverRTH serverEEB
Dynamic Ports
- - -
Static Ports
1 UDP, 31000+xxx 1 UDP, 32000+xxx 1 UDP, 33000+xxx
|
serverM |
- |
1 UDP, 34000+xxx 1 TCP, 35000+xxx |
|
clients |
1 TCP for each client |
<Dynamic Port assignment> |
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: 31000+319 = 31319 for the Backend-Server (A). It is NOT going to be 31000319. Note that the serverM has only one UDP port. The same port is used to connect to all of the backend servers.
On Screen Message
Table 1. Credential Verification Server C on-screen
messages
Event On-screen Messages
|
Booting up (Only while starting): |
The Server C is up and running using UDP on port <Server C port number>. |
|
Inform the main server it has been booted up: |
The Server C has informed the main server. |
After receiving an authentication request from the main server
The Server C received an authentication request from the main server.
If pass the authentication
If username does not exist
If password does not match
Successful authentication. Username does not exist. Password does not match.
|
After sending the results to the main server |
The Server C finished sending the response to the main server. |
Table 2. Room Information Server RTH/EEB on-screen
messages
Event On-screen Messages
(a) Availability query
|
Booting up (Only while starting): |
The Server <RTH/EEB> is up and running using UDP on port <Server RTH/EEB port number>. |
|
Inform the main server it has been booted up: |
The Server <RTH/EEB> has informed the main server. |
|
After receiving an availability request from the main server |
The Server <RTH/EEB> received an availability request from the main server. |
|
If the room is available on the selected day and time |
Room <room number> is available at <time> on <day>. |
|
If the room is not available on the selected day and time |
Room <room number> is not available at <time> on <day>. |
|
If the room number is not in the system |
Not able to find the room <room number>. |
|
After sending the results to the main server |
The Server <RTH/EEB> finished sending the response to the main server. |
Extra Credit
After receiving an availability request from the main server
The Server <RTH/EEB> received an availability request from the main server.
|
If the client only provides the room number |
All the availability of the room <room number> has been extracted. |
|
If the client only provides the room number and the day |
All the availability of the room <room number> on <day> has been extracted. |
|
If the room number is not in the system |
Not able to find the room <room number>. |
|
After sending the results to the main server |
The Server <RTH/EEB> finished sending the response to the main server. |
(b) Reservation query
|
After receiving a reservation request from the main server |
The Server <RTH/EEB> received a reservation request from the main server. |
|
If the room is available on the selected day and time |
Successful reservation. The status of Room <room number> is updated. |
|
If the room is not available on the selected date and time |
Cannot make a reservation. Room <room number> is not available. |
|
If the room code is not in the system |
Cannot make a reservation. Not able to find the room layout. |
|
After sending the results to the main server |
The Server <RTH/EEB> finished sending the response to the main server. |
Table 3. Main Server on-screen messages
Event On-screen Messages
Booting up: The main server is up and running.
|
Upon receiving the notification from Server C/RTH/EEB |
The main server has received the notification from Server <C/RTH/EEB> using UDP over port <main server UDP port number>. |
(a) Member
(b) Guest
|
After receiving the username from the guest |
The main server received the guest request for <encrypted_username> using TCP over port <main server TCP port number>. The main server accepts <encrypted_username> as a guest. |
|
Upon sending a guest response to the client |
The main server sent the guest response to the client. |
(a) Availability request
After receiving the username and password from the member
The main server received the authentication for <encrypted_username> using TCP over port <main server TCP port number>.
After forwarding the username and password to Server C
The main server forwarded the authentication for <encrypted_username> using UDP over port <main server UDP port number>.
Upon receiving the response from Server C
The main server received the authentication result for <encrypted_username> using UDP over port <main server UDP port number>.
Upon sending an authentication response to the client
The main server sent the authentication result to the client.
Upon receiving the input from the client for availability
The main server has received the availability request on Room <room number> at <time> on <day> from <encrypted_username> using TCP over port <main server TCP port number>.
After forwarding the request to Server <RTH/EEB>
(b) Reservation request
The main server sent a request to Server <RTH/EEB>.
After receiving the result from Server <RTH/EEB>
The main server received the response from Server <RTH/EEB> using UDP over port <main server UDP port number>.
After forwarding the result to the client
The main server sent the availability information to the client.
|
Upon receiving the input from the client for the reservation |
The main server has received the reservation request on Room <room number> at <time> on <day> from <encrypted_username> using TCP over port <main server TCP port number>. |
|
Error message (if the client is a guest, not a member) |
Permission denied. <encrypted_username> cannot make a reservation. |
|
After sending an error message to the client |
The main server sent the error message to the client. |
|
After forwarding the request to Server <RTH/EEB> |
The main server sent a request to Server <RTH/EEB>. |
|
After receiving the result and updated room status from Server <RTH/EEB> |
The main server received the response from Server <RTH/EEB> using UDP over port <main server UDP port number>. |
|
After forwarding the result to the client |
The main server sent the reservation result to the client. |
Table 4. Member Client on-screen messages
Event On-screen Messages
Booting up (only while starting) Client is up and running.
Asking the user to enter the username
Please enter the username: <unencrypted_username>
Asking the user to enter the password
Please enter the password: <unencrypted_password>
Upon sending an authentication request to the main Server
<unencrypted_username> sent an authentication request to the main server.
fter receiving the result of the authentication request from the main server (if the authentication passed)
Welcome member <unencrypted_username>!
After receiving the result of the authentication request from the main server (username does not exist)
Failed login: Username does not exist.
After receiving the result of the authentication request from the main server (password does not match)
Failed login: Password does not match.
Asking the user to input the room number
Please enter the room number: <room number>
Asking the user to input the selected day
Please enter the day: <day>
Asking the user to input the selected time
Please enter the time: <time>
Asking the user to choose the desired action
Would you like to search for the availability or make a reservation? (Enter “Availability” to search for the availability or Enter “Reservation” to make a reservation ): <Availability or Reservation>
Error handling (If the extra credit is not implemented and the client does not provide the day or the time)
Missing argument.
<Leave one blank line> -----Start a new request-----
Extra Credit
|
Asking the user to input the room code |
Please enter the room number: <room number> |
|
Asking the user to input the selected day |
Please enter the day: <The client may choose to type ”Enter” to skip> |
|
Asking the user to input the selected time |
Please enter the time: <The client may choose to type “Enter” to skip> |
(a) Availability request
|
Upon sending an availability request to the main server |
<unencrypted_username> sent an availability request to the main server. |
|
After receiving the response from the main server (the room is available) |
The client received the response
from the main server using TCP over
port <client port number>. |
|
After receiving the response from the main server (the room is not available) |
The client received the response
from the main server using TCP over
port <client port number>. |
|
After receiving the response from the main server (room number is not in the system) |
he client received the response from
the main server using TCP over port
<client port number>. <Leave one blank line> -----Start a new request----- |
Extra Credit
|
Upon sending an availability request to the main server |
<unencrypted_username> sent an availability request to the main server. |
|
After receiving the response from the main server (If the client only provides the room number, and room is available for some days and times.) Note: <day n> may be the same day as <day m> |
The client received the response
from the main server using TCP over
port <client port number>. |
||
|
After receiving the response from the main server (If the client only provides the room number and the day. The room has availability on the selected day.) |
The client received the response
from the main server using TCP over
port <client port number>. |
||
|
After receiving the response from the main server (If the client only provides the room number and the room does not have availability.) |
The client received the response
from the main server using TCP over
port <client port number>. |
||
|
After receiving the response from the main server (If the client only provides the room number and the day. The room does not have availability on the selected day.) |
The client received the response
from the main server using TCP over
port <client port number>. |
(b) Reservation request
|
Upon sending a reservation request to the main server |
<unencrypted_username> sent a reservation request to the main server. |
|
After receiving the response from the main server (the room is available) |
The client received the response
from the main server using TCP over
port <client port number>.
Congratulation! The reservation for
Room <room number> has been
made. |
|
After receiving the response from the main server (the room is not available) |
The client received the response
from the main server using TCP over
port <client port number>. |
|
After receiving the response from the main server (room number is not in the system) |
The client received the response
from the main server using TCP over
port <client port number>. |
<Leave one blank line> -----Start a new request-----
After receiving the response from the main server (room number is not in the system.)
he client received the response from
the main server using TCP over port
<client port number>.
Not able to find the room.
<Leave one blank line> -----Start a new request-----
Table 5. Guest Client on-screen messages
Event On-screen Messages
Booting up(only while starting) Client is up and running.
|
Asking the user to enter the username |
Please enter the username: <unencrypted_username> |
|
Asking the user to enter the password |
Please enter the password: <”Enter”> |
|
Upon continuing as a guest |
<unencrypted_username> sent a guest request to the main server using TCP over port <client port number>. |
|
After receiving the response from the main server |
Welcome guest <unencrypted_username>! |
|
Asking the user to input the room number |
Please enter the room number: <room number> |
|
Asking the user to input the selected day |
Please enter the date: <day> |
|
Asking the user to input the selected time |
Please enter the time: <time> |
|
Asking the user to choose the desired action |
Would you like to search for the availability or make a reservation? (Enter “Availability” to search for the availability or Enter “Reservation” to make a reservation ): <Availability or Reservation> |
|
Error handling (If the client does not provide the day or time) |
Missing argument. |
(a) Availability request
|
Upon sending an availability request to the main server |
<unencrypted_username> sent an availability request to the main server. |
(b) Reservation request
|
Upon sending a reservation request to the main server. |
<unencrypted_username> sent a reservation request to the main server. |
|
After receiving the response from the main server |
Permission denied: Guest cannot
make a reservation. |
Example Output to Illustrate Output Formatting
Server C Terminal:
The Server C is up and running using UDP on port 31319.
The Server C received an authentication request from the main server.
Successful authentication.
The Server S finished sending the response to the main server.
After receiving the response from the main server (the room is available)
The client received the response
from the main server using TCP over
port <client port number>.
The requested room is available.
<Leave one blank line>
-----Start a new request-----
After receiving the response from the main server (the room is not available)
The client received the response
from the main server using TCP over
port <client port number>.
The requested room is not available.
<Leave one blank line>
-----Start a new request-----
After receiving the response from the main server (room number is not in the system)
The client received the response
from the main server using TCP over
port <client port number>.
Not able to find the room.
<Leave one blank line>
-----Start a new request-----
Server RTH Terminal:
The Server RTH is up and running using UDP on port 32319.
The Server RTH has informed the main server.
The Server RTH received an availability request from the main server.
Room RTH304 is not available.
The Server RTH finished sending the response to the main server.
Server EEB Terminal:
The Server EEB is up and running using UDP on port 33319.
The Server EEB has informed the main server.
The Server EEB received a reservation request from the main server.
Successful reservation.
The Server EEB finished sending the response to the main server.
Main Server Terminal:
The main server is up and running.
The main server has received the notification from Server C using UDP over
port 34319.
The main server has received the notification from Server RTH using UDP
over port 34319.
The main server has received the notification from Server EEB using UDP
over port 34319.
The main server received the authentication for Kcp!j?d using TCP over
port 35319.
The main server forwarded the authentication request to Server C.
The main server received the authentication result from Server C using
UDP over port 34319.
The main server sent the authentication result to the client.
The main server has received the availability request on Room RTH304
from Kcp!j?d using TCP over port 35319.
The main server sent a request to Server RTH.
The main server received the response from Server RTH using UDP over
port 34319.
The main server sent the availability information to the client.
The main server has received the availability request on Room EEB101
from Kcp!j?d using TCP over port 35319.
The main server sent a request to Server EEB.
The main server received the response from Server EEB using UDP over
port 34319.
The main server sent the availability information to the client.
The main server has received the reservation request on Room RTH304
from Kcp!j?d using TCP over port 35319.
The main server sent a request to Server RTH.
The main server received the response from Server RTH using UDP over
port 34319.
The main server sent the reservation result to the client.
Client Terminal:
Client is up and running.
Please enter the username: Jam!e?w
Please enter the password: 2kAnsa7s
james sent an authentication request to the main server.
Welcome member james!
Please enter the room number: RTH304
Please enter the day: Monday
Please enter the time: 6 pm
Would you like to search for the availability or make a reservation? (Enter
“Availability” to search for the availability or Enter “Reservation” to make a
reservation ):Availability
james sent an availability request to the main server.
The client received the response from the main server using TCP over port
<port number>.
The requested room is available.
-----Start a new request-----
Please enter the room code: EEB101
Please enter the day: Tuesday
Please enter the time: 3 pm
Would you like to search for the availability or make a reservation? (Enter
“Availability” to search for the availability or Enter “Reservation” to make a
reservation ):Availability
james sent an availability request to the main server.
The client received the response from the main server using TCP over port
<port number>.
The requested room is not available.
-----Start a new request-----
Please enter the room code: RTH304
Please enter the day: Monday
Please enter the time: 6 pm
Would you like to search for the availability or make a reservation? (Enter
“Availability” to search for the availability or Enter “Reservation” to make a
reservation ): Reservation
james sent a reservation request to the main server.
The client received the response from the main server using TCP over port
<port number>. Congratulation! The reservation for Room RTH304 has
been made.
-----Start a new request-----
Please enter the room code: <Ctrl C>
(Note: You should replace <port number> with the TCP port number dynamically assigned by the system.)
Implementation and Submission Instructions
TAs will first compile all codes using make all. They will then open 6 different terminal windows. On 4 terminals, they will start servers M, C, RTH, and EEB. On the two other terminals, they will start the clients using ./client. Remember that all programs should always be on once started. TAs will check the outputs for multiple input values. The terminals should
display the messages shown in the On-screen Messages tables in this project writeup.
Compress all your files including the README file and the Makefile into a single “tar ball” and call it: ee450_YourLastName_YourFirstName_yourUSCusername.tar.gz (all small letters) e.g. an example filename would be ee450_trojan_tommy_tommyt.tar.gz. Please make sure that your name matches the one in the class list.
Here are the instructions:
On your VM, go to the directory which has all your project files. Remove all
executable and other unnecessary files. Only include the required source
code files, Makefile and the README file. Now run the following two
commands:
tar cvf ee450_YourLastName_YourFirstName_yourUSCusername.tar *
gzip ee450_YourLastName_YourFirstName_yourUSCusername.tar
Now, you will find a file named
“ee450_YourLastName_YourFirstName_yourUSCusername.tar.gz” in the
same directory.
Please notice there is a space and a star(*) at the end of the first command.
An example submission would be:
First Name: John
Last Name: Doe
USC username: jdoe (This can be found with your email address, In this
case the email address would be jdoe@usc.edu)
So the submission would be:
ee450_Doe_John_jdoe.tar.gz
Any compressed format other than .tar.gz will NOT be graded!
Upload “ee450_YourLastName_YourFirstName_yourUSCusername.tar.gz” to the Digital Dropbox on the DEN website (DEN -> EE450 -> My Tools -> Assignments -> Project). After the file is uploaded to the dropbox, you must
click on the “Submit” button to actually submit it. If you do not click on “Submit”, the file will not be submitted.
D2L will keep a history of all your submissions. If you make multiple submissions, we will grade your latest valid submission. Submission after the deadline is considered as invalid.
D2L will send you a “Dropbox submission receipt” to confirm your submission. So please do check your emails to make sure your submission is successfully received. If you have not received a confirmation mail, contact your TA if it always fails.
After receiving the confirmation email, please confirm your submission by downloading and compiling it on your machine. This is exactly what TAs/graders would do, So please grade your own project from the perspective of the TAs/graders. If the outcome is not what you expected, try to resubmit and confirm again. We will only grade what you submitted even though it’s corrupted.
Please take into account all kinds of possible technical issues and do expect a huge traffic on the DEN website very close to the deadline which may render your submission or even access to DEN unsuccessful.
Please DO NOT wait till the last 5 minutes to upload and submit because some technical issues might happen and you will miss the deadline. And a kind suggestion, if you still get some bugs one hour before the deadline, please make a submission first to make sure you will get some points for your hard work!
Submission File and Folder Structure
Your submission should have the following folder structure and the files
(the examples are of .cpp, but it can be .c files as well):
- ee450_lastname_firstname_uscusername.tar.gz - ee450_lastname_firstname_uscusername
- client.cpp
- serverM.cpp
- serverC.cpp
- serverRTH.cpp
- serverEEB.cpp
- Makefile
- readme.txt (or) readme.md
- <Any additional header files>
The grader will extract the tar.gz file, and will place all the input data files in the same directory as your source files. The executable files should also be generated in the same directory as your source files. So, after testing your code, the folder structure should look something like this:
- ee450_lastname_firstname_uscusername
- client.cpp
- serverM.cpp
- serverC.cpp
- serverRTH.cpp
- serverEEB.cpp
- Makefile
- readme.txt (or) readme.md
- client
- serverM
- serverC
- serverRTH
- serverEEB
- member.txt
- RTH.txt
- EEB.txt
- <Any additional header files>
Note that in the above example, the input data files (member.txt, RTH.txt, and EEB.txt) will be manually placed by the TAs/graders, while the ‘make all’ command should generate the executable files.
Assumptions
-
You have to start the processes in this order: serverM, serverC,
serverRTH, serverEEB, and clients. If you need to have more code files than the ones that are mentioned here, please use meaningful names and all small letters and mention them all in your README file.
-
You are allowed to use blocks of code from Beej’s socket programming tutorial (Beej’s guide to network programming) in your project. However, you need to cite the copied part in your code. Any signs of academic dishonesty will be taken very seriously.
-
When you run your code, if you get the message “port already in use” or “address already in use”, please first check to see if you have a zombie process. If you do not have such zombie processes or if you still get this message after terminating all zombie processes, try changing the static UDP or TCP port number corresponding to this error message (all port numbers below 1024 are reserved and must not be used). If you have to change the port number, please do mention it in your README file and provide reasons for it.
Requirements
-
Do not hardcode the TCP port numbers that are to be obtained
dynamically. Refer to Required Port Number Allocation to see which ports are statically defined and which ones are dynamically assigned. Use getsockname() function to retrieve the locally-bound port number wherever ports are assigned dynamically.
-
The host name must be hard coded as “localhost” or “127.0.0.1” in all codes.
-
Your client, the backend servers, and the main server should keep running and wait for another request until the TAs/graders terminate them by Ctrl+C. If they terminate before that, you will lose some points for it.
-
All the naming conventions and the on-screen messages must conform to the previously mentioned rules.
-
You are not allowed to pass any parameter, value, string, or character as a command-line argument except what is already described in the project document.
-
All the on-screen messages must conform exactly to the project description. You should not add any more on-screen messages. If you need to do so for debugging purposes, you must comment out all of the extra messages before you submit your project.
-
Please do remember to close the socket and tear down the connection once you are done using that socket.
Programming platform and environment
-
All your submitted code MUST work well on the provided virtual
machine Ubuntu (i.e., StudentVM or VM for MAC with M1/M2
chips).
-
All submissions will only be graded using the provided Ubuntu.
TAs/Graders won’t make any updates or changes to the virtual machine. It’s your responsibility to make sure your code works well on the provided Ubuntu. “It works well on my machine” is not an excuse.
-
Your submission MUST have a Makefile. Please follow the requirements in the following Submission Rules section.
Programming languages and compilers 1 You must use only C/C++ on UNIX as well as UNIX Socket programming commands and functions. Here are the pointers for Beej's Guide to C Programming and Network Programming (socket programming):
http://www.beej.us/guide/bgnet/
(If you are new to socket programming please do study this tutorial carefully as soon as possible and before starting the project)
You can use a unix text editor like emacs to type your code and then use compilers such as g++ (for C++) and gcc (for C) that are already installed on Ubuntu to compile your code. You must use the following commands and switches to compile yourfile.c or yourfile.cpp. It will make an executable by the name of "yourfileoutput”.
gcc -o yourfileoutput yourfile.c g++ -o yourfileoutput yourfile.cpp
Do NOT forget the mandatory naming conventions mentioned before!
Also, inside your code, you need to include these header files in addition to any other header file you think you may need:
#include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <errno.h> #include <string.h> #include <netdb.h> #include <sys/types.h> #include <netinet/in.h> #include <sys/socket.h> #include <arpa/inet.h> #include <sys/wait.h>
Submission Rules
Along with your code files, include a README file and a Makefile. The
Makefile requirements are mentioned in the section below. The README
file can be in any format (Markdown or txt). The only requirement is that
the TAs should be able to open the file and read it in the provided VM. Your
project will be graded in without installing any additional software. In the
README file please include:
1. Your Full Name as given in the class list
2. Your Student ID What you have done in the assignment if you have completed the optional part (extra credit). If it’s not mentioned, it will not be considered.
-
What your code files are and what each one of them does. (Please do not repeat the project description; just name your code files and briefly mention what they do).
-
The format of all the messages exchanged, e.g., username and password, are concatenated and delimited by a comma, etc.
-
Any idiosyncrasy of your project. It should say under what conditions the project fails, if any.
-
Reused Code: Did you use code from anywhere for your project? If not, say so. If so, say what functions and where they're from. (Also, identify this with a comment in the source code). Reusing functions that are directly obtained from a source on the internet without or with few modifications is considered plagiarism (Except code from the Beej’s Guide). Whenever you are referring to an online resource, make sure to only look at the source, understand it, close it, and then write the code yourself. The TAs will perform plagiarism checks on your code, so make sure to follow this step rigorously for every piece of code that is submitted.
Submissions WITHOUT README and Makefile WILL NOT BE GRADED.
Makefile https://www.cs.swarthmore.edu/~newhall/unixhelp/howto_makefiles.html
About the Makefile: makefile should support the following functions:
|
make all |
Compiles all your files and creates executables |
make clean ./serverM ./serverC ./serverRTH ./serverEEB
Removes all the executable files
Runs Main server
Runs Backend server C
Runs Backend server RTH
Runs Backend server EEB
./client Runs the client
Cautionary Words and Academic Integrity
Cautionary Words
-
Start on this project early!!!
-
In view of what is a recurring complaint near the end of a project,
we want to make it clear that the target platform on which the project is supposed to run is StudentVM (64-bit) or Ubuntu 22.04 ARM64 for M1/M2 Mac users. It is strongly recommended that students develop their code on this virtual machine. In case students wish to develop their programs on their personal machines, possibly running other operating systems, they are expected to deal with technical and incompatibility issues (on their own) to ensure that the final project compiles and runs on the requested virtual machine. If you do development on your own machine, please leave at least three days to make it work on Ubuntu. It might take much longer than you expect because of some incompatibility issues.
-
You may create zombie processes while testing your codes, please make sure you kill them every time you want to run your code. To see a list of all zombie processes, try this command:
Academic Integrity
All students are expected to write all their code on their own!!!
Do not post your code on Github, especially in a public repository before
the deadline!!!
Double-check the settings and do some testing before posting in a private
repository!!!Copying code from friends or from any unauthorized resources (webpages,
github, etc.) is called plagiarism not collaboration and will result in an F for
the entire course. Any libraries or pieces of code that you use or refer and
you did not write must be listed in your README file. Students are only
allowed to use the code from Beej’s socket programming tutorial. Copying
the code from any other resources may be considered as plagiarism. Please
be careful!!! All programs will be compared with automated tools to detect
similarities; examples of code copying will get an F for the course. IF YOU
HAVE ANY QUESTIONS ABOUT WHAT IS OR ISN’T ALLOWED ABOUT
PLAGIARISM, TALK TO THE TA. “I didn’t know” is not an excuse.
