Update chapters/io/optimizations/drills/tasks/async-server/tests/check_server.sh

Co-authored-by: Teodor Dutu <[email protected]>

Author: raress04

chapters/io/ipc/drills/tasks/client-server/README.md

@@ -1,6 +1,6 @@
 # Ordered Client-Server Communication
 
-Navigate to `chapters/io/ipc/drills/tasks/client-server/` and run `make` to generate the `support` directory.
+Navigate to `client-server` directory of the extracted archive (or `chapters/io/ipc/drills/tasks/client-server/` if you are working directly in the repository) and run `make` to generate the `support` directory.
 This exercise will guide you in creating a basic messaging protocol between a server and a client.
 Although in real-world applications a server typically handles multiple connections at once, here we focus on a single connection.
 Handling multiple connections is further explored in [I/O multiplexing](../../../../io-multiplexing/reading/io-multiplexing.md).

chapters/io/optimizations/drills/tasks/async-server/README.md

@@ -1,13 +1,12 @@
 # Async Server
 
-Navigate to `chapters/io/optimizations/drills/tasks/async-server` and run `make` to generate the `support` files.
-Enter `support` and run `make test-file.txt` to generate the test file.
+Navigate to `async-server` directory of the extracted archive (or `chapters/io/optimizations/drills/tasks/async-server` if you are working directly in the repository) and run `make` to generate the `support` files. Enter `support` and run `make test-file.txt` to generate the test file.
 
 This task builds on the previous example of a [multiplexed client-server](../../tasks/multiplexed-client-server/README.md).
 The server accepts connections from clients and downloads a file of `100MB` from each.
 After uploading the file, the clients close the connection.
 
-1. Open `server.c` and complete the TODOs in the main function to setup IO multiplexing using [`epoll`](https://man7.org/linux/man-pages/man7/epoll.7.html).
+1. Look at the code in `support` and open `server.c` and complete the TODOs in the main function to setup IO multiplexing using [`epoll`](https://man7.org/linux/man-pages/man7/epoll.7.html).
    Use `epoll_create()`, `epoll_wait()`, and the wrappers defined in `w_epoll.h` to handle descriptors without blocking.
    **Remember** to remove the client sockets from the `epoll` instance before closing them.
 

chapters/io/optimizations/drills/tasks/async-server/tests/check_server.sh

@@ -3,7 +3,7 @@
 
 TEST_FILE="../support/test-file.txt"
 if [ ! -f "$TEST_FILE" ]; then
-    echo "run make test-file.txt to generate the test file"
+    echo "run make test-file.txt in the `support/` folder to generate the test file"
     exit 1
 fi
 
@@ -25,7 +25,7 @@ rm -f "$SERVER_LOG" "$CLIENT_LOG"
 PID_LIST=$(lsof -ti tcp:$PORT)
 if [ -n "$PID_LIST" ]; then
     echo "Killing previous server processes on port $PORT: $PID_LIST"
-    kill -9 "$PID_LIST"
+    lsof -ti tcp:$PORT | xargs kill -9
     sleep 1
 fi
 

chapters/io/optimizations/drills/tasks/multiplexed-client-server/README.md

@@ -1,6 +1,6 @@
 # Multiplexed Client Server
 
-Navigate to `chapters/io/optimizations/drills/tasks/multiplexed-client-server` and run `make` to generate the `support` files.
+Navigate to `multiplexed-client-server` directory of the archive, (or `chapters/io/optimizations/drills/tasks/multiplexed-client-server` if you are working directly in the repository) and run `make` to generate the `support` files.
 
 This task builds on the previous implementation of a [client-server ordered communication](../../../../ipc/drills/tasks/client-server/README.md).
 Previously, the client and server followed a strict, sequential communication pattern: each peer had to send a message and wait for a reply before proceeding.

chapters/io/overview/reading/overview.md

@@ -1,5 +1,7 @@
 # I/O
 
+The contents of the lab are located in the [lab archive](https://github.com/cs-pub-ro/operating-systems/raw/refs/heads/lab-archives/Lab_11_IO_Optimizations.zip) and in the [GitHub repository](https://github.com/cs-pub-ro/operating-systems).
+
 We know that a compute system is a collection of hardware and software that modifies data.
 This data has to come from _somewhere_.
 This _somewhere_ is always outside the compute system: files, network packets, radio signals, sensor data.