Add the indicatif crate to Cargo.toml.

Add the `indicatif` crate to `Cargo.toml`.

Mục tiêu:

Congratulations on achieving a massive milestone! You have successfully integrated both the sender and receiver logic into a single, cohesive command-line application. Your p2p_file_sharer is now a complete, end-to-end program that can successfully transfer files between two machines. This is a fantastic accomplishment and the solid foundation upon which we will now build more advanced, user-friendly features.

While the application is functionally complete, the user experience during a large file transfer is still a bit of a mystery. Once the transfer begins, the user is left staring at a static terminal, with no indication of progress, speed, or estimated time remaining. This “black box” experience is something we can dramatically improve. Our next major goal is to provide real-time feedback with a visual progress bar.

To achieve this without reinventing the wheel, we will leverage the power of the Rust ecosystem by adding an external library, or “crate,” to our project.

Introducing `indicatif`: Your Go-To Crate for Console Progress Bars

The Rust community maintains a public registry of open-source libraries at crates.io. For creating beautiful and highly functional command-line progress bars and spinners, one of the most popular and powerful crates is indicatif. It’s designed to be easy to use for simple cases while providing extensive customization options for more advanced scenarios.

Before we can use indicatif in our Rust code, we must first declare it as a dependency of our project. This is done in the Cargo.toml file, which acts as the manifest and configuration file for your entire project.

Adding a Dependency in `Cargo.toml`

The Cargo.toml file contains a section called [dependencies]. This is where you list all the external crates your project needs to compile and run. When you build your project, Cargo reads this list, automatically downloads the specified versions of these crates from crates.io, compiles them, and links them into your final executable. This dependency management is one of Cargo’s most powerful features.

Your task now is to open your Cargo.toml file and add indicatif to this list.

Open your project’s Cargo.toml file and add the highlighted line under the [dependencies] section. It’s conventional to keep dependencies listed in alphabetical order.

[package]
name = "p2p_file_sharer"
version = "0.1.0"
edition = "2021"

[dependencies]
bincode = "1.3.3"
clap = { version = "4.5.4", features = ["derive"] }
# HIGHLIGHT START
indicatif = "0.17.8"
# HIGHLIGHT END
serde = { version = "1.0.198", features = ["derive"] }

Let’s break down this addition:

indicatif: This is the name of the crate, which must match its name on crates.io.
=: The equals sign separates the crate name from its version requirement.
"0.17.8": This is the version string. By specifying a specific version, you ensure that your build is repeatable and won’t be broken by unexpected changes in a future version of the library. This is known as “pinning” a dependency. It’s a best practice for application development to ensure stability.

What Happens Next?

With this single line added, you have successfully declared your project’s dependency on the indicatif crate. You don’t need to run any special command right now. The next time you run cargo build, cargo run, or cargo check, Cargo will perform the following steps automatically:

Resolve Dependencies: It will read your Cargo.toml, see the new indicatif dependency, and also find any dependencies that indicatif itself has.
Download: It will download the necessary versions of indicatif and its dependencies from crates.io if they aren’t already cached on your machine.
Compile: It will compile all these new crates.
Link: It will make the public functions, structs, and macros from indicatif available for you to use in your own code.

You have now successfully equipped your project with a powerful new tool. The next step is to wield that tool. You’ll begin by modifying your sender and receiver functions to set up the foundational components for tracking progress: a shared, thread-safe counter using Rust’s concurrency primitives, Arc and Mutex.

In both sender and receiver functions, create a counter for bytes transferred: `let bytes\_transferred = Arc::new(Mutex::new(0));`

Mục tiêu:

Excellent work adding the indicatif crate to your project’s dependencies! You’ve successfully equipped our application with a powerful tool for creating a professional user experience. However, a progress bar is only as good as the data it displays. Before we can draw anything on the screen, we need a mechanism to track the progress of our file transfer in a way that the progress bar can safely access.

This leads us to a classic and fascinating challenge in systems programming: concurrency. Our file transfer happens in a tight, blocking I/O loop. If we try to update a progress bar inside that same loop, the updates will be jerky and tied to our network buffer size. A much smoother experience is achieved by having the I/O loop focus solely on transferring data, while a separate piece of logic periodically checks the progress and updates the display.

To make this work, these two separate parts of our program need to safely access and modify the same piece of data—the number of bytes transferred. Our current byte counters are simple local variables (let mut bytes_transferred = 0;), which cannot be accessed from outside their own function, let alone by another thread. Our current task is to upgrade this simple counter into a sophisticated, thread-safe data structure that can be shared.

To do this, we will use two of the most important concurrency primitives from Rust’s standard library: Arc and Mutex.

Understanding the Tools: `Mutex` and `Arc`

When you want to share data that can be changed between threads, you face two primary problems:

Data Races: How do you prevent two threads from trying to write to the same memory location at the exact same time, which can corrupt the data?
Ownership: How can multiple threads “own” the same piece of data, when Rust’s ownership rules strictly enforce that a value can only have one owner?

Rust provides elegant solutions for both:

Mutex<T> (Mutual Exclusion): A Mutex is a “lock” that you can wrap around a piece of data. Before any thread can access the data, it must first acquire the lock. While that thread holds the lock, no other thread can acquire it—they have to wait their turn. Once the first thread is done, it releases the lock, allowing another waiting thread to proceed. This mechanism guarantees that only one thread can access the data at a time, completely eliminating data races.
Arc<T> (Atomically Reference Counted): An Arc is a “smart pointer” that solves the ownership problem. It wraps a value and allows for multiple, shared owners. It works by keeping a count of how many active owners exist. When you clone() an Arc, you aren’t actually copying the data inside it (which could be very large and expensive); you are just creating a new pointer to the same data and incrementing the internal reference count. This is a very cheap operation. When an Arc pointer goes out of scope, the reference count is decreased. When the count reaches zero, it means no owners are left, and the data can be safely cleaned up.

By combining these two, Arc<Mutex<T>>, we create a powerful and very common Rust pattern for sharing mutable state across threads. The Arc allows multiple threads to have shared ownership of the Mutex, and the Mutex ensures that only one thread at a time can actually modify the data hidden inside.

Implementing the Thread-Safe Counter

Let’s apply this pattern to both our sender and receiver logic. We will replace our simple u64 counters with this new, thread-safe version.

In `sender.rs`

First, open src/sender.rs. We need to bring Arc and Mutex into scope and then create our new counter.

// src/sender.rs

// ... (your existing `use` statements)
use std::fs::File;
use std::io::{Read, Write};
use std::net::{TcpListener, TcpStream};
use std::path::Path;
// HIGHLIGHT START
// Import the concurrency primitives from the standard library's `sync` module.
// `Arc` stands for "Atomically Reference Counted", a smart pointer for shared ownership.
// `Mutex` stands for "Mutual Exclusion", a lock to protect shared data.
use std::sync::{Arc, Mutex};
// HIGHLIGHT END

pub fn start_sender(file_path: &Path) {
    // ... (listener binding and metadata creation logic remains the same)
    let file_size = std::fs::metadata(file_path)
        .expect("Failed to get file metadata")
        .len();

    let filename = file_path
        .file_name()
        .unwrap()
        .to_str()
        .unwrap()
        .to_string();

    let metadata = crate::FileMetadata {
        filename,
        size: file_size,
    };

    // ... (metadata serialization and writing to stream)

    // --- HIGHLIGHT START ---
    // Create a new, thread-safe counter for tracking the bytes transferred.
    // 1. `Mutex::new(0u64)`: We create a new Mutex, wrapping our counter value (a u64, initialized to 0).
    // 2. `Arc::new(...)`: We wrap the Mutex in an Arc. This allows us to share ownership
    //    of the Mutex between the main thread (for the progress bar) and the
    //    networking thread (which will do the actual file transfer).
    let bytes_transferred = Arc::new(Mutex::new(0u64));
    // --- HIGHLIGHT END ---

    let mut file = File::open(file_path).expect("Failed to open file for reading");
    let mut buffer = [0u8; 8192];

    // ... (the rest of the I/O loop remains the same for now)
}

In `receiver.rs`

Next, we’ll do the exact same thing in src/receiver.rs. Here, we will be replacing the existing bytes_received variable with our new, more powerful version.

// src/receiver.rs

use crate::FileMetadata;
use std::fs::File;
use std::io::{Read, Write};
use std::net::TcpStream;
// HIGHLIGHT START
use std::sync::{Arc, Mutex};
// HIGHLIGHT END

pub fn start_receiver(server_address: &str) {
    // ... (connection and metadata deserialization logic remains the same)

    let mut file = File::create(&metadata.filename)
        .expect("Failed to create file on local disk");

    // --- HIGHLIGHT START ---
    // We replace the old `let mut bytes_received: u64 = 0;` with this new
    // thread-safe counter. The principle is identical to the sender's implementation.
    // This shared counter will be updated by the networking thread and read by the
    // main thread to update the progress bar.
    let bytes_transferred = Arc::new(Mutex::new(0u64));
    // --- HIGHLIGHT END ---

    println!("-> Created file '{}'. Ready to receive {} bytes.", metadata.filename, metadata.size);

    let mut buffer = [0u8; 8192];
    println!("\n-> Starting file download...");

    // The `while` loop condition will need to be updated in a future step
    // to read from this new counter.
    let mut bytes_received_for_loop = 0; // Temporary for now
    while bytes_received_for_loop < metadata.size {
        // ... (the rest of the I/O loop remains the same for now)
    }

    // ... (rest of the function)
}

Note: We’ve added a temporary local variable bytes_received_for_loop in the receiver just to keep the compiler happy for this task. We will remove it and properly integrate the Arc<Mutex<...>> counter into the loop logic in a later task.

You have now successfully set up the foundational data structure for our progress reporting. This bytes_transferred variable is no longer a simple number; it’s a sophisticated, thread-safe piece of shared state, ready to coordinate the work between our networking logic and our user interface.

What’s Next?

With our thread-safe counter in place, we are now ready to use the indicatif crate. The next task will be to create an instance of indicatif’s ProgressBar. We will initialize it, setting its total length to the file size we get from the metadata, making it visually aware of the total scope of the work to be done.

Create a new `ProgressBar` from the `indicatif` crate, setting its length to the total file size.

Mục tiêu:

You’ve done an outstanding job setting up the backbone for our progress indicator! By creating a thread-safe counter with Arc<Mutex<u64>>, you’ve built the data source that will drive our progress bar. This counter is the single source of truth for how many bytes have been transferred. Now, it’s time to create the visual component that will read this data and present it to the user in a clean, intuitive way.

Our current task is to use the indicatif crate to create a ProgressBar instance. This object is the heart of the visual display; it’s what we will interact with to draw and update the bar on the console.

The Anatomy of a Progress Bar: Length is Everything

A progress bar is fundamentally a visual representation of a value between a starting point (usually 0) and an endpoint (the total amount of work). In indicatif, this endpoint is called the length.

Setting the length is arguably the most critical step in creating a meaningful progress bar. When you tell the ProgressBar its total length, you give it the context it needs to calculate all the useful information a user wants to see:

Percentage Complete: It can calculate (current_progress / total_length) * 100.
Estimated Time of Arrival (ETA): By observing the rate of progress, it can estimate how long it will take to reach the total length.
Transfer Speed: It can show how many bytes are being transferred per second.
Visual Bar: It knows how to scale the visual [████░░░░] part of the bar relative to the total length.

In our project, this “total length” maps perfectly to the total size of the file being transferred. We already have this information available in both the sender and receiver logic.

Let’s now create this progress bar object in both modules.

Implementing in `sender.rs`

In the sender’s logic, we calculate the file size using std::fs::metadata. We will pass this value directly to the ProgressBar when we create it.

First, open src/sender.rs and bring the ProgressBar type into scope at the top of the file.

// src/sender.rs

// ... (your existing `use` statements)
use std::sync::{Arc, Mutex};
// HIGHLIGHT START
// Import the primary struct for creating and managing progress bars.
use indicatif::ProgressBar;
// HIGHLIGHT END

Now, within the start_sender function, create the ProgressBar right after you’ve set up your thread-safe counter.

// src/sender.rs

// ... (inside `pub fn start_sender`)

    // ... (logic to get file_size and create metadata)

    // Create a new, thread-safe counter for tracking the bytes transferred.
    let bytes_transferred = Arc::new(Mutex::new(0u64));

    // --- HIGHLIGHT START ---
    // Create a new ProgressBar instance from the indicatif crate.
    // The `ProgressBar::new()` function takes one argument: the total length of the bar.
    // We provide the `file_size` (a u64) so the progress bar knows what 100% is.
    // This allows it to automatically calculate percentages, ETAs, and transfer speeds.
    let pb = ProgressBar::new(file_size);
    // --- HIGHLIGHT END ---

    let mut file = File::open(file_path).expect("Failed to open file for reading");
    // ... (the rest of the function)

Implementing in `receiver.rs`

The process for the receiver is nearly identical. The only difference is the source of the file size information. Instead of reading it from the local filesystem, we use the size field from the FileMetadata struct that we received over the network.

First, open src/receiver.rs and add the corresponding use statement.

// src/receiver.rs

// ... (your existing `use` statements)
use std::net::TcpStream;
use std::sync::{Arc, Mutex};
// HIGHLIGHT START
use indicatif::ProgressBar;
// HIGHLIGHT END

Now, let’s create the ProgressBar in the start_receiver function.

// src/receiver.rs

// ... (inside `pub fn start_receiver`)

    // ... (logic to connect and deserialize metadata)
    let metadata: FileMetadata = bincode::deserialize_from(&mut stream)
        .expect("Failed to deserialize metadata from sender");
    println!("-> Received metadata: {:?}\\n", metadata);

    let mut file = File::create(&metadata.filename)
        .expect("Failed to create file on local disk");

    // We replace the old `let mut bytes_received: u64 = 0;` with this new
    // thread-safe counter.
    let bytes_transferred = Arc::new(Mutex::new(0u64));

    // --- HIGHLIGHT START ---
    // Create the ProgressBar for the receiver.
    // We use `metadata.size` which was sent by the sender. This ensures both the
    // sender and receiver have progress bars that agree on the total file size.
    let pb = ProgressBar::new(metadata.size);
    // --- HIGHLIGHT END ---

    println!("-> Created file '{}'. Ready to receive {} bytes.", metadata.filename, metadata.size);
    // ... (the rest of the function)

You have now successfully instantiated the ProgressBar in both the sender and receiver! You have a tangible object, pb, that represents the visual UI component. At this point, if you were to run the program, you still wouldn’t see anything because we haven’t told the progress bar to draw or update itself. We’ve simply created it and given it its most important piece of information: the finish line.

What’s Next?

With the thread-safe counter (bytes_transferred) and the visual component (pb) both ready, we have the two key ingredients for a concurrent UI. The next crucial step is to separate the work. We need to move the blocking I/O loop (the part that actually reads/writes file chunks over the network) into a new background thread. The main thread will then be free to manage the progress bar, periodically checking the shared counter and updating the display for a smooth, non-blocking user experience.

Offload Blocking I/O to a Worker Thread

Mục tiêu: Refactor the file transfer logic by moving the blocking I/O loops into a new background worker thread using std::thread::spawn. This separation prevents the main (UI) thread from freezing during file transfer, ensuring a smooth and responsive user experience.

You have done an absolutely brilliant job setting up the components for our real-time progress indicator. You have a thread-safe data source (Arc<Mutex<u64>>) to track the transfer’s progress and a visual UI component (indicatif::ProgressBar) ready to display it.

The challenge we face now is making them work together. Our networking code, with its read() and write_all() calls, is blocking. This means that while the program is waiting for data to come from the network or be written to the disk, it’s completely frozen, doing nothing else. If we try to update our progress bar on the same thread as this blocking I/O, the UI would be unresponsive, updating in jerky bursts only after a full 8KB chunk is processed. The user experience would be poor.

To solve this, we will employ one of the most fundamental patterns in modern software development: we will separate the work onto different threads.

The Worker Thread and the UI Thread

The solution is to create a division of labor:

The Main Thread (UI Thread): This thread, the one our main function runs on, will be responsible for one thing only: managing the user interface. It will periodically check the transfer progress and update the ProgressBar.
The Worker Thread: We will spawn a new, separate background thread whose sole responsibility is to perform the heavy, blocking work of the file transfer—the I/O loop that reads and writes data chunks.

This separation ensures that even while the worker thread is blocked waiting for the network, our main thread is free to run, keeping the progress bar smooth and the application feeling responsive.

To create this new thread, we will use Rust’s primary tool for the job: std::thread::spawn.

Spawning a New Thread with `std::thread::spawn`

The std::thread::spawn function takes a single argument: a closure. A closure is essentially an anonymous, on-the-fly function. The code you put inside this closure will be executed on a new operating system thread.

A crucial aspect of this is ownership. The new thread you create will likely outlive the current function’s scope. Therefore, it needs to take full ownership of any variables it uses from the surrounding environment. We tell Rust to enforce this by using the move keyword right before the closure’s argument list (e.g., move || { ... }). This move closure takes ownership of variables like our TcpStream and File handle, moving them out of the main thread and into the new worker thread.

Let’s now apply this powerful concept to both our sender and receiver.

Refactoring `sender.rs`

In sender.rs, we will wrap the entire loop that performs the file I/O inside thread::spawn.

First, bring the thread module into scope at the top of src/sender.rs.

// src/sender.rs

// ... (your existing `use` statements)
use std::sync::{Arc, Mutex};
// HIGHLIGHT START
use std::thread;
// HIGHLIGHT END

Now, modify the start_sender function to move the I/O loop into a new thread.

// src/sender.rs

// ... (inside `pub fn start_sender`)

    let pb = ProgressBar::new(file_size);

    let mut file = File::open(file_path).expect("Failed to open file for reading");
    let mut buffer = [0u8; 8192];

    // --- HIGHLIGHT START ---

    // `thread::spawn` creates a new thread and runs the provided closure in it.
    // The `move` keyword is crucial: it forces the closure to take ownership of the
    // variables it uses from the environment, such as `stream`, `file`,
    // and `bytes_transferred`. This is required because the new thread might
    // outlive the current function.
    let handle = thread::spawn(move || {
        // This is the core I/O loop, now running on a separate background thread.
        loop {
            let bytes_read = match file.read(&mut buffer) {
                Ok(0) => break, // End of file reached.
                Ok(n) => n,
                Err(e) => {
                    eprintln!("Error reading from file: {}", e);
                    break;
                }
            };

            if let Err(e) = stream.write_all(&buffer[..bytes_read]) {
                eprintln!("Error writing to stream: {}", e);
                break;
            }
            // In a future task, we will update `bytes_transferred` here.
        }
    });

    // --- HIGHLIGHT END ---

    // The main thread will now continue execution here immediately,
    // while the I/O loop runs in the background. In later tasks, we will add
    // code here to monitor the progress and wait for the `handle` to finish.
    println!("-> File transfer thread started.");

Refactoring `receiver.rs`

We will do the exact same thing for the receiver. The entire while loop will be moved into a thread::spawn closure.

First, add the use statement to src/receiver.rs.

// src/receiver.rs

// ... (your existing `use` statements)
use std::sync::{Arc, Mutex};
// HIGHLIGHT START
use std::thread;
// HIGHLIGHT END

Now, update start_receiver to create the worker thread. Note that the local counter, bytes_received, will now live entirely inside the new thread.

// src/receiver.rs

// ... (inside `pub fn start_receiver`)

    let pb = ProgressBar::new(metadata.size);

    println!("-> Created file '{}'. Ready to receive {} bytes.", metadata.filename, metadata.size);

    let mut buffer = [0u8; 8192];
    println!("\n-> Starting file download...");

    // --- HIGHLIGHT START ---

    // Spawn a new worker thread to handle the blocking network I/O.
    // The `move` closure takes ownership of `stream`, `metadata`, `file`,
    // and the `bytes_transferred` Arc, which it will need to update progress.
    let handle = thread::spawn(move || {
        // This local counter is now private to the worker thread.
        let mut bytes_received: u64 = 0;

        // The entire download loop now runs in the background.
        while bytes_received < metadata.size {
            let bytes_read = match stream.read(&mut buffer) {
                Ok(0) => {
                    println!("-> Connection closed by sender unexpectedly.");
                    break;
                }
                Ok(n) => n,
                Err(ref e) if e.kind() == std::io::ErrorKind::Interrupted => continue,
                Err(e) => {
                    eprintln!("Error reading from stream: {}", e);
                    break; // Use eprintln for errors
                }
            };

            if let Err(e) = file.write_all(&buffer[..bytes_read]) {
                eprintln!("Failed to write chunk to file: {}", e);
                break;
            }

            bytes_received += bytes_read as u64;
            // In a future task, we'll also update the shared `bytes_transferred` here.
        }
    });

    // --- HIGHLIGHT END ---

    // The main thread continues here, free to manage the UI.
    println!("-> File download thread started.");

Understanding the `JoinHandle`

The thread::spawn function returns a JoinHandle. This handle is a special object that represents the running thread. We’ve stored it in a variable named handle. For now, we aren’t using it, but it will become critical later. We can call handle.join() to make our main thread wait until the worker thread has finished its execution. This is how we’ll know the file transfer is truly complete.

You have now successfully decoupled your application’s logic. The heavy, blocking I/O is offloaded to a background thread, leaving your main thread free and responsive. This is a massive step towards building a truly professional and user-friendly application.

What’s Next?

With the worker thread created, we now need to establish the communication link between it and the main thread. Our Arc<Mutex<...>> is the key. In the next task, you will clone the Arc and move the clone into the new thread. This will give both threads shared ownership of the counter, preparing the way for the worker thread to update the progress and the main thread to read it.

Clone the `Arc` and move it into the new thread.

Mục tiêu:

You’ve successfully taken a monumental step by decoupling your application’s logic! By moving the blocking I/O operations into a background thread with std::thread::spawn, you have laid the architectural foundation for a responsive, modern command-line application. The main thread is now free to handle the user interface, while the new worker thread is dedicated to the heavy lifting of data transfer.

However, this separation has introduced a new, classic concurrency puzzle. The move keyword on your closure was essential—it ensured the new thread took ownership of the TcpStream and File handles. But in doing so, it also took ownership of our precious Arc<Mutex<...>> counter. This leaves the main thread with no way to access the progress information! How can two different threads both “own” and access the same piece of data?

This is the exact problem that Arc (Atomically Reference Counted pointer) was designed to solve, and its clone() method is the key.

The Magic of `Arc::clone()`: Shared, Not Copied

When you call clone() on most types in Rust (like a String), you typically get a completely new, independent copy of the data. This is often called a “deep clone” and can be an expensive operation if the data is large.

Cloning an Arc is fundamentally different and incredibly cheap. When you clone an Arc, you are not cloning the data inside it. Instead, you are creating a new pointer to the exact same data on the heap and atomically incrementing an internal reference counter.

Think of it like this: * You have one treasure chest on an island (Mutex<u64>). * You create the first treasure map (Arc::new). The map has a note: “1 map exists.” * When you Arc::clone(), you are just making a photocopy of the treasure map. You don’t create a new treasure chest. Now you have two maps, and the note is atomically updated to say “2 maps exist.”

This mechanism allows multiple variables, even across different threads, to have shared ownership of the same underlying data. When a map (Arc pointer) is destroyed (goes out of scope), the count is decreased. When the count reaches zero, Rust knows that no one can access the treasure anymore, and the chest itself is safely removed.

Our task now is to use this mechanism. We will clone our Arc before spawning the thread. The new thread will take ownership of the clone, while the original Arc remains with the main thread.

Updating `sender.rs` with `Arc::clone`

Let’s modify src/sender.rs to implement this pattern.

// src/sender.rs

// ... (your existing `use` statements)
use indicatif::ProgressBar;
use std::fs::File;
use std::io::{Read, Write};
use std::net::{TcpListener, TcpStream};
use std::path::Path;
use std::sync::{Arc, Mutex};
use std::thread;

pub fn start_sender(file_path: &Path) {
    // ... (listener binding, metadata, and connection logic)
    // ... (stream.write_all for metadata)

    let file_size = std::fs::metadata(file_path) /* ... */ .len();
    let bytes_transferred = Arc::new(Mutex::new(0u64));
    let pb = ProgressBar::new(file_size);

    // --- HIGHLIGHT START ---
    // Before spawning the thread, we create a clone of the Arc.
    // This creates a new pointer to the same shared Mutex, incrementing the
    // reference count from 1 to 2. This operation is very cheap.
    let bytes_transferred_clone = Arc::clone(&bytes_transferred);
    // --- HIGHLIGHT END ---

    let mut file = File::open(file_path).expect("Failed to open file for reading");
    let mut buffer = [0u8; 8192];

    // The `move` closure will now capture and take ownership of `bytes_transferred_clone`.
    // The original `bytes_transferred` remains owned by this main thread, allowing us
    // to read the progress from it later to update the progress bar.
    let handle = thread::spawn(move || {
        loop {
            let bytes_read = match file.read(&mut buffer) {
                Ok(0) => break,
                Ok(n) => n,
                Err(e) => {
                    eprintln!("Error reading from file: {}", e);
                    break;
                }
            };

            if let Err(e) = stream.write_all(&buffer[..bytes_read]) {
                eprintln!("Error writing to stream: {}", e);
                break;
            }

            // In the next task, we will use `bytes_transferred_clone` to update the counter.
        }
    });

    println!("-> File transfer thread started.");
    // ...
}

Updating `receiver.rs` with `Arc::clone`

The logic for the receiver is identical. We clone the Arc so that both the new worker thread and the main UI thread can share access to the counter.

// src/receiver.rs

// ... (your existing `use` statements)
use indicatif::ProgressBar;
use std::fs::File;
use std::io::{Read, Write};
use std::net::TcpStream;
use std::sync::{Arc, Mutex};
use std::thread;

pub fn start_receiver(server_address: &str) {
    // ... (connection and metadata deserialization logic)

    let mut file = File::create(&metadata.filename)
        .expect("Failed to create file on local disk");

    let bytes_transferred = Arc::new(Mutex::new(0u64));
    let pb = ProgressBar::new(metadata.size);

    // --- HIGHLIGHT START ---
    // Just as in the sender, we clone the Arc. This gives us a second "handle"
    // to our shared counter.
    let bytes_transferred_clone = Arc::clone(&bytes_transferred);
    // --- HIGHLIGHT END ---

    println!("-> Created file '{}'. Ready to receive {} bytes.", metadata.filename, metadata.size);

    let mut buffer = [0u8; 8192];
    println!("\n-> Starting file download...");

    // The `move` closure will now take ownership of the clone, leaving the original
    // `bytes_transferred` for the main thread to use.
    let handle = thread::spawn(move || {
        let mut bytes_received: u64 = 0;

        while bytes_received < metadata.size {
            // ... (the rest of the I/O loop remains the same)
            // ... (read from stream, write to file)

            bytes_received += bytes_read as u64;
            // In the next task, we'll update the shared `bytes_transferred_clone` here.
        }
    });

    println!("-> File download thread started.");
    // ...
}

You have now successfully established the link. Both the main thread and the worker thread hold their own Arc pointers, and both of these pointers refer to the exact same Mutex<u64> in memory. You have achieved safe, shared ownership across threads.

What’s Next?

With the communication channel now properly set up, the next logical step is to actually use it. Inside the worker thread’s I/O loop, after each successful chunk transfer, you will now lock the mutex and update the shared counter. This will be the first time you interact with the Mutex to safely mutate the shared state.

Inside the networking thread’s loop, after each chunk is transferred, lock the mutex and update the counter.

Mục tiêu:

You have masterfully architected the concurrent structure of your application! By cloning the Arc, you’ve successfully established shared ownership of the progress counter. Your worker thread now holds a pointer (bytes_transferred_clone) to the exact same shared data that the main thread holds. The communication channel is open.

The next logical step is for the worker thread to start broadcasting its progress. After each chunk of data is successfully transferred, it needs to update the shared counter. This is where the second part of our Arc<Mutex<T>> combo comes into play: the Mutex. This task is all about safely locking the data, changing it, and then releasing the lock.

The Art of the Lock: Ensuring Safe Mutation

A Mutex (Mutual Exclusion) acts as a gatekeeper for the data it protects. The rule is simple and absolute: to access the data, you must first ask the gatekeeper for the key (acquire the lock). While you have the key, no one else can get one. When you are finished, you return the key (release the lock), allowing the next person in line to proceed. This mechanism completely prevents “data races,” where two threads might try to modify the same data simultaneously, leading to corruption and chaos.

In Rust, this process is made incredibly safe and ergonomic through a concept called RAII (Resource Acquisition Is Initialization).

Acquire the Lock: You call the .lock() method on the Mutex. This is a blocking call; if another thread currently holds the lock, your thread will pause and wait its turn.
Receive the Guard: When .lock() succeeds, it doesn’t return the data directly. Instead, it returns a special smart pointer called a MutexGuard. This guard “locks” the mutex for as long as it exists.
Access the Data: The MutexGuard acts like a key and a temporary, mutable reference to the data. You can access the data through the guard.
Automatic Release: The moment the MutexGuard variable goes out of scope (for example, at the end of a loop iteration), its drop function is automatically called. This function’s job is to release the lock. You never have to manually call an unlock() method, which eliminates a massive category of common concurrency bugs like forgetting to release a lock.

Let’s implement this safe and robust pattern in our worker threads.

Updating the Counter in `sender.rs`

In the sender’s worker thread, after we successfully write a chunk of data to the network stream, we’ll lock the mutex and increment the counter.

Modify the thread::spawn closure in src/sender.rs:

// src/sender.rs

// ... (inside the thread::spawn closure in start_sender)
let handle = thread::spawn(move || {
    loop {
        let bytes_read = match file.read(&mut buffer) {
            Ok(0) => break, 
            Ok(n) => n,
            Err(e) => {
                eprintln!("Error reading from file: {}", e);
                break;
            }
        };

        if let Err(e) = stream.write_all(&buffer[..bytes_read]) {
            eprintln!("Error writing to stream: {}", e);
            break;
        }

        // --- HIGHLIGHT START ---

        // This is the core of our thread communication.
        // 1. `bytes_transferred_clone.lock()`: We call lock() on our Arc'd Mutex.
        //    This waits for the lock to be available and then acquires it.
        //    The method returns a Result, which we .unwrap() for simplicity. A panic
        //    here would indicate that another thread panicked while holding the lock.
        // 2. `let mut num = ...`: The successful result is a `MutexGuard`. We bind it
        //    to a mutable variable `num`. This guard provides exclusive access to the data.
        let mut num = bytes_transferred_clone.lock().unwrap();

        // 3. `*num`: The `MutexGuard` is a smart pointer. To access the `u64` value
        //    inside, we must dereference it with the `*` operator.
        // 4. `+= ...`: We increment the shared counter by the number of bytes we
        //    just sent.
        *num += bytes_read as u64;

        // The `MutexGuard` (`num`) goes out of scope here at the end of the loop
        // iteration. Its destructor is automatically called, which releases the lock,
        // allowing the main thread (or any other thread) to acquire it.

        // --- HIGHLIGHT END ---
    }
});
// ...

Updating the Counter in `receiver.rs`

The logic for the receiver is identical. Inside the worker thread’s while loop, after successfully writing a chunk to the file and updating the local bytes_received counter, we will also update the shared bytes_transferred counter for the UI thread to see.

Modify the thread::spawn closure in src/receiver.rs:

// src/receiver.rs

// ... (inside the thread::spawn closure in start_receiver)
let handle = thread::spawn(move || {
    let mut bytes_received: u64 = 0;

    while bytes_received < metadata.size {
        let bytes_read = match stream.read(&mut buffer) {
            Ok(0) => {
                println!("-> Connection closed by sender unexpectedly.");
                break;
            }
            Ok(n) => n,
            Err(ref e) if e.kind() == std::io::ErrorKind::Interrupted => continue,
            Err(e) => {
                eprintln!("Error reading from stream: {}", e);
                break;
            }
        };

        if let Err(e) = file.write_all(&buffer[..bytes_read]) {
            eprintln!("Failed to write chunk to file: {}", e);
            break;
        }

        bytes_received += bytes_read as u64;

        // --- HIGHLIGHT START ---

        // As in the sender, we lock the mutex to gain exclusive access to the
        // shared counter. We use the clone of the Arc that was moved into this thread.
        let mut num = bytes_transferred_clone.lock().unwrap();

        // We update the shared value. The main thread will be able to see this
        // change on its next check.
        *num += bytes_read as u64;

        // The lock is automatically released here when `num` goes out of scope.
        // This brief lock duration is excellent for performance, as it minimizes
        // the time other threads might have to wait.

        // --- HIGHLIGHT END ---
    }
});
// ...

You have now completed the writer’s side of the contract. Your background worker threads are diligently performing the file transfer and, after every single chunk, they safely and efficiently publish their progress to the shared state. The foundation is now fully laid for a responsive and real-time user interface.

What’s Next?

With the worker thread now constantly updating the shared bytes_transferred value, the final piece of the puzzle is to implement the reader’s side. In the next and final task of this step, you will write the code for the main thread. It will enter a loop where it periodically locks the same mutex, reads the current progress, and uses that value to update the indicatif::ProgressBar, bringing your real-time UI to life.

Implement a UI Loop for a Concurrent Progress Indicator

Mục tiêu: Create a non-blocking UI loop on the main thread to display real-time file transfer progress. This involves polling a shared Arc counter, updated by a worker thread, and using its value to update an indicatif::ProgressBar, while using thread::sleep to avoid busy-waiting.

Absolutely masterful work! You have perfectly architected the concurrent foundation for our progress indicator. The worker thread is now diligently toiling in the background, transferring data and—most importantly—faithfully reporting its progress to the shared Arc<Mutex<...>> counter after every chunk. The communication channel is live.

Now, we arrive at the final, most satisfying task of this step: bringing the user interface to life. The main thread, which has been patiently waiting, will now step up to its new role as the UI manager. Its job is to read the progress from the shared counter and update the indicatif::ProgressBar, creating a smooth, real-time display for the user.

The Main Thread’s UI Loop

Our main thread is now free from the burden of blocking I/O. We can use this freedom to create a dedicated UI loop. This loop’s sole responsibility is to periodically check for progress updates and redraw the progress bar on the screen.

This introduces a few key challenges that we will solve:

Polling, Not Busy-Waiting: How do we check periodically without spinning the CPU at 100%? We’ll use std::thread::sleep to pause the UI loop for a brief moment (e.g., 100 milliseconds) between checks.
Reading the Progress: How do we safely read the value from the shared counter? We will lock the same Mutex the worker thread is using, read the value, and the lock will be released automatically.
Updating the Display: How do we tell indicatif to update? We’ll use the ProgressBar::set_position() method.
Knowing When to Stop: How does the main thread know when the file transfer is complete and the worker thread has finished? We’ll use the JoinHandle returned by std::thread::spawn.

Let’s implement this elegant final piece in both our sender and receiver.

Completing the `sender.rs` Logic

In src/sender.rs, after spawning the worker thread, we will add the UI loop to the main thread’s execution path.

// src/sender.rs

// ... (your existing `use` statements)
use std::thread;
// HIGHLIGHT START
// Import `Duration` to specify a time interval for sleeping.
use std::time::Duration;
// HIGHLIGHT END

// ... (inside `pub fn start_sender`)

    let handle = thread::spawn(move || {
        // ... (the entire worker thread I/O loop remains unchanged)
    });

    println!("-> File transfer thread started.");

    // --- HIGHLIGHT START ---

    // This is the UI loop, running on the main thread.
    // It continues as long as the worker thread (`handle`) is still running.
    // The `is_finished()` method is a non-blocking check.
    while !handle.is_finished() {
        // 1. Lock the mutex to read the current progress.
        // We lock the *original* `bytes_transferred` Arc, which is owned by the main thread.
        let bytes = *bytes_transferred.lock().unwrap();

        // 2. Update the progress bar's position.
        // The `set_position` method tells the bar how much progress has been made.
        pb.set_position(bytes);

        // 3. Sleep for a short duration.
        // This prevents the UI loop from consuming 100% of a CPU core.
        // It's the key to efficient polling. 100ms is a good refresh rate for a CLI.
        thread::sleep(Duration::from_millis(100));
    }

    // After the loop, the transfer is done. We ensure the progress bar shows 100%.
    // We lock one last time to get the final, exact total.
    let final_bytes = *bytes_transferred.lock().unwrap();
    pb.set_position(final_bytes);

    // Mark the progress bar as finished and display a success message.
    pb.finish_with_message("-> File sent successfully!");

    // It's crucial to `join` the handle. This waits for the worker thread to completely
    // finish its execution, cleaning up its resources. It also propagates any panics
    // that might have occurred in the worker thread.
    handle.join().unwrap();

    // --- HIGHLIGHT END ---

Completing the `receiver.rs` Logic

The implementation for the receiver is identical. The main thread’s responsibility is the same: monitor the shared state and update the UI.

// src/receiver.rs

// ... (your existing `use` statements)
use std::thread;
// HIGHLIGHT START
use std::time::Duration;
// HIGHLIGHT END

// ... (inside `pub fn start_receiver`)

    let handle = thread::spawn(move || {
        // ... (the entire worker thread I/O loop remains unchanged)
    });

    println!("-> File download thread started.");

    // --- HIGHLIGHT START ---

    // The UI loop for the receiver, identical in principle to the sender's.
    // It polls the shared state while the background download is in progress.
    while !handle.is_finished() {
        // Lock, read the value, and update the progress bar.
        let bytes = *bytes_transferred.lock().unwrap();
        pb.set_position(bytes);

        // Pause to avoid busy-waiting.
        thread::sleep(Duration::from_millis(100));
    }

    // Final update to ensure the bar is at 100%.
    let final_bytes = *bytes_transferred.lock().unwrap();
    pb.set_position(final_bytes);

    // Mark as finished and provide a confirmation message to the user.
    pb.finish_with_message("-> File received successfully!");

    // Wait for the worker thread to terminate cleanly.
    handle.join().unwrap();

    // --- HIGHLIGHT END ---

Deconstructing the UI Loop

This new block of code is the culmination of our efforts. Let’s analyze it:

while !handle.is_finished(): This is the loop’s condition. The JoinHandle’s is_finished() method is a non-blocking check that returns true only after the worker thread has completed. Our loop continues as long as it’s not finished.
let bytes = *bytes_transferred.lock().unwrap();: This is the read side of our concurrent data sharing. The main thread blocks briefly to acquire the lock, copies the current value of the counter, and then the MutexGuard immediately goes out of scope, releasing the lock.
pb.set_position(bytes);: This is the core indicatif command. We tell the progress bar object what its new current value is. indicatif handles all the complex logic of redrawing the bar, updating the percentage, and recalculating the ETA.
thread::sleep(...): This is crucial for performance. Without it, this while loop would be a “busy-wait” loop, consuming an entire CPU core just to check a value. By sleeping, we yield control back to the operating system, making our application efficient and well-behaved.
pb.finish_with_message(...): This is a clean way to end the progress bar. It ensures the bar is at 100%, replaces the spinning ETA with a final message, and cleans up the line.
handle.join().unwrap(): This is a critical final step. While is_finished() lets us poll, join() makes the main thread block and wait until the worker thread has truly and completely finished. This guarantees that all file handles are closed and all resources are cleaned up before our start_sender/start_receiver function returns. It is the proper way to conclude a thread’s lifecycle.

Congratulations! You have successfully implemented a sophisticated, multi-threaded progress indicator. Your application now provides a professional, responsive, and informative user experience during file transfers.

What’s Next?

You have now reached a major plateau in the project’s development. The core file transfer mechanism is not only complete but also polished with a professional UI. The next major step in your project roadmap is to tackle a new and exciting challenge: “Implementing LAN Discovery with UDP Broadcast.” You will learn how to use a different networking protocol (UDP) to allow senders and receivers on the same network to find each other automatically, removing the need for users to manually type in IP addresses.