Create a new module for the sender logic (sender.rs).

Create a new module for the sender logic (`sender.rs`).

Mục tiêu:

With your serialization protocol defined and verified, you now have a robust way to package file metadata. The theoretical groundwork is complete, and it’s time to transition into the practical world of networking. We’ll begin by building the “sender” side of our application.

To keep our project clean, scalable, and easy to understand, we will not put all our code into main.rs. Instead, we will separate the distinct responsibilities of our application into their own dedicated modules. This task is focused on creating a new module specifically for all the logic related to the sender.

The Power of Modularity in Rust

As applications grow, keeping all the code in a single file becomes unwieldy. The Rust module system is a powerful feature designed to help you organize your code into a logical hierarchy, promoting reusability and maintainability.

Think of modules as separate rooms in a house. The main.rs file is like the entrance hall—it’s the entry point and directs traffic. The sender logic, however, is a specialized workshop that should have its own room. By creating a sender module, we are achieving a clear separation of concerns. Anyone working on the project will know that if they need to understand or modify how files are sent, the code they’re looking for will be in sender.rs.

In Rust, when you have a file src/main.rs, declaring mod sender; inside it tells the compiler to look for a file named src/sender.rs and include its contents as a module named sender.

Step 1: Create the `sender.rs` File

First, navigate to the src directory inside your project folder. Create a new, empty file and name it sender.rs.

Your project structure should now look like this:

p2p_file_sharer/
├── src/
│   ├── main.rs
│   └── sender.rs  <-- NEW FILE
└── Cargo.toml

This file will be the home for all the functions and logic related to the sender’s role.

Step 2: Declare the Module in `main.rs`

Now that the file exists, you need to tell your project’s crate root (main.rs) that this module is part of the compilation.

Open your src/main.rs file and add the module declaration near the top, right after your use statements.

// src/main.rs

use clap::{Parser, Subcommand};
use serde::{Serialize, Deserialize};
use std::path::PathBuf;

// HIGHLIGHT START
// This line declares a new module named `sender`.
// The Rust compiler will look for a file named `sender.rs` in the `src`
// directory and include its contents here.
mod sender;
// HIGHLIGHT END

#[derive(Serialize, Deserialize, PartialEq, Debug)]
pub struct FileMetadata {
    // ... struct definition remains the same
    pub filename: String,
    pub size: u64,
}

// ... rest of the main.rs file remains the same

By adding mod sender;, you’ve officially integrated the new file into your project. The compiler is now aware of it, and we can start adding code to it. Right now, your project will compile, but the new module doesn’t do anything yet.

Creating this module is the foundational step for building out the sender’s networking capabilities. In the next task, we will populate the sender.rs file with the primary start_sender function and begin writing the code to listen for incoming network connections.

Define the Sender Entry Point Function in Rust

Mục tiêu: Create the public start\_sender function in the sender.rs module. This function will act as the primary entry point for the file sending logic, accepting a file path as an argument and containing placeholder logic to verify the path.

Excellent work creating the sender.rs module! You’ve successfully established a dedicated, organized space for our sender logic, adhering to best practices for structuring a growing Rust application. The sender.rs file is currently empty, so our next step is to populate it with its primary entry point: the start_sender function.

Defining the Sender’s Entry Point

Every module that performs a specific action needs a clear entry point. For our sender, this will be a public function that we can call from main.rs whenever a user invokes the send subcommand. This function will eventually contain all the logic for setting up a network listener, sending metadata, and streaming the file content.

For this task, we will define the function’s signature—its name, its arguments, and its return type—and add some placeholder logic to confirm it works. We’ll place this new function inside the src/sender.rs file you just created.

Open the currently empty src/sender.rs file and add the following code:

// src/sender.rs

// We need to bring the `Path` type into scope from the standard library's `path` module.
use std::path::Path;

/// The main public function for the sender's logic.
/// This function will orchestrate the entire process of sending a file to a receiver.
/// It is marked as `pub` (public) so that it can be called from outside this module,
/// specifically from our `main` function in `main.rs`.
///
/// # Arguments
/// * `file_path`: A reference to a `Path` object representing the file to be sent.
pub fn start_sender(file_path: &Path) {
    // For now, let's add a simple check and a print statement. This acts as a placeholder
    // and allows us to verify that our `main` function is correctly calling this
    // function with the path provided by the user.
    if file_path.is_file() {
        println!("-> Sender logic initiated for file: {:?}", file_path);
        // In the next tasks, we will add the networking code here.
    } else {
        // It's crucial to handle cases where the input might not be what we expect.
        // If the provided path doesn't point to a file, we should inform the user.
        // `eprintln!` prints to the standard error stream, which is the correct
        // place for error messages.
        eprintln!("Error: The path {:?} is not a valid file.", file_path);
    }
}

Deconstructing the `start_sender` Function

Let’s analyze this code in detail to understand the important Rust concepts at play.

Visibility: The `pub` Keyword

The pub fn start_sender(...) declaration starts with the pub keyword. In Rust, all items (functions, structs, modules, etc.) are private by default. This means they can only be accessed by code within the same module. Since our goal is to call start_sender from main.rs (which is a different module), we must explicitly mark it as pub (public) to make it visible and accessible from outside the sender module. This is a core part of Rust’s encapsulation and module system.

The Function Argument: `file_path: &Path`

This is a very important and idiomatic aspect of Rust. Let’s break down why we chose &Path as the type for our argument:

Path vs. PathBuf: In Rust’s standard library, there are two main types for handling file paths.
- PathBuf: An owned, heap-allocated, and growable path. Think of it as the path equivalent of a String. The clap parser gives us a PathBuf because it needs to own the data it parses from the command line.
- Path: An unsized type that represents a borrowed “path slice”. Think of it as the path equivalent of &str. You almost always see it used in its borrowed form: &Path.
Why &Path is Better for Function Arguments: By accepting a &Path, our start_sender function becomes more flexible and efficient. It can accept a reference to a PathBuf, a String, a &str, or anything else that can be viewed as a path slice. This is possible due to a Rust feature called deref coercion. When we pass our PathBuf from main.rs to this function, Rust automatically converts &PathBuf into &Path. This avoids unnecessary memory allocations and makes our function’s API more general and reusable. It’s a best practice to prefer borrowed types (&str, &[T], &Path) for function arguments when you only need to read the data.

Placeholder Logic

Inside the function, we use file_path.is_file() to check if the path actually points to a file on the filesystem. This is a simple but practical validation step. For now, we print a confirmation message to standard output (println!) on success or an error message to standard error (eprintln!) on failure. This allows us to test our integration in a later step without having to implement the full networking logic first.

With this function now defined in our sender module, we have a solid skeleton to build upon. The next task will be to start filling in this skeleton by adding the core networking code that listens for an incoming connection from a receiver.

Create a TCP Listener in Rust

Mục tiêu: Modify the start\_sender function to use std::net::TcpListener to bind to address 0.0.0.0:8080, enabling the application to listen for incoming network connections.

You’ve successfully created the start_sender function, which acts as the perfect entry point for our sender’s logic. Now, it’s time to move beyond simple file checks and open our application to the network. We will replace the placeholder println! with the code that establishes a listening point, preparing our sender to receive a connection from a peer.

Opening the Door: Listening for Connections with `TcpListener`

In our P2P model, the “sender” temporarily acts as a server. Its primary job is to wait patiently for a “receiver” (acting as a client) to initiate a connection. The tool for this job in Rust’s standard library is std::net::TcpListener.

A TcpListener is a type of socket that is bound to a specific network address (an IP address and a port). “Binding” is the process of telling your computer’s operating system: “Hey, I want my program to be the one that handles any incoming TCP traffic destined for this specific IP and port combination.” Once bound, the listener can start accepting incoming connections.

For our application, we will bind to the address 0.0.0.0:8080. Let’s break down what this special address means:

0.0.0.0 (The Unspecified Address): This is a special IP address that tells the listener to accept connections on any network interface available on the machine. This is crucial for our P2P application. If we used 127.0.0.1 (localhost), we could only accept connections from our own computer. By using 0.0.0.0, our application can accept connections from other computers on the same Local Area Network (LAN), which is exactly what we want.
:8080 (The Port): A port is like an apartment number on a building’s address. While the IP address gets traffic to the right computer, the port number ensures it gets to the right application on that computer. 8080 is a common, high-numbered port often used for development, and it’s a perfectly good choice for our application. (Ports 0-1023 are generally reserved for well-known system services).

Let’s modify our sender.rs file to create and bind this listener.

// src/sender.rs

// We need to bring the `TcpListener` type into scope from the standard library's `net` module.
use std::net::TcpListener;
use std::path::Path;

/// The main public function for the sender's logic.
pub fn start_sender(file_path: &Path) {
    if file_path.is_file() {
        // --- HIGHLIGHT START ---

        // Use `TcpListener::bind` to create a new listener socket.
        // This tells the OS that we want to listen for incoming TCP connections
        // on all available network interfaces at port 8080.
        // The `bind` function returns a `Result`, as this operation can fail
        // (e.g., if the port is already in use by another application).
        // We use `.expect()` to handle the error case for now. If `bind` returns
        // an `Err`, our program will panic and print the provided message.
        // This is a simple approach suitable for now; we'll implement more
        // graceful error handling in a later step.
        let listener = TcpListener::bind("0.0.0.0:8080")
            .expect("Failed to bind to address 0.0.0.0:8080");

        // We'll update the print statement to reflect that we're now listening.
        println!("-> Sender listening on 0.0.0.0:8080. Ready to send file: {:?}" , file_path);

        // --- HIGHLIGHT END ---
    } else {
        eprintln!("Error: The path {:?} is not a valid file.", file_path);
    }
}

Deconstructing the Code

use std::net::TcpListener;: We start by importing the necessary TcpListener struct from the standard library.
let listener = TcpListener::bind("0.0.0.0:8080").expect(...): This is the core of our new logic.
- TcpListener::bind(...) is the function that attempts to create the socket and bind it to the address.
- This operation can fail. For example, another program might already be using port 8080, or the user might not have the necessary permissions. Because of this, bind returns a Result<TcpListener, std::io::Error>.
- We use the .expect() method on the Result. This is a convenient way to handle errors during development. If the Result is Ok(listener), expect will return the listener instance. If the Result is Err(...), expect will cause the program to panic and display the error message we provided: “Failed to bind to address 0.0.0.0:8080”. This immediately alerts us to a problem with our network setup.

You have now successfully written the code to open a network listener. Your sender application is no longer an isolated program; it has a presence on the network, ready and waiting for a receiver. The next task is to use the listener object we just created to actually accept an incoming connection, which will give us the TcpStream we need to start transferring data.

Provide User Feedback for a Rust TCP Sender

Mục tiêu: Refine the sender’s console output to inform the user that the application is successfully listening on a network address and is waiting for a receiver to connect. Improve the message by displaying just the filename instead of the full path for a cleaner user experience.

Excellent! You’ve successfully written the code to bind a TcpListener to a network address, giving your sender application its presence on the local network. This is a huge step. However, a silent program can be confusing for a user. They might wonder if it’s working, listening, or has already crashed. Our current task is to provide clear, essential feedback to the user, letting them know that the sender is up and running and is now waiting for the receiver to connect.

Providing User Feedback: The Importance of Status Messages

In command-line applications, clear communication is key to a good user experience. When a user runs your send command, they expect the application to enter a specific state—in this case, a “waiting” state. Our job is to reflect that state back to the user with a concise and informative message.

This message serves two purposes:

Confirmation: It confirms that the program started successfully, the file path was valid, and the network listener was bound without errors.
Instruction: It implicitly tells the user what to do next. Seeing a “Waiting for a connection…” message prompts them to go to another machine and run the receive command.

We’ll refine the println! statement you added in the previous task to be more explicit about this waiting state. We’ll also improve it to show just the filename instead of the entire path, which is cleaner and more user-friendly.

Let’s modify the start_sender function in src/sender.rs.

// src/sender.rs

use std::net::TcpListener;
use std::path::Path;

pub fn start_sender(file_path: &Path) {
    if file_path.is_file() {
        let listener = TcpListener::bind("0.0.0.0:8080")
            .expect("Failed to bind to address 0.0.0.0:8080");

        // --- HIGHLIGHT START ---
        // We are refining the message to be more explicit about the current state.
        // This message clearly tells the user that the program is running correctly,
        // is listening on a specific address, and is now waiting for the receiver
        // to connect. This is crucial user feedback for a command-line tool.
        // We're also using `file_path.file_name()` for a cleaner output.
        println!(
            "Listening on 0.0.0.0:8080. Waiting for a connection to send {:?}...",
            // `file_name()` returns an `Option<&OsStr>`, so we handle the `None` case
            // by falling back to the original path. This makes our code more robust.
            file_path.file_name().unwrap_or_else(|| file_path.as_os_str())
        );
        // --- HIGHLIGHT END ---
    } else {
        eprintln!("Error: The path {:?} is not a valid file.", file_path);
    }
}

Deconstructing the Refined Message

Let’s break down the updated println! macro, as it introduces a new, useful pattern.

println!(...): This is the standard Rust macro for printing a formatted string to the console’s standard output (stdout), followed by a newline. It’s the primary tool for communicating status and results to the user in a CLI application.
file_path.file_name(): Instead of printing the full path (e.g., /home/user/documents/my_file.txt), this method from the Path type attempts to extract just the final component (my_file.txt). This is much cleaner and more relevant to the user.
Handling Option with unwrap_or_else: The file_name() method is smart; it knows that not all paths have a filename (for example, / or ../). Because of this, it doesn’t return a filename directly. Instead, it returns an Option<&OsStr>.
- If a filename is present, it returns Some(filename).
- If no filename can be found, it returns None.
To handle this safely without crashing, we use the unwrap_or_else method. This method takes a closure (the || file_path.as_os_str() part) as an argument. * If the Option is Some(value), it “unwraps” it and returns the value. * If the Option is None, it executes the closure and returns its result. In our case, the closure || file_path.as_os_str() provides a safe fallback, returning the original path as an OsStr (a string type for interacting with the operating system). This makes our code robust against unusual inputs.

Our program now provides excellent feedback. However, there’s a subtle but important detail: after printing this message, our start_sender function finishes, and the program exits! The listener is created and then immediately dropped.

The application is telling the user it’s waiting, but it isn’t actually waiting yet. The next task is to fix this by introducing the listener.accept() method. This is the function that will actually pause, or block, the program’s execution until a receiver establishes a connection.

Accept an Incoming TCP Connection

Mục tiêu: Implement a blocking call to listener.accept() in the TCP sender to pause execution until a client connects, establishing a TcpStream for future communication.

Brilliant! You’ve successfully set up the TcpListener and provided a clear, informative message to the user, letting them know the sender is ready. However, as you may have noticed, after printing the “Waiting for a connection…” message, the program immediately exits. The listener is created and then instantly destroyed as the start_sender function reaches its end.

Our current task is to make the program actually wait. We need to introduce a mechanism that pauses, or blocks, the program’s execution until a receiver makes contact. This is the very essence of a listening server.

Accepting the Connection: The `listener.accept()` Call

The TcpListener you created has a crucial method called accept(). This is the function that brings your listener to life. When you call listener.accept(), you are telling your program: “Pause everything on this thread right here. Do not proceed until a client successfully connects to the IP and port I’m listening on.”

This is what’s known as a blocking operation. The program’s execution is blocked, waiting for an external event (an incoming network connection). This is a fundamental concept in many forms of I/O (Input/Output) programming.

Once a receiver connects, the accept() method wakes up and completes its job. It returns two vital pieces of information packaged together in a tuple:

TcpStream: This is the prize. A TcpStream is a new socket that represents the dedicated, two-way communication channel between your sender and the specific receiver that just connected. It’s the pipe through which you will send the file metadata and the file’s content. You can both write to it and read from it.
SocketAddr: This contains the IP address and port number of the client that just connected. It’s incredibly useful for logging and debugging, as it allows you to see exactly who you’re talking to.

Let’s add this blocking call to your start_sender function in src/sender.rs.

// src/sender.rs

// No new imports are needed for this step.
use std::net::TcpListener;
use std::path::Path;

pub fn start_sender(file_path: &Path) {
    if file_path.is_file() {
        let listener = TcpListener::bind("0.0.0.0:8080")
            .expect("Failed to bind to address 0.0.0.0:8080");

        println!(
            "Listening on 0.0.0.0:8080. Waiting for a connection to send {:?}...",
            file_path.file_name().unwrap_or_else(|| file_path.as_os_str())
        );

        // --- HIGHLIGHT START ---

        // `listener.accept()` is a blocking method. It will wait here until a
        // client connects. When a connection is established, it returns a new
        // `TcpStream` for communication and the address of the connecting peer.
        // Like `bind`, `accept` can also fail, so it returns a `Result`.
        // We use `.expect()` for simple error handling for now.
        // We use `let (mut stream, addr)` to destructure the returned tuple.
        // `stream` is marked as `mut` because we will need to write data to it later.
        let (mut stream, addr) = listener.accept()
            .expect("Failed to accept connection");

        // Once `accept` returns, it means a client has connected.
        // We can now provide feedback to the user that the connection was successful.
        println!("-> Connection established with peer: {}", addr);

        // --- HIGHLIGHT END ---

    } else {
        eprintln!("Error: The path {:?} is not a valid file.", file_path);
    }
}

Deconstructing the New Logic

Let’s analyze the highlighted code in detail:

let (mut stream, addr) = ...: This is a destructuring assignment. The accept() method returns a tuple (TcpStream, SocketAddr). This syntax allows us to neatly unpack the tuple and assign its contents to two separate variables, stream and addr, in a single line.
mut stream: We declare the stream variable as mutable using the mut keyword. This is important because a TcpStream is the channel we will write data to. Writing is a mutable operation that changes the state of the stream, so Rust requires us to be explicit about our intent to modify it.
listener.accept().expect(...):
- listener.accept(): This is the blocking call we discussed. Your program will pause on this line.
- .expect("Failed to accept connection"): Just like bind, the accept operation can fail (for various network-related reasons). It returns a Result to represent this possibility. For now, we continue to use .expect(), which will crash the program with a helpful message if an error occurs.
println!("-> Connection established with peer: {}", addr);: This is our new feedback mechanism. As soon as accept() returns successfully, we print a message confirming the connection and displaying the receiver’s address, which we got from the addr variable. This is great for the user, as they now know the file transfer is about to begin.

You have now implemented one of the most critical pieces of the sender’s logic. Your application can now properly listen, wait for a connection, and establish a communication channel. The foundation is set.

The next logical step is to use the stream object we’ve just acquired. With this open channel to the receiver, we can finally send the first piece of our protocol: the serialized FileMetadata.

Get the filename and size of the file to be sent.

Mục tiêu:

With a live connection to a receiver established, your sender application is on the verge of its primary mission: transferring a file. You have the TcpStream—the open channel—ready and waiting. But before you can send the file’s content, you must first send the “table of contents,” our FileMetadata, so the receiver knows what to expect.

This task is all about gathering that metadata from the local filesystem. Specifically, we need to determine two crucial pieces of information from the file_path provided by the user: its name and its total size in bytes.

Obtaining File Information from the Filesystem

Rust’s extensive standard library provides robust and platform-agnostic tools for interacting with the filesystem. We’ll use two of these tools now: one to get the file’s size and another to extract its name.

1. Finding the File Size

To get information about a file, such as its size, creation time, or permissions, we can use the std::fs::metadata function. This function takes a path and queries the operating system for its metadata.

This operation can, of course, fail. The file might have been deleted between the time we checked for its existence and now (a classic race condition), or our program might not have the necessary permissions to read its metadata. For this reason, fs::metadata returns a Result. If successful, it gives us a Metadata struct; otherwise, it returns an io::Error. We’ll continue our current strategy of using .expect() to handle any errors for now, which will halt the program with a clear message if something goes wrong.

Once we have the Metadata struct, we can simply call its .len() method, which conveniently returns the file size in bytes as a u64, the exact type we need for our FileMetadata struct.

2. Extracting a Clean Filename

We also need the filename. While we used file_path.file_name() in the previous step for our println! message, we now need to capture it in a String variable to eventually place it in our FileMetadata struct.

The file_name() method returns an Option<&OsStr>. Let’s break this down: * Option: It’s an Option because not all paths have a filename (e.g., / or C:\\). Our earlier is_file() check makes this highly unlikely, but it’s good practice to handle it. * &OsStr: This stands for “OS String slice.” This is not a standard &str. Why? Because different operating systems have different rules for valid filenames. While many filenames are simple UTF-8 text, some filesystems (like on Linux) allow filenames with byte sequences that are not valid UTF-8. OsStr is a special string type that can handle these platform-specific quirks.

However, our FileMetadata struct requires a standard Rust String, which must be valid UTF-8. Therefore, we must perform a conversion. We can convert an &OsStr to a &str using the .to_str() method. This method also returns an Option, because the conversion will fail if the filename contains non-UTF-8 characters.

So, the full, robust process is: file_path -> file_name() (gets Option<&OsStr>) -> to_str() (gets Option<&str>) -> to_string() (converts &str to String).

Let’s add this logic to our start_sender function in src/sender.rs.

// src/sender.rs

// Import the `fs` module to access filesystem operations.
use std::fs;
use std::net::TcpListener;
use std::path::Path;

pub fn start_sender(file_path: &Path) {
    if file_path.is_file() {
        let listener = TcpListener::bind("0.0.0.0:8080")
            .expect("Failed to bind to address 0.0.0.0:8080");

        println!(
            "Listening on 0.0.0.0:8080. Waiting for a connection to send {:?}...",
            file_path.file_name().unwrap_or_else(|| file_path.as_os_str())
        );

        let (mut stream, addr) = listener.accept()
            .expect("Failed to accept connection");

        println!("-> Connection established with peer: {}", addr);

        // --- HIGHLIGHT START ---

        // 1. Get the filename.
        // We extract the filename from the path, convert it from an OsStr to a &str,
        // and finally own it as a String. We use `expect` to handle the rare cases
        // where the filename is not valid UTF-8 or doesn't exist.
        let filename = file_path
            .file_name()
            .expect("Could not get file name from path")
            .to_str()
            .expect("Filename is not valid UTF-8")
            .to_string();

        // 2. Get the file size.
        // `fs::metadata` queries the filesystem for metadata about the file.
        // This can fail (e.g., permissions), so it returns a Result.
        let file_metadata = fs::metadata(file_path)
            .expect("Could not read file metadata");
        let file_size = file_metadata.len(); // .len() gives the size in bytes.

        // Print the gathered information for verification. This is a good debugging step.
        println!("-> Preparing to send file: '{}' ({} bytes)", filename, file_size);

        // --- HIGHLIGHT END ---

    } else {
        eprintln!("Error: The path {:?} is not a valid file.", file_path);
    }
}

You have now successfully gathered all the necessary information about the file you intend to send. You’ve read its metadata from the filesystem and prepared its name and size in variables, ready for the next step.

With the filename and file_size now in hand, you are perfectly positioned for the next task: to create an instance of your FileMetadata struct, packaging this information into a single, serializable object.

Create an instance of the `FileMetadata` struct from the previous step.

Mục tiêu:

You’ve done an excellent job gathering the raw data from the filesystem! You now have the file’s name stored in a String and its size in a u64. These are the two essential ingredients for our metadata package. Now, it’s time to assemble them into the clean, structured format we designed earlier: an instance of our FileMetadata struct.

Assembling the Metadata Package: From Variables to a Struct

Think back to the “Defining the Communication Protocol” step. We created the FileMetadata struct to act as a blueprint. It’s a formal declaration of what file metadata is in our application’s world: a combination of a filename and a size.

The process of creating a concrete value from a struct’s blueprint is called instantiation. We are about to take our two separate variables and use them to construct a single, meaningful metadata object. This object bundles the related data together, making it much easier to manage and, crucially, to pass to our serialization function in the next step.

First, to make our code cleaner, let’s bring the FileMetadata struct into the scope of our sender module. This allows us to refer to it as FileMetadata directly, instead of the more verbose crate::FileMetadata.

Add the following use statement to the top of src/sender.rs.

// src/sender.rs

// --- HIGHLIGHT START ---
// Bring our custom FileMetadata struct into the scope of this module.
// `crate` refers to the root of our own crate, where `main.rs` lives
// and where we defined `FileMetadata`.
use crate::FileMetadata;
// --- HIGHLIGHT END ---
use std::fs;
use std::net::TcpListener;
use std::path::Path;

Now, let’s create the instance within the start_sender function, right after we’ve gathered the filename and file_size.

// src/sender.rs

pub fn start_sender(file_path: &Path) {
    if file_path.is_file() {
        // ... (code for binding listener and accepting connection remains the same)
        let (mut stream, addr) = listener.accept().expect("Failed to accept connection");
        println!("-> Connection established with peer: {}", addr);

        let filename = file_path
            .file_name()
            .expect("Could not get file name from path")
            .to_str()
            .expect("Filename is not valid UTF-8")
            .to_string();

        let file_metadata = fs::metadata(file_path).expect("Could not read file metadata");
        let file_size = file_metadata.len();

        println!("-> Preparing to send file: '{}' ({} bytes)", filename, file_size);

        // --- HIGHLIGHT START ---

        // Now, we create an instance of our `FileMetadata` struct.
        // We populate its fields with the variables we just created.
        let metadata = FileMetadata {
            // This is a Rust feature called "field init shorthand".
            // Since our variable `filename` has the same name as the struct field,
            // we can just write `filename` instead of `filename: filename`.
            filename,
            // Here, the variable name `file_size` is different from the struct field `size`,
            // so we must specify the mapping explicitly.
            size: file_size,
        };

        // For now, we'll just print this struct using its `Debug` representation
        // to confirm it has been created correctly.
        println!("-> Created metadata package: {:?}", metadata);

        // --- HIGHLIGHT END ---

    } else {
        eprintln!("Error: The path {:?} is not a valid file.", file_path);
    }
}

Deconstructing the Instantiation

Let’s look closely at this new block of code, as it showcases some elegant and idiomatic Rust features.

use crate::FileMetadata;: This line is crucial for good module organization. The crate keyword represents a path starting from the root of our project’s source code (src/main.rs for a binary crate). By adding this line, we make FileMetadata a known type within sender.rs, which is much cleaner than referring to it by its full path (crate::FileMetadata) every time.
let metadata = FileMetadata { ... };: This is the core struct literal syntax used for instantiation. We state the type we want to create (FileMetadata) followed by curly braces {} containing the values for its fields.
filename,: This is the field init shorthand. It’s a convenient piece of syntactic sugar provided by Rust. The compiler sees that we’re initializing a struct with a field named filename and that there is a variable in the current scope also named filename. It understands that our intent is to assign the variable’s value to the field, so we can omit the repetitive filename: filename. This makes the code more concise and readable.
size: file_size,: This is the standard, explicit way of initializing a field. Because our variable is named file_size but the struct’s field is named size, we must be explicit: field_name: variable_name. This demonstrates why the shorthand is so useful—it only works when the names match exactly.

You now have a single, self-contained metadata variable that neatly packages all the necessary information. This is a significant milestone. You’ve successfully transitioned from raw, separate pieces of data to a structured, meaningful object that perfectly represents the protocol you designed.

With this metadata instance in hand, you are fully prepared for the next critical task: to serialize this struct into a stream of bytes using bincode and write those bytes to the TcpStream, officially sending the first piece of data to the receiver.

Serialize and Send File Metadata over a Network Stream

Mục tiêu: Implement the network logic to send file metadata. This involves serializing a FileMetadata struct using bincode and then writing the resulting bytes to a TcpStream with the write\_all method from the std::io::Write trait.

You have perfectly prepared the FileMetadata instance, bundling the file’s name and size into a single, structured object. This is the “shipping label” for our data package. Now, it’s time to stick that label on the box and send it down the wire. This task is where we perform the first actual network communication: serializing our metadata and writing it to the TcpStream we established with the receiver.

From In-Memory Struct to Network Bytes

This process involves two distinct but sequential steps, which you’ve already practiced in your unit test:

Serialization: We’ll use bincode::serialize to convert our in-memory metadata struct into a Vec<u8>. This transforms our structured data into a flat, universal sequence of bytes that the network can understand.
Writing to the Stream: We’ll take this vector of bytes and write it into the TcpStream. The operating system’s networking stack will then take over, packaging these bytes into TCP packets and ensuring they are reliably delivered to the receiver.

To perform the second step, we need a new tool from Rust’s standard library: the std::io::Write trait.

The `std::io::Write` Trait

In Rust, a trait is a collection of methods that defines a shared behavior. The Write trait defines the behavior of being a “sink” for bytes. Anything that implements Write has a standard way of receiving byte data. This is a powerful abstraction because it means we can use the same code to write to a file on disk (std::fs::File), to an in-memory buffer, or, in our case, to a network connection (std::net::TcpStream).

The TcpStream implements the Write trait, which gives us access to several useful methods, most notably write_all(). We choose write_all() over the lower-level write() because it guarantees that it will continue writing until the entire buffer you provide has been sent. This simplifies our code tremendously, as we don’t have to write a loop to handle cases where the network can only accept a partial chunk of our data at once.

Let’s update our sender.rs file to include this logic.

First, we need to bring the Write trait into scope. Add this to your use statements at the top of src/sender.rs.

// src/sender.rs

use crate::FileMetadata;
use std::fs;
// HIGHLIGHT START
// Import the `Write` trait from the `std::io` module.
// This trait provides the `.write_all()` method for our TcpStream.
use std::io::Write;
// HIGHLIGHT END
use std::net::TcpListener;
use std::path::Path;

Now, let’s add the core logic to the start_sender function, right after creating the metadata instance.

// src/sender.rs

// ... (keep the start_sender function signature and the code before this point)
pub fn start_sender(file_path: &Path) {
    if file_path.is_file() {
        // ... (binding, listening, accepting, and getting file info remains the same)

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

        // We can now remove the previous debug print for the metadata struct.

        // --- HIGHLIGHT START ---

        // Step 1: Serialize the metadata struct.
        // `bincode::serialize` takes our struct and returns a `Result` containing a `Vec<u8>`.
        // We `.expect()` to handle any potential (though unlikely) serialization errors.
        let serialized_metadata = bincode::serialize(&metadata)
            .expect("Failed to serialize metadata");

        println!("-> Sending metadata ({} bytes)...", serialized_metadata.len());

        // Step 2: Write the serialized bytes to the stream.
        // The `write_all` method takes a byte slice (`&[u8]`) and ensures every single
        // byte is sent. This operation can also fail (e.g., if the receiver disconnects
        // abruptly), so it returns a `Result` which we handle with `.expect()`.
        stream.write_all(&serialized_metadata)
            .expect("Failed to write metadata to the stream");

        println!("-> Metadata sent successfully.");

        // --- HIGHLIGHT END ---

    } else {
        eprintln!("Error: The path {:?} is not a valid file.", file_path);
    }
}

Deconstructing the Network Code

Let’s review the new code block in detail:

let serialized_metadata = bincode::serialize(&metadata)...: This is the exact same logic from our unit test, now applied in our real application code. We take our metadata struct and convert it into a Vec<u8>. The println! that follows is a great debugging and user-feedback tool, confirming how many bytes of metadata are being sent.
stream.write_all(&serialized_metadata)...: This is the critical network operation.
- stream: This is our TcpStream variable, which we made mutable (mut) when we received it from listener.accept().
- .write_all(): This is the method provided by the Write trait.
- &serialized_metadata: We pass a reference to our byte vector. The write_all method expects a byte slice (&[u8]), and Rust can automatically convert a &Vec<u8> into a &[u8] (a process called deref coercion).
- .expect(...): Network operations are inherently fallible. The connection could drop at any moment. write_all returns a Result<(), std::io::Error> to reflect this. For now, we use .expect() to crash the program with a clear error message if the write fails.

You have now officially sent data over the network! This is the first half of our custom protocol. The receiver, once implemented, will perform the inverse of this operation: it will read these exact bytes from its own TcpStream and use bincode::deserialize to reconstruct the FileMetadata object.

With the metadata successfully sent, the receiver now knows what’s coming. The stage is set for the main event: sending the actual file content. Your next task will be to open the file for reading and prepare to send it, chunk by chunk.

Open a File for Reading in Rust

Mục tiêu: Learn how to open a local file for reading in Rust using std::fs::File::open(). This task covers handling the Result type, the importance of mutability (mut) for file handles, and preparing to send file contents over a network.

You’ve brilliantly executed the first part of our custom network protocol! The FileMetadata has been serialized and sent across the TcpStream. The receiver is now fully informed about the file it’s about to receive. With the “shipping label” sent, it’s time to prepare the actual package: the file’s content.

Our next task is to open the file from the local disk and get a handle to it, allowing our program to read its raw byte content.

Gaining Access to File Content with `std::fs::File`

The file we want to send currently resides on the sender’s disk. To read its contents into our application so we can send them over the network, we need to ask the operating system for a “file handle.” In Rust, the primary type for representing an open file is std::fs::File.

We will use the std::fs::File::open() function. This function takes a path to a file and attempts to open it. By default, it opens the file in read-only mode, which is a perfect example of the principle of least privilege. Our sender’s job is only to read the file, not to modify it, so we should only request reading permissions. This makes our program safer and more predictable.

Like the other I/O operations we’ve performed (TcpListener::bind, fs::metadata), File::open() can fail for various reasons (the file might have been deleted, or we might lack the necessary permissions). Therefore, it doesn’t return a File directly. Instead, it returns a Result<File, std::io::Error>, forcing us to handle the potential for failure. We will continue our current strategy of using .expect() to provide a clear error message and halt the program if the file cannot be opened.

Let’s modify our sender.rs file to open the file.

First, let’s bring the File type into scope at the top of src/sender.rs for cleaner code.

// src/sender.rs

use crate::FileMetadata;
// HIGHLIGHT START
// Import the `File` type from the `std::fs` module.
use std::fs::{self, File};
// HIGHLIGHT END
use std::io::Write;
use std::net::TcpListener;
use std::path::Path;

Now, let’s add the code to open the file inside the start_sender function, right after we’ve sent the metadata.

// src/sender.rs

pub fn start_sender(file_path: &Path) {
    if file_path.is_file() {
        // ... (All the code for listening, connecting, and sending metadata remains the same)

        stream.write_all(&serialized_metadata)
            .expect("Failed to write metadata to the stream");

        println!("-> Metadata sent successfully.");

        // --- HIGHLIGHT START ---

        // Now, we open the file for reading.
        // `File::open` returns a `Result`, so we use `.expect()` to handle errors.
        // The `file` variable must be mutable (`mut`) because reading from a file
        // advances an internal cursor, which is a change in the file handle's state.
        // Rust requires us to be explicit about this mutation.
        let mut file = File::open(file_path)
            .expect("Failed to open file for reading");

        println!("-> Opened file {:?} for reading.", file_path.file_name().unwrap_or_default());

        // --- HIGHLIGHT END ---

    } else {
        eprintln!("Error: The path {:?} is not a valid file.", file_path);
    }
}

Deconstructing the Code: Mutability and State

Let’s look closely at the new code, particularly the mut keyword.

use std::fs::{self, File};: We’ve updated our use statement. Instead of just importing the fs module, we are now also specifically importing the File type from within it. This lets us write File::open instead of fs::File::open and let mut file: File instead of let mut file: fs::File. It’s a small change that improves readability.
let mut file = File::open(...): This is the core of this task.
- File::open(file_path): We call the function, passing the same file_path that the user provided to our application.
- .expect("Failed to open file for reading"): We handle the Result as before. If the file can’t be opened, our program will stop with this specific, helpful message.
- mut file: This is a subtle but fundamentally important concept in Rust. Why does file need to be mutable? We are only reading from it, not writing to it. The reason is that an open file handle maintains internal state, specifically its current position or “cursor.” When you read a chunk of data, the operating system advances this cursor so that the next read will start where the last one left off. Because the act of reading changes the internal state of the File object, Rust considers it a mutating operation and requires us to explicitly mark the variable as mut. This explicitness is a key feature of Rust’s safety and clarity.

You have now successfully opened the file for reading and hold a handle to it in the file variable. This File object, just like TcpStream, implements another crucial I/O trait: std::io::Read. This means it acts as a source of bytes.

With the file handle open (our source of bytes) and the stream available (our destination for bytes), all the pieces are in place. The next task is to create a buffer to act as a temporary holding area and then, in a loop, read bytes from the file into the buffer and write the buffer’s contents to the stream, completing the core of the file transfer.

Create a Stack-Allocated Buffer in Rust for File I/O

Mục tiêu: Create a mutable, fixed-size byte array on the stack to serve as a buffer. This buffer will be used to read a file in manageable chunks for efficient network transfer, avoiding high memory consumption.

You have successfully opened the file on disk, which gives you a readable “source” of bytes (File). You also have a writable “destination” for those bytes in the form of the TcpStream. The final piece of the puzzle before we can start moving data is to create a temporary holding area—a buffer—to carry the data in chunks from the source to the destination.

The Role of Buffering in Efficient I/O

When transferring a file, especially one that could be very large (gigabytes or more), it’s highly impractical and inefficient to read the entire file into your computer’s memory (RAM) at once. Doing so would consume a huge amount of memory and could cause the system to slow down or even crash.

Instead, the standard and most efficient approach is to process the file in manageable chunks. We read a small chunk from the file, send that chunk over the network, then read the next chunk, send it, and so on, until the entire file has been transferred. This process is known as buffered I/O. The buffer is the small, fixed-size piece of memory that we use to hold each chunk.

For this task, we will create a buffer as a simple byte array on the stack.

Creating a Stack-Allocated Byte Array

In Rust, a fixed-size array is a collection of objects of the same type stored in contiguous memory. For a byte buffer, the perfect type is [u8; N], where u8 is the standard 8-bit unsigned integer type (a single byte), and N is the size of the array.

A key advantage of using a fixed-size array like this is that it is typically allocated on the stack. Stack allocation is extremely fast because it just involves moving a “stack pointer” by a fixed amount. For small, fixed-size data that only needs to exist for the duration of a function call, the stack is the ideal place for it.

We’ll choose a buffer size of 8192 bytes (or 8 KiB). This is a common and effective size for I/O buffers. It’s large enough to minimize the number of system calls (which have some overhead) but small enough to fit comfortably in modern CPU caches and not waste memory.

Let’s add the code to create this buffer in your start_sender function.

// src/sender.rs

// ... (your existing use statements)
use std::fs::{self, File};
use std::io::Write;
// New! We need the `Read` trait for the next steps. It's good practice to add it now.
use std::io::Read;
use std::net::TcpListener;
use std::path::Path;

pub fn start_sender(file_path: &Path) {
    if file_path.is_file() {
        // ... (All the code for listening, connecting, and sending metadata remains the same)

        let mut file = File::open(file_path)
            .expect("Failed to open file for reading");

        println!("-> Opened file {:?} for reading.", file_path.file_name().unwrap_or_default());

        // --- HIGHLIGHT START ---

        // Create a buffer to hold chunks of the file data.
        // This is a fixed-size array of 8192 bytes (8 KiB) allocated on the stack.
        // The array is initialized with all zeros.
        // It must be `mut` because the `file.read()` operation in the next step
        // will write data into it, changing its contents.
        let mut buffer = [0u8; 8192];

        println!("-> Created an 8 KiB buffer for file transfer.");

        // --- HIGHLIGHT END ---

    } else {
        eprintln!("Error: The path {:?} is not a valid file.", file_path);
    }
}

Deconstructing the Code

Let’s break down the new line and its context:

use std::io::Read;: We’ve preemptively added the Read trait to our imports. While not strictly needed for creating the buffer, it will be essential for the very next task, which is to read from the file into our new buffer. The Read trait provides the .read() method, much like the Write trait provides .write_all().
let mut buffer = [0u8; 8192];: This is the core of our task.
- let mut buffer: We declare a mutable variable named buffer. It must be mutable because we intend to fill it with data from the file. The read operation is a mutating one, as it changes the contents of the buffer.
- [0u8; 8192]: This is Rust’s concise syntax for creating an array. It means: “Create an array where the element is 0u8 (the byte value 0), and repeat that element 8192 times.” This creates our 8 KiB buffer and initializes all its bytes to zero, which is a safe default.

You have now successfully prepared all the necessary components for the file transfer. You have the source (file), the destination (stream), and the vehicle to carry the data between them (buffer).

The stage is now perfectly set for the grand finale of the sender’s logic: creating a loop that repeatedly fills the buffer from the file and writes the buffer’s contents to the network stream until the entire file is sent.

Implement a File Reading Loop in Rust

Mục tiêu: Create the core I/O loop to read a file in chunks into a buffer. Use the .read() method and a match statement to handle its Result return value, correctly managing successful reads, the end-of-file (EOF) condition, and I/O errors.

You have perfectly set up all the necessary components for the data transfer. You have your data source (file), your data destination (stream), and the vehicle to carry the data (buffer). Now it’s time to start the engine and begin the core process of the file transfer: reading the file’s content, chunk by chunk, in a loop.

Orchestrating the Transfer with an I/O Loop

The heart of any large data transfer is a loop. This loop’s responsibility is to repeatedly perform two actions: read a chunk of data from the source and write that chunk to the destination. In this task, we will focus solely on the first action: reading data from the File into our buffer.

To accomplish this, we will use the .read() method, which is provided by the std::io::Read trait that you imported in the previous task. The std::fs::File type implements this trait, making the method available to us.

Understanding the `.read()` Method’s Return Value

The .read() method is the workhorse of input operations in Rust. Its behavior, especially its return value, is critical to understand for writing correct and robust I/O code. The method attempts to read bytes from the source and fill the buffer you provide. It then returns a Result<usize>. Let’s break down the possible outcomes:

Ok(n) where n > 0: This is the most common success case. It means that n bytes were successfully read from the file and have been written into the beginning of your buffer. The value n might be less than your buffer’s total size, especially when you are nearing the end of the file.
Ok(0): This is not an error! It’s a special, important signal. It means that the end of the file has been reached (often called EOF). There is no more data to read. When we receive this signal, we know our work is done, and we can exit the loop.
Err(e): An I/O error occurred while trying to read from the file. This could happen for many reasons, such as a disk failure or the file being unreadable.

To handle these distinct outcomes gracefully, a match statement is the perfect tool. It allows us to write separate logic for each case, making our code clear and correct.

Let’s implement this I/O loop in your start_sender function.

// src/sender.rs

// ... (your existing use statements)
use crate::FileMetadata;
use std::fs::{self, File};
use std::io::{Read, Write}; // Ensure `Read` is imported
use std::net::TcpListener;
use std::path::Path;

pub fn start_sender(file_path: &Path) {
    if file_path.is_file() {
        // ... (All code for listening, connecting, and sending metadata remains the same)

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

        println!("\n-> Starting file transfer...");

        // --- HIGHLIGHT START ---

        // This loop will continue until the entire file is read.
        loop {
            // The `file.read()` method attempts to fill the buffer with data from the file.
            // It returns a `Result` indicating how many bytes were read.
            let bytes_read = match file.read(&mut buffer) {
                // `Ok(0)` means we've reached the end of the file (EOF).
                // This is our signal to break out of the loop.
                Ok(0) => {
                    println!("-> Reached end of file.");
                    break;
                }
                // `Ok(n)` means `n` bytes were successfully read into the buffer.
                Ok(n) => {
                    println!("   - Read {} bytes from file.", n);
                    // For this task, we are only reading. In the next task,
                    // we will add the code here to write these `n` bytes
                    // to the `TcpStream`.
                    n // The number of bytes read is the result of this match arm.
                }
                // `Err` indicates an I/O error occurred during the read.
                // We'll panic for now, but this will be improved later with
                // more robust error handling.
                Err(ref e) if e.kind() == std::io::ErrorKind::Interrupted => continue,
                Err(e) => {
                    // Panic with a descriptive error message.
                    panic!("Error reading from file: {}", e);
                }
            };
            // The `bytes_read` variable now holds the number of bytes we just read.
            // We'll use this in the next task.
        }

        // --- HIGHLIGHT END ---

    } else {
        eprintln!("Error: The path {:?} is not a valid file.", file_path);
    }
}

Deconstructing the I/O Loop

Let’s examine the new block of code in detail.

loop { ... }: We use an infinite loop here. This is a common pattern for I/O because the exit condition (Ok(0)) is determined inside the loop’s body, not before it starts.
let bytes_read = match file.read(&mut buffer) { ... }: This is the core of the logic. We call file.read() and immediately pass its Result into a match statement to handle all possible outcomes.
&mut buffer: We pass a mutable reference to our buffer. This gives the read method the permission it needs to write the file’s data into our buffer’s memory.
Ok(0) => break;: This is our exit strategy. When read returns Ok(0), we know the file is fully read, so we print a confirmation message and use the break keyword to exit the loop.
Ok(n) => n: In the success case where n bytes are read, we print how many bytes we got. We then have this match arm evaluate to n, which gets stored in the bytes_read variable. This variable will be crucial in the next step.
Err(ref e) if e.kind() == std::io::ErrorKind::Interrupted => continue,: This is a subtle but important piece of robust I/O handling. Sometimes, a read operation can be interrupted by a system signal before any data is transferred. This is not a fatal error, and the correct action is to simply try the read again. This line catches that specific kind of error and uses continue to immediately start the next loop iteration.
Err(e) => panic!(...): This is our catch-all for any other I/O error. If something unexpected goes wrong, we panic, which will stop the program and display a detailed error message.

You have now successfully implemented the reading portion of the file transfer loop. If you were to run this code, you would see a series of “Read X bytes from file” messages printed to your console, followed by “Reached end of file.” You have proven that your application can correctly process a file in manageable chunks.

With the buffer being successfully filled in each loop iteration, the next and final step for the sender is to take those bytes and write them to the network stream, sending them on their way to the receiver.

Writing Buffered Data to a Stream with Slicing

Mục tiêu: Complete the file transfer I/O loop by writing the data from the buffer to the TCP stream. Use a slice of the buffer (&buffer[0..bytes\_read]) to ensure only the bytes actually read from the file are sent, preventing data corruption on the final chunk.

You’ve done an incredible job implementing the reading portion of the I/O loop! In each iteration, your code successfully reads a chunk of the file into the buffer and correctly identifies how many bytes were read. You are now holding a buffer that’s partially or fully filled with precious data, ready to be sent.

This is the moment where the two sides of our I/O operation meet. We will now take the data we just read from the file and write it to the stream, completing one full cycle of our transfer loop.

The Challenge of Incomplete Buffers and the Power of Slicing

A crucial detail we must handle is that on the final read from a file, the number of bytes read (bytes_read) will almost certainly be less than the total buffer size. For example, if our file is 10,000 bytes and our buffer is 8192 bytes, the sequence of reads will be:

Read 8192 bytes.
Read the remaining 1708 bytes.

In that second read, our 8192-byte buffer will contain 1708 bytes of actual file data, followed by 6484 bytes of leftover zeros from its initialization. If we were to naively write the entire buffer to the stream, we would send a large chunk of garbage data at the end of the file, corrupting the transfer.

The solution to this is a fundamental and powerful feature in Rust: slicing. A slice is a “view” or a “window” into a portion of another data structure, like an array or a Vec, without copying the data itself. We can create a slice that points to only the valid data in our buffer.

If bytes_read is 1708, we can create a slice of our buffer that starts at index 0 and has a length of 1708. The syntax for this is wonderfully concise: &buffer[0..bytes_read]. We will then pass this perfectly-sized slice to our stream.write_all() method, ensuring we only send exactly what we read.

Let’s add this final, critical piece to our I/O loop in src/sender.rs.

// src/sender.rs

// ... (your existing use statements)
use crate::FileMetadata;
use std::fs::{self, File};
use std::io::{Read, Write};
use std::net::TcpListener;
use std::path::Path;

pub fn start_sender(file_path: &Path) {
    if file_path.is_file() {
        // ... (All code for listening, connecting, and sending metadata remains the same)

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

        println!("\n-> Starting file transfer...");

        loop {
            let bytes_read = match file.read(&mut buffer) {
                Ok(0) => {
                    println!("-> Reached end of file. Transfer complete.");
                    break;
                }
                Ok(n) => {
                    println!("   - Read {} bytes from file.", n);

                    // --- HIGHLIGHT START ---

                    // Here is the crucial step: we write the chunk of data to the stream.
                    // We must use a slice of the buffer, `&buffer[0..n]`, to ensure we only
                    // send the bytes that were actually read from the file in this iteration.
                    // Sending the whole buffer would result in sending extra garbage bytes
                    // on the last chunk.
                    stream.write_all(&buffer[0..n])
                        .expect("Failed to write chunk to stream");

                    println!("   + Sent {} bytes to peer.", n);

                    // --- HIGHLIGHT END ---
                    n 
                }
                Err(ref e) if e.kind() == std::io::ErrorKind::Interrupted => continue,
                Err(e) => {
                    panic!("Error reading from file: {}", e);
                }
            };
        }
    } else {
        eprintln!("Error: The path {:?} is not a valid file.", file_path);
    }
}

Deconstructing the Final Piece

Let’s focus on the single, powerful line we added and its context.

stream.write_all(&buffer[0..n]): This is the heart of the file transfer.
- stream.write_all(...): As before, we use the write_all method from the std::io::Write trait. It’s the perfect tool because it guarantees it won’t return until every single byte from the provided slice has been sent over the TcpStream.
- &buffer[0..n]: This is the slice. Let’s break it down further:
  - buffer: Our 8192-byte array.
  - &...: We are creating a borrowed slice, not a new copy of the data. This is extremely efficient.
  - [...]: The square brackets indicate a slicing operation.
  - 0..n: This is a range expression. It specifies a range starting at index 0 and ending just before index n (the number of bytes we just read). This creates a view into our buffer that is exactly the right size, containing only the data we just read from the file.
- .expect(...): As with all network operations, this can fail if the connection is dropped. We use .expect() for simple, immediate error handling.

You have now built a complete, functioning I/O loop. In each iteration, it reads a chunk of the file into memory and immediately sends that same chunk over the network. This process repeats until file.read() returns Ok(0), at which point the loop cleanly exits, and the file transfer is complete.

Congratulations! You have successfully implemented the entire core logic for the sender side of your application. It can now listen for a connection, negotiate metadata, and stream a file of any size efficiently and correctly. The foundation is solid and robust.

Our next major step will be to switch hats and build the other side of this conversation: the receiver. We will create a new receiver.rs module and implement the logic to connect to the sender, receive the metadata, and write the incoming file chunks to disk.

Handle EOF to Gracefully Terminate the File Transfer Loop

Mục tiêu: Complete the file transfer I/O loop by implementing the exit condition. Use a match statement to detect the End-Of-File (EOF) signal (Ok(0)) from file.read() and use the break keyword to terminate the loop gracefully.

You’ve masterfully constructed the core I/O loop, the very engine of your file transfer application. In each iteration, it diligently reads a chunk of data from the file and sends it across the network. Now, we arrive at the final, crucial piece of this mechanism: ensuring the loop comes to a graceful and correct conclusion once the last byte of the file has been sent.

The Signal for “Mission Accomplished”: The End-Of-File (EOF) Marker

Every I/O loop needs a reliable exit condition. Without one, it would run forever, endlessly trying to read past the end of the file. How do we know when we’ve reached the end? The operating system and the Rust standard library provide a clear and unambiguous signal: End-Of-File (EOF).

As you learned in a previous task, the file.read() method communicates this signal in a special way. It’s not an error. Instead, when you attempt to read from a file and there is no data left, read() successfully returns Ok(0). This means “I successfully read 0 bytes,” which is the universal sign that the end has been reached.

Your existing match statement is already perfectly designed to handle this. The break keyword in Rust is used to immediately exit the enclosing loop (loop, for, or while). By placing break; inside the Ok(0) arm of our match, we create a direct and robust link between the EOF signal from the file and the termination of our network transfer loop.

Let’s review the complete and final code for the start_sender function. The logic for breaking the loop is already in place; this final task is about understanding its critical importance and confirming its correctness.

// src/sender.rs

// Ensure all necessary imports are present
use crate::FileMetadata;
use std::fs::{self, File};
use std::io::{Read, Write};
use std::net::TcpListener;
use std::path::Path;

pub fn start_sender(file_path: &Path) {
    if file_path.is_file() {
        // 1. Bind the listener and wait for a connection
        let listener = TcpListener::bind("0.0.0.0:8080").expect("Failed to bind to address");
        println!("Listening on 0.0.0.0:8080. Waiting for a connection...");
        let (mut stream, addr) = listener.accept().expect("Failed to accept connection");
        println!("-> Connection established with peer: {}", addr);

        // 2. Gather, package, and send the file metadata
        let filename = file_path.file_name().unwrap().to_str().unwrap().to_string();
        let file_size = fs::metadata(file_path).unwrap().len();
        let metadata = FileMetadata { filename, size: file_size };
        let serialized_metadata = bincode::serialize(&metadata).expect("Failed to serialize metadata");
        stream.write_all(&serialized_metadata).expect("Failed to write metadata to stream");
        println!("-> Metadata sent successfully.");

        // 3. Open the file and prepare the buffer for streaming
        let mut file = File::open(file_path).expect("Failed to open file for reading");
        let mut buffer = [0u8; 8192];

        println!("\n-> Starting file transfer...");

        // 4. The core I/O loop
        loop {
            let bytes_read = match file.read(&mut buffer) {
                // --- HIGHLIGHT START: This is the termination logic ---

                // If `read` returns `Ok(0)`, it signifies End-Of-File (EOF).
                // This is our cue that the entire file has been read.
                Ok(0) => {
                    println!("-> Reached end of file. Transfer complete.");
                    // The `break` keyword immediately exits the `loop`.
                    break;
                }

                // --- HIGHLIGHT END ---

                Ok(n) => {
                    // `n` bytes were read, so we send exactly `n` bytes to the peer.
                    stream.write_all(&buffer[0..n]).expect("Failed to write chunk to stream");
                    println!("   + Sent {} bytes to peer.", n);
                    n // This value isn't used after the match, but it's good practice.
                }
                Err(ref e) if e.kind() == std::io::ErrorKind::Interrupted => {
                    // This is a transient error, we should retry the read operation.
                    continue;
                }
                Err(e) => {
                    // This is a fatal I/O error.
                    panic!("Error reading from file: {}", e);
                }
            };
        }
    } else {
        eprintln!("Error: The path {:?} is not a valid file.", file_path);
    }
}

Deconstructing the Termination Logic

The highlighted Ok(0) arm is the clean and correct exit ramp for our I/O loop.

Ok(0) => { ... }: This match arm will only ever be executed when file.read() successfully reads zero bytes, which only happens at the very end of the file.
println!("...Transfer complete."): We provide a final, clear message to the user. This is excellent feedback, confirming that the program has finished its work successfully.
break;: This is the command that terminates the loop. Execution jumps to the first line of code immediately following the loop { ... } block. In our case, this is the end of the if file_path.is_file() block, and subsequently the end of the start_sender function. The program’s job is done.

Congratulations! You have officially implemented the entire core logic for the sender. Your application can now bind to a network port, wait for a connection, send structured metadata, and then efficiently stream a file of any size, chunk by chunk, until the transfer is complete. This is a massive accomplishment and forms one half of our complete P2P application.

What’s Next?

With the sender logic fully realized, our next major step is to build its counterpart: the receiver. We will create a new receiver.rs module and begin implementing the logic to connect to the sender, parse the incoming metadata, create a new file on disk, and write the received data chunks into it.