hw5

.pdf

School

University of Illinois, Chicago *

*We aren’t endorsed by this school

Course

362

Subject

Computer Science

Date

Apr 3, 2024

Type

pdf

Pages

5

Uploaded by KaruleanZ

Report
Homework 5 - Concurrent Server with Threads CS 361 - Fall 2023 - Maratos Description In this assignment we will be implementing a server that handles client requests concurrently. You will use your solution to HW4 as the starting point. 1 Threading Models Your solution will implement two models for managing threads to handle client requests. 1. One Thread Per Connection - In this mode, each client request will be handled by a single thread that was created for this task. The peer thread will read the request from the socket and handle it accordingly. After the transaction is done the peer thread should terminate. 2. Thread Pool - In this mode, the server is initialized with a main thread and a pool of N peer threads. The main thread accepts connection requests and makes the connection available for the peer threads. The peer threads run the following loop: 1. wait for a new client, 2. handle the client, 3. close the connection to the client, and 4. loop back and wait for another client. We will discuss the producer-consumer design pattern in class and you will use that approach in your implementation for this homework. 2 Concurrency Requirements If any client accesses the following URL’s they should be handled concurrently and without interfering with each other: /ping , /echo , and generic GET requests for files. For example, if Client 1 requests /ping and another requests /echo then they will be handled concurrently. 3 Implementation Guide Start by implementing the thread per connection model for your concurrent server. It is only tests 9 and 10 that are relevant to the thread pool model. Figure out what data is shared amongst all the threads. try to minimize the number of shared data regions by making variables private some data will have to be shared and in those circumstances you should be iden- tifying critical regions in your code Minimize the number of critical regions in your code and keep them small. There are two drop in replacements for recv and send and you must use them in your code. 1
int recv_http_request(int connfd, char * buffer, int max_size, int opts) int send_fully(int connfd, const char * data, int size, int opts) 4 Safety Requirements 4.1 Safe Read/Write Reading or writing data should be atomic which means that the operation should either happen completely or not at all. Consider the following scenarios. Scenario 1 - Good Write 1. Client 1 executes in parallel with Client 2 2. Client 1 performs a /write with data aaaaaaaaaaa 3. Client 2 performs a /write with data bbbbbbbbbbb 4. Client 3 performs a /read 5. Client 3 receives either aaaaaaaaaaa or bbbbbbbbbbb Scenario 2 - Bad Write (this should not happen) 1. Setup is the same as Scenario 1 through Step 4 2. Client 3 reads a combination of a and b . For example aaabbbb... Scenario 3 - Good Read 1. Client 1 performs a /write with data aaaaaaaaaaa 2. Client 2 and 3 execute in parallel 3. Client 2 performs a /write with data bbbbbbbbbbb 4. Client 3 performs a /read 5. Client 3 receives either aaaaaaaaaaa or bbbbbbbbbbb Scenario 4 - Bad Read (this should not happen) 1. Setup is the same as Scenario 3 through Step 4 2. Client 3 reads a combination of a and b . For example aaabbbb... 2
4.2 Safe stats You can assume that /stats is only accessed by a single client without any other concurrent clients. When a client requests /stats your server should account for all previous requests accurately. Consider the following scenarios below. Scenario 1 - Good stats 1. There are 100 clients handled concurrently. 50 of the resulting transactions transfer 10 header bytes and 10 body bytes. 50 transactions are errors resulting in transferring 10 bytes. 2. After all 100 clients finish another client accesses /stats . 3. The server responds that there were 50 requests, 50 errors, 500 header bytes, 500 body bytes, and 500 error bytes. Scenario 2 - Bad stats 1. Same as Scenario 1 from Steps 1 and 2. 2. Any of the statistics are reported differently than Scenario 1 Step 3. 5 Quick Explanations of Test Cases Many of these tests are checking for the same functionality that was described in HW 4. While functionality is the same for many scenarios, the server is implemented in a different way by handling clients with threads instead of I/O multiplexing. You can use HW 4 as a reference for what many of the HTTP responses would look like. 5.1 One These test cases just make sure your implementation can handle the following with a single thread. 1. accepting connection requests 2. ping requests This will require adapting some of our solution from HW 4. See the introduction video for HW 5 which solves this test case. Remember for future tests that you should initialize global variables and create threads in create_server_socket . Remember that you should use the utility methods for reading and writing HTTP responses: recv_http_request and send_fully instead of calling send and recv directly. 5.2 Two, Three, Four, and Five These tests will check if your server supports most of the features you had implemented for HW4: /ping , /echo , generic file with GET , and simply accepting connections. 3
Your preview ends here
Eager to read complete document? Join bartleby learn and gain access to the full version
  • Access to all documents
  • Unlimited textbook solutions
  • 24/7 expert homework help
5.3 Six, Seven, and Eight These tests will check your server’s ability to handle reads and writes and report statistics. Make sure you are following the advice we gave in Section 3 on handling shared data and critical regions. Furthermore, tests seven and eight can pass with an incorrect implementation so to get credit for these you need to answer two questions which are described in Section 6 and submit your answers to Gradescope. Test eight checks your implementation for /stats . It is worth mentioning that you could be failing tests because of a mismatch in versions of curl on your local machine. In that situation make sure to double check with GitHub to see if you are actually failing the test or simply have this discrepancy. 5.4 Nine and Ten These tests work a little differently than the previous. Make sure you read through Section 7 to understand how they work. 6 Questions Tests 7 and 8 are non-deterministic and they can pass with incorrect solutions depending on thread scheduling. To get credit for these tests you need to answer the following questions and submit them to Gradescope. 1. What measures does your solution take to ensure safe read/write (Described in Section 4.1) while maintaining the requirements for concurrency? 2. What measures does your solution take to ensure safe stats (Described in Section 4.2) while maintaining the requirements for concurrency? 7 Important Comments on Thread Pool Once you have implemented and passed the first 8 tests you can work on your thread pool implementation. This is done by modifying the makefile and changing the first line from FLAG=T910=0 to FLAG=T910=1 . This will change the test environment so that threads can only be created at the start in create_server_socket . Furthermore, any thread that exits will cause the server to terminate. In the Thread Pool model, threads are supposed to be long lived and exist for the lifetime of the server. With this flag set your implementation will most likely fail previous test cases and you will need to fix it. Test 09 corresponds to tests 1-4 and Test 10 corresponds to tests 5-8. 4
8 Entry Point You will do your work in hw5.c and make a small change to makefile (see Section 7) when you start working on the thread pool model for tests 09 and 10. 9 Due Date and Resubmission Policy The deadline for this homework is 11/22 11:59 PM. There is no late policy. There will be no extensions granted for this assignment. Your submission is the last commit you made in your repository. We will use the timestamp of this commit to verify the assignment was completed on time. Assuming you have attended Labs 09, 10, and 11 you can resubmit your work up to one week after the deadline, 11/29 11:59 PM. You must also submit a written document that describes the changes you made since the deadline. The written document is how you can demonstrate your understanding of what was missing in your original submission. 10 Bonus Points You can earn up to 10% bonus points from endorsed posts you make on Piazza. Re- member to claim those points by filling out the form mentioned in the Syllabus - https://forms.gle/DgCzbVFp6jZYS6UQ8 You can earn 15% bonus points for completing Labs 09, 10, and 11. 11 Hardcoding and Academic Integrity Just as a reminder, the syllabus policy on academic integrity will be enforced. Also, if we discover that you are subverting the goal of the assignment and gaming the autograder to simply earn points is a zero on the assignment. If your code is trying to detect that a certain input is given (because you know it is associated with a specific test) and simply output an expected result (without doing the reasonable work required by the assignment) then that is gaming the autograder. If you have further questions on what would be considered ”gaming” then post them on Piazza as soon as you have them. 5