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

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