CSci 4061: Introduction to Operating Systems, Spring 2024
Project #4: Socket Programming
Final submission due: 11:59pm (CDT), 5, 1, 2023
1. Project Overview
In Project 3, we built a multi-threaded image matching server using POSIX threads and synchronization mechanisms. While doing so, several utility functions were provided which helped you implement the network communication portion of the server and client. In this project, you will be implementing the networking utility functions using POSIX socket programming.
2. Description
The utility functions used in the server and client are responsible for receiving requests and sending responses between clients and the server. We have provided a solution file for the Project 3 multi-threaded server (server.o) and client (client.o) that will integrate with the utility functions that you will write in utils.c through the interface described in utils.h.
There are seven main utility functions that you must implement. The interface of each of these functions is described in detail in the provided utils.h header file with additional comments in utils.c file. A high-level overview of what each function should do is provided below.
2.1 Server Functions
This function is run once by the server main() during initialization to set up a socket for receiving client connection requests on the port provided. The newly global created socket should be used by all dispatch threads for accepting client connection requests.
|
int accept_connection(void);
|
This function is called repeatedly by each dispatcher thread to accept a new client connection request. If successful, it should return the new socket descriptor for communicating with the client.
|
char * get_request_server(int fd, size_t *filelength);
|
This function is called by each dispatcher thread to get a request from the client. If successful, it should return a char * of bytes with the image content from the client and return the image size in filelength variable.
|
int send_file to client(int socket, char *buffer, int size);
|
This function is called by the worker thread to send the new image content back to the client. The function takes a socket of where to send the data and buffer with the new image bytes and the size of the new image. If successful, it should return a 0 and failure it should return - 1.
2.1 Client Functions
|
int setup_connection(int port);
|
This function is called by the client threads to set up a connection with the server on a given port. The function takes a port of where it should attempt to connect. The function returns a socket fd of the socket connection between the client and the server.
|
int send_file to server(int socket, FILE *file, int size);
|
This function sends a file over a network connection to a server. It first sends the size of the file in a packet, then sends the file data. It reads data from the file, stores it in a buffer, and sends the buffer over the network. It returns 0 upon successful transmission and - 1 if there are any errors.
|
int receive_file_from_server(int socket, const char *filename);
|
This function receives a file from a server. It starts by opening a new file to save the received data. Then, it waits to receive a packet from the server containing information about the size of the file. After getting the size, it starts receiving the file data and writes to the file. Returns 0 upon successful reception. If there's an error, it returns - 1.
3. Passive Socket Port Reuse
The server may be terminated at any time. When an unexpected termination occurs, by default the port number used by the server continues to be held by the OS until a timeout has occurred. To avoid having to wait for the port number to be released after the timeout, the socket created for accepting client connection requests during init() should be setup for port reuse.This can be done using setsockopt() with the SO_REUSEADDR option.This will allow us to restart our server on the same port immediately after a previous run.
4. Compilation Instructions
You can create all of the necessary executable files with
Running the program with various directories can be accomplished with
|
Command Line
|
|
$ ./server cher>
|
|
$ ./client ver Port>
|
Example:
|
Command Line
|
|
$ ./server 8000 database 50 50 20
|
|
$ ./client img 8000 output
|
5. Project Folder Structure
Please strictly conform. to the folder structure that is provided to you. Your conformance will be graded.
|
Project structure
|
Contents (initial/required contents)
|
|
include/
|
.hheader files (server.h client.h utils.h)
|
|
lib/
|
.o library files (server.o client.o)
|
|
src/
|
.c source files (utils.c)
|
|
database/
|
Contain the server database
|
|
output/
|
outputted images
|
|
Makefile
|
file containing build information and used for testing/compiling
|
|
README.md
|
|
6. Assumptions / Notes
1. The maximum number of dispatcher threads will be 100.
2. The maximum number of worker threads will be 100.
3. The maximum length of the request queue will be 100 requests.
4. The maximum length of a filename will be 1024.
5. The maximum number of database entries is 100.
6. The server should accept a backlog of up to 20 connection requests
7. Documentation
Within your code you should use one or two sentences to describe each function that you write. You do not need to comment every line of your code. However, you might want to comment portions of your code to increase readability.
8. Submission Details
There will be one submission for this assignment. The only submission is due ~2 weeks after the project is released.
8.1 Final Submission
One student from each group should upload a .zip file to Gradescope containing all of the project files. The README should include the following details:
● Project group number
● Group member names and x500s
● The name of the CSELabs computer that you tested your code on
○ e.g. csel-kh1250-01.cselabs.umn.edu
● Members ’ individual contributions
● Any changes you made to the Makefile or existing files that would affect grading
● Any assumptions that you made that weren’t outlined in section 7
● How could you enable your program to make EACH individual request parallelized? (high-level pseudocode would be acceptable/preferred for this part)
The member of the group who uploads the .zip file to Gradescope should add the other members to their group after submitting. Only one member in a group should upload.
Your project folder should include all of the folders that were in the original template. You can add additional files to those folders and edit the Makefile, but make sure everything still works. Before submitting your final project, run “make clean” to remove any existing output/ data and manually remove any erroneous files.
9. Miscellaneous
1. We will provide an initial set of code, but you will be doing most of the coding.
2. Do not use the system called “system” .
3. Said before: KILL all of your stray processes during debugging as needed.
4. Any provided binaries are meant for the CSELAB Linux environment. No other binaries will be distributed.
5. ChatGPT or other significant “other” code reuse is prohibited. The purpose of this course is to learn by doing, and not meeting some deadline. If you are unsure about any located online code, contact us.
6. On the other hand, locating code snippets that show how system calls can be used is fine
10. Rubric (tentative)
● [ 10%] README
● [5%] Coding style. indentations, readability, comments where appropriate
● [35%] Test cases
● [40%] Correct use of socket(), connect(), bind(), listen(), accept(), send(), recv().
● [ 10%] Error handling — should handle system call errors and terminate gracefully
Additional notes:
● We will use the GCC version installed on the CSELabs machines to compile your code. Make sure your code compiles and runs on CSELabs.
● A list of CSELabs machines can be found at https://cse.umn.edu/cseit/classrooms-labs
○ Try to stick with the Keller Hall computers since those are what we’ll use to test your code
● Helpful GDB manual. From Huang: GDB Tutorial From Kauffman: Quick Guide to gdb