Create the Receiver Module in Rust

Mục tiêu: Set up the structural foundation for the file receiver by creating a new receiver.rs file and declaring it as a module within the main.rs file of a Rust P2P file-sharing application.

An outstanding job completing the entire core logic for the sender! You’ve built a robust piece of software that can listen for connections, communicate metadata, and stream a file of any size. This is a massive achievement. Now, it’s time to build its counterpart—the other side of the conversation. Every sender needs a receiver, and that’s precisely what we will build next.

Just as we did for the sender, we will create a dedicated, organized space for all the receiver’s logic. This practice of separation of concerns is a cornerstone of building maintainable and scalable software. By creating a receiver module, we ensure that all the code related to receiving a file lives in one predictable place, making our project significantly easier to read, debug, and expand upon in the future. We will follow the exact same pattern we used to create the sender.rs module.

Step 1: Create the receiver.rs File

Your first action is to create the physical file that will house our new module. Navigate to the src directory within your project and create a new, empty file named receiver.rs.

After creating the file, your project’s directory structure should look like this:

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

This new file is now ready to be filled with the logic for connecting to a sender, receiving metadata, and writing the incoming file to disk.

Step 2: Declare the Receiver Module in main.rs

Creating the file isn’t enough; we need to tell the Rust compiler that this new file is part of our application’s compilation unit. We do this by declaring it as a module within our crate’s root, which is src/main.rs.

Open src/main.rs and add the mod receiver; declaration. The best place for it is right next to the mod sender; declaration for organizational consistency.

// src/main.rs

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

mod sender;
// HIGHLIGHT START
// This line declares another new module named `receiver`.
// Following Rust's module system rules, the compiler will now look for a file
// named `receiver.rs` (or `receiver/mod.rs`) in the `src` directory and include it.
mod receiver;
// 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

With this single line, you have successfully integrated receiver.rs into your project. The compiler is now aware of this new module, and any public functions or structs you define within it will be accessible from other parts of your code (like main.rs).

You’ve now laid the structural foundation for the receiver. The next logical step is to populate this new, empty module with its primary entry point: the start_receiver function. This function will contain all the logic for connecting to the sender and orchestrating the file download.

Further Reading

To reinforce your understanding of Rust’s powerful module system, which is fundamental to writing well-structured applications, these resources are highly recommended:

Define the start\_receiver Function Skeleton in Rust

Mục tiêu: Create the public entry point function start\_receiver in the src/receiver.rs file. This function will take a server address as a &str and contain placeholder logic to print a confirmation message.

Excellent work setting up the receiver.rs module! You’ve successfully created a dedicated, organized space for the receiver’s logic, following the best practices for structuring a clean and maintainable Rust project. With the empty file now part of your project, our next step is to give it a purpose by defining its primary entry point: the start_receiver function.

Defining the Receiver’s Entry Point

Just as start_sender acts as the main orchestrator for the sender, start_receiver will be the function that coordinates all the logic for the receiver. This public function will be called from main.rs when the user runs the receive subcommand. It will be responsible for connecting to the sender, receiving the metadata, and downloading the file.

For this task, we will define the function’s signature—its name, arguments, and return type—and add some initial placeholder logic. This allows us to build and test the application’s structure before diving into the complexities of network programming.

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

// src/receiver.rs

/// The main public function for the receiver's logic.
/// This function will orchestrate the entire process of connecting to a sender
/// and receiving a file. It is marked `pub` (public) so it can be called from
/// outside this module, specifically from our `main` function in `main.rs`.
///
/// # Arguments
/// * `server_address`: A string slice representing the sender's IP address and port
///   (e.g., "192.168.1.10:8080").
pub fn start_receiver(server_address: &str) {
    // For now, this function simply prints a message to confirm it has been called
    // with the correct arguments. This serves as a placeholder for the networking
    // logic that will be added in the upcoming tasks.
    println!(
        "-> Receiver logic initiated. Attempting to connect to sender at: {}",
        server_address
    );

    // In the next task, we will replace this `println!` with the code to
    // actually establish a TCP connection to the sender.
}

Deconstructing the start_receiver Function

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

Visibility: The pub Keyword

The function signature pub fn start_receiver(...) begins with the pub keyword. In Rust’s module system, items are private by default, meaning they can only be used within the module where they are defined (in this case, receiver.rs). Since we need to call this function from main.rs, we must explicitly mark it as pub (public) to make it visible and accessible from other parts of our application. This is the same principle you applied to start_sender.

The Function Argument: server_address: &str

This is a key part of writing idiomatic Rust. Let’s break down why &str is the correct choice here:

  1. String vs. &str (String Slice):

    • A String is an owned, heap-allocated, and growable string buffer. It’s what you use when you need to own and modify string data.
    • A &str is a borrowed “string slice.” It’s a view into some string data that is owned by someone else. It is immutable by default and very efficient because it doesn’t require a new memory allocation.

  2. Why &str is Preferred for Function Arguments: When a function only needs to read string data without taking ownership of it, accepting a &str is more flexible and efficient. This is the exact same principle you followed when defining start_sender(file_path: &Path). The clap argument parser will likely give us an owned String, but by accepting a &str, our function can work with a reference to that String without needing to copy it. This is a fundamental concept in Rust’s ownership and borrowing system that leads to more performant and versatile code.

Placeholder Logic

For now, the function’s body contains a single println! statement. This simple line is a crucial piece of scaffolding. It allows us to:

  1. Verify Integration: In a later step, when we connect the CLI logic in main.rs, we can run the receive command and see this message printed. This confirms that all the pieces are wired together correctly.
  2. Provide User Feedback: It immediately tells the user that the program has started and is attempting to perform the requested action.

You have now successfully created the skeleton for our receiver. This start_receiver function provides a clean entry point and a solid foundation upon which we will build the rest of the receiver’s logic.

The next task will be to replace the placeholder println! with the first real piece of networking code: using std::net::TcpStream::connect to establish a connection with the waiting sender.

Further Reading

Connect Receiver to Sender with TcpStream

Mục tiêu: Update the start\_receiver function to establish a network connection to the sender. Use std::net::TcpStream::connect to initiate the connection and handle potential errors with .expect(), storing the successful connection in a mutable stream variable.

Excellent, you have defined the start_receiver function, creating a clear and logical entry point for the receiver’s operations. The placeholder message you added is perfect for verifying that the command-line arguments are being passed correctly. Now, it’s time to replace that placeholder with the first real piece of networking code: initiating a connection to the sender.

Reaching Out: Connecting to the Sender with TcpStream

In our peer-to-peer model, while the sender acts as a temporary server by listening for a connection, the receiver acts as the client by actively initiating that connection. The primary tool for this in Rust’s standard library is std::net::TcpStream.

You’ve already encountered TcpStream on the sender side; it’s what you get back from listener.accept(). On the receiver side, we create one directly by using the TcpStream::connect() associated function. This function is the counterpart to the sender’s listener.accept() call.

When you call TcpStream::connect(server_address), your program performs a series of actions under the hood, known as the TCP three-way handshake:

  1. Your receiver sends a SYN (synchronize) packet to the sender’s address.
  2. If the sender is listening and accepts, it responds with a SYN-ACK (synchronize-acknowledgment) packet.
  3. Your receiver completes the handshake by sending an ACK (acknowledgment) packet back.

Once this handshake is complete, a stable, two-way communication channel is established. The TcpStream::connect() function then returns, giving you the TcpStream object that represents this channel.

This operation is blocking; your program will pause and wait until the connection is either successfully established or an error occurs.

Handling Connection Failures

Connecting to a network address is an inherently fallible operation. The connection might fail for many reasons: * The sender’s IP address or port might be incorrect. * The sender’s application might not be running. * A firewall on either the sender’s or receiver’s machine could be blocking the connection. * General network issues could prevent the packets from reaching their destination.

Because of these possibilities, TcpStream::connect() doesn’t return a TcpStream directly. Instead, it returns a Result<TcpStream, std::io::Error>. To handle this, we will continue our established pattern of using the .expect() method. If the connection succeeds, .expect() will give us the TcpStream. If it fails, the program will panic and display a clear error message, which is perfect for development.

Let’s update src/receiver.rs to implement this connection logic.

First, add the necessary use statement at the top of the file.

// src/receiver.rs

// HIGHLIGHT START
// Import the TcpStream type from the standard library's net module.
// This is the primary type for representing a TCP connection.
use std::net::TcpStream;
// HIGHLIGHT END

Now, modify the start_receiver function to replace the placeholder println! with the connection code.

// src/receiver.rs

use std::net::TcpStream;

pub fn start_receiver(server_address: &str) {
    println!(
        "-> Receiver logic initiated. Attempting to connect to sender at: {}",
        server_address
    );

    // --- HIGHLIGHT START ---

    // `TcpStream::connect` attempts to establish a TCP connection to the specified address.
    // This is a blocking operation and will return a `Result`.
    // We use `.expect()` for simple error handling. If the connection fails,
    // the program will panic with the provided message.
    // The resulting `stream` must be mutable so we can read data from it.
    let mut stream = TcpStream::connect(server_address)
        .expect("Failed to connect to the sender");

    // This message provides crucial user feedback, confirming that the network
    // connection was successfully established.
    println!("-> Successfully connected to sender: {}", server_address);

    // --- HIGHLIGHT END ---
}

Deconstructing the Code

Let’s break down the new code in detail: * use std::net::TcpStream;: This line brings the TcpStream type into our module’s scope, allowing us to use it directly. * let mut stream = TcpStream::connect(server_address).expect(...): This is the core of our task. * TcpStream::connect(server_address): We call the connect function, passing it the address string that was provided by the user on the command line. * .expect("Failed to connect to the sender"): We handle the Result. If the connection fails for any reason, our program will stop and print this helpful message. * let mut stream: We declare the variable stream as mutable. This is critically important. Just like reading from a file handle, reading from a network stream changes its internal state (it consumes data from an internal buffer). Because the act of reading is a mutating operation, Rust requires us to be explicit by marking the stream variable with mut. * println!("-> Successfully connected to sender: ...");: This line is executed only after TcpStream::connect returns successfully. It serves as a clear confirmation to the user that the first and most uncertain step—establishing the network link—is complete.

You have now successfully implemented the client-side connection logic. Your receiver application can now reach out across the network and establish a communication channel with the waiting sender.

With this stream object in hand, you are now ready for the next phase of the protocol: listening for incoming data. Your next task will be to read the serialized FileMetadata bytes from this stream.

Further Reading

Deserialize File Metadata from a TCP Stream in Rust

Mục tiêu: Implement the receiver logic to read from a TcpStream and deserialize a FileMetadata struct using bincode::deserialize_from. This function reads directly from the stream, solving the common networking problem of handling variable-length messages.

You’ve successfully established a TcpStream from the receiver to the sender, creating a live communication channel across the network. This is a fantastic milestone! Your receiver is now connected and waiting. According to our protocol, the very first thing the sender will do is transmit the serialized FileMetadata. Your receiver’s immediate job is to read and interpret this crucial first message.

The Challenge: Reading a Message of Unknown Size

A TcpStream is exactly what its name implies: a continuous, unstructured stream of bytes. It doesn’t have built-in “messages” or “packets.” The sender wrote a sequence of bytes representing the FileMetadata, but how does the receiver know exactly how many bytes to read? The size of this data isn’t fixed because the filename can have any length.

If we read too few bytes, we’ll have an incomplete structure that fails to deserialize. If we read too many, we’ll accidentally consume the beginning of the actual file content, corrupting the rest of the transfer.

The Solution: Stream-Aware Deserialization with bincode

Fortunately, this is a classic problem in networking, and the bincode crate provides an elegant and powerful solution. While we used bincode::serialize on the sender side to turn a struct into a byte vector, the receiver can use a more advanced function: bincode::deserialize_from.

This function is specifically designed to work with a source that implements the std::io::Read trait, which our TcpStream does. Instead of needing all the bytes in a buffer upfront, bincode::deserialize_from reads from the stream just enough bytes to build the target struct.

How does it work? It’s quite clever:

  1. It knows the structure of FileMetadata (a String and a u64).
  2. It knows that bincode’s format for a String is to first write the string’s length (as a u64), followed by the string’s UTF-8 bytes.
  3. So, deserialize_from first reads 8 bytes from the stream to determine the length of the upcoming filename.
  4. It then reads exactly that many bytes for the filename’s content.
  5. Finally, it reads another 8 bytes for the size field (u64).
  6. Once it has all the pieces, it assembles the FileMetadata struct and returns.

This abstracts away all the complexity of manual buffering and byte-counting, making our code clean, robust, and concise.

Let’s implement this in your receiver.rs file.

First, we need to bring our FileMetadata struct into the scope of this module, just as we did in sender.rs.

// src/receiver.rs

// HIGHLIGHT START
// Bring our custom FileMetadata struct into the scope of this module.
// `crate` refers to the root of our own crate, where `FileMetadata` is defined.
use crate::FileMetadata;
// HIGHLIGHT END
use std::net::TcpStream;

Now, let’s add the deserialization logic to the start_receiver function.

// src/receiver.rs

use crate::FileMetadata;
use std::net::TcpStream;

pub fn start_receiver(server_address: &str) {
    println!(
        "-> Receiver logic initiated. Attempting to connect to sender at: {}",
        server_address
    );

    let mut stream = TcpStream::connect(server_address)
        .expect("Failed to connect to the sender");

    println!("-> Successfully connected to sender: {}", server_address);

    // --- HIGHLIGHT START ---

    println!("-> Waiting to receive file metadata...");

    // `bincode::deserialize_from` reads bytes directly from any source that
    // implements `std::io::Read` (like our `TcpStream`) and constructs a
    // new object from that data.
    //
    // This is a blocking operation. The function will read from the stream until
    // it has enough bytes to form a complete `FileMetadata` struct.
    //
    // We must provide an explicit type annotation (`: FileMetadata`) so that
    // bincode knows what data structure it should be building.
    // The operation returns a `Result`, which we handle with `.expect()`.
    let metadata: FileMetadata = bincode::deserialize_from(&mut stream)
        .expect("Failed to deserialize metadata from sender");

    // This print statement is a crucial verification step. It confirms that we
    // have successfully received and decoded the metadata. We use the `Debug`
    // format specifier `{:?}` which works because we added `#[derive(Debug)]`
    // to our `FileMetadata` struct.
    println!("-> Received metadata: {:?}", metadata);

    // --- HIGHLIGHT END ---
}

Deconstructing the Code

Let’s analyze the new logic in detail:

  • use crate::FileMetadata;: This makes our FileMetadata struct available within the receiver.rs file, which is essential for the type annotation in the next step.
  • let metadata: FileMetadata = ...: We declare a new variable metadata and explicitly state its type. This type annotation is mandatory. The deserialize_from function is generic; it can create any type that implements serde::Deserialize. We must tell the compiler our specific target type so bincode knows what to build.
  • bincode::deserialize_from(&mut stream): This is the core function call.
    • We pass &mut stream, a mutable reference to our TcpStream. The function needs mutable access because reading from the stream consumes its data and changes its internal state.
    • This function reads from the stream, intelligently parsing the bincode format until it has constructed a complete FileMetadata instance.
  • .expect("Failed to deserialize metadata from sender"): The deserialization can fail if the network data is corrupted, the connection drops midway, or the sender sends data in an unexpected format. This returns a Result, which we handle with .expect() for now. A failure here is a critical error, so stopping the program is the correct action.
  • println!("-> Received metadata: {:?}", metadata);: This is our confirmation. It prints the entire received struct to the console, allowing you to see the filename and size, verifying that the first part of our protocol worked perfectly.

You have now successfully implemented the receiver’s side of the metadata exchange. The receiver is no longer blind; it knows the name and size of the file it’s about to download. This information is absolutely critical for the next steps.

With the metadata object in hand, your next task will be to use bincode to deserialize these bytes back into a FileMetadata struct, officially completing the metadata transfer.

Further Reading

Receive and Decode File Metadata from a Network Stream

Mục tiêu: Learn how to deserialize a Rust struct directly from a TcpStream using bincode::deserialize\_from. This task explains how to read bytes from a network connection and reconstruct a FileMetadata object, highlighting the role of the std::io::Read trait and type annotations.

You have brilliantly established a live TcpStream to the sender, creating the communication channel for our file transfer. The sender, following our protocol, has already sent the first crucial piece of information: the serialized FileMetadata. In the previous step, you added the code to receive this data. Now, let’s dive deep into that specific line of code and understand exactly how it works its magic, turning a raw stream of network bytes back into a meaningful Rust struct.

The Magic of Stream-Aware Deserialization

The function at the heart of this process is bincode::deserialize_from. While you used bincode::serialize on the sender side to convert a struct into a byte vector (Vec<u8>), and you used bincode::deserialize in your unit test to convert a byte slice (&[u8]) back into a struct, deserialize_from is a more advanced tool designed specifically for I/O streams like our TcpStream.

Let’s look at the code again, focusing on this critical operation.

// src/receiver.rs

// Ensure our custom FileMetadata struct is in scope.
use crate::FileMetadata;
use std::net::TcpStream;

pub fn start_receiver(server_address: &str) {
    // ... (connection logic from previous task remains the same)
    let mut stream = TcpStream::connect(server_address)
        .expect("Failed to connect to the sender");
    println!("-> Successfully connected to sender: {}", server_address);

    println!("-> Waiting to receive file metadata...");

    // --- HIGHLIGHT START: The Core Deserialization Logic ---

    // `bincode::deserialize_from` reads bytes directly from any source that
    // implements the `std::io::Read` trait (like our `TcpStream`) and constructs a
    // new object from that data.
    //
    // This is a blocking operation. The function will read from the stream only
    // the exact number of bytes it needs to form a complete `FileMetadata` struct.
    //
    // The explicit type annotation `: FileMetadata` is mandatory. It tells
    // bincode the "shape" of the data it should expect to find in the stream.
    let metadata: FileMetadata = bincode::deserialize_from(&mut stream)
        .expect("Failed to deserialize metadata from sender");

    // This print statement is a crucial verification step. It confirms that we
    // have successfully received and decoded the metadata. The `{:?}` format
    // specifier works because we added `#[derive(Debug)]` to our `FileMetadata` struct.
    println!("-> Received metadata: {:?}\n", metadata);

    // --- HIGHLIGHT END ---
}

Deconstructing bincode::deserialize_from

This single line of code is doing a remarkable amount of work for us. Let’s break it down to fully appreciate its power and elegance.

1. It Works with Streams, Not Slices

The key difference between deserialize and deserialize_from is their input. deserialize requires a complete byte slice (&[u8]) containing all the data. In our network scenario, we don’t know the exact size of the incoming metadata beforehand (the filename’s length varies). deserialize_from solves this by taking a source that implements std::io::Read, such as our &mut stream. It reads from the stream on its own, byte by byte, until it has consumed exactly enough data to build the target struct. This completely removes the need for us to manage a temporary buffer or worry about message boundaries for the metadata.

2. It’s Guided by the Type Annotation

How does bincode know when to stop reading? It’s guided by the type you provide. When you write let metadata: FileMetadata = ..., you are giving bincode a blueprint. It inspects the FileMetadata struct and understands its composition: * A field named filename of type String. * A field named size of type u64.

bincode knows how it serializes these types, so it can reverse the process:

  1. For the String: It knows its own format is to first write the string’s length as a u64 (8 bytes). So, deserialize_from begins by reading 8 bytes from the stream to figure out how long the filename is.
  2. Let’s say it reads a length of 13. It now knows it must read exactly 13 more bytes from the stream for the filename’s content.
  3. For the u64: After reading the filename, it knows the next field is a u64, which has a fixed size of 8 bytes. It proceeds to read the final 8 bytes from the stream.

Once it has gathered all the necessary pieces, it constructs the FileMetadata instance and returns it. This intelligent, type-driven parsing is what makes serde and bincode so powerful and robust.

3. It Handles Errors Gracefully

Networking is unreliable. The connection could drop while deserialize_from is halfway through reading the data. The data itself could be corrupted. bincode is designed for this reality. The function returns a Result, which will be Err if it can’t successfully parse a complete FileMetadata struct from the stream. Our use of .expect() turns a potential error into an immediate program crash with a clear message, which is a perfect strategy during development.

What’s Next?

You have now successfully received and decoded the “instructions” for the file transfer. The metadata variable holds the two most important pieces of information you need: the filename you should create on your local disk and the total size of the file you should expect to receive.

With this vital information in hand, you are perfectly prepared for the next logical step: creating a new, empty file on the local filesystem that will receive the incoming data.

Further Reading

Prepare File Destination for TCP Transfer in Rust

Mục tiêu: Using received file metadata, create a new local file with std::fs::File::create to serve as the destination for an incoming network file transfer. This involves handling the Result of the I/O operation and making the file handle mutable for subsequent writes.

You have brilliantly decoded the first message from the sender! By deserializing the data directly from the TcpStream, you now hold a metadata variable that contains the two most critical pieces of information for the entire transfer: the filename and the total size of the incoming file. The receiver is no longer operating in the dark; it has its instructions.

Our immediate task is to act on these instructions. Before we can receive a single byte of the file’s content, we must prepare a place for it to live on our local disk. This means creating a new, empty file with the exact name provided by the sender.

Preparing the Destination: Creating a File with std::fs::File::create

To interact with the filesystem in Rust, we turn to the std::fs module. Specifically, we’ll use the std::fs::File::create() function. This function is the perfect tool for our needs. It takes a path to a file and does one of two things:

  1. If the file does not exist, it creates a new, empty file at that path.
  2. If the file already exists, it opens the file and truncates it, meaning it erases all of its current contents, leaving it empty and ready to be written to.

This “create-or-truncate” behavior is exactly what we want. It ensures that each time we receive a file, we start with a clean slate, preventing new data from being appended to an old, partially downloaded file.

Like all I/O operations that can fail, File::create() returns a Result<File, std::io::Error>. A failure could occur if, for example, our program doesn’t have permission to write to the current directory. We will continue to use .expect() to handle this Result, which will halt the program with a clear error message if the file cannot be created.

Let’s add the necessary code to your receiver.rs file.

First, bring the File type into scope at the top of the file.

// src/receiver.rs

use crate::FileMetadata;
// HIGHLIGHT START
// Import the `File` type from the standard library's `fs` (filesystem) module.
use std::fs::File;
// HIGHLIGHT END
use std::net::TcpStream;

Now, let’s add the file creation logic to the start_receiver function, right after you’ve successfully received and printed the metadata.

// src/receiver.rs

use crate::FileMetadata;
use std::fs::File;
use std::net::TcpStream;

pub fn start_receiver(server_address: &str) {
    // ... (connection and metadata deserialization logic remains the same)
    let mut stream = TcpStream::connect(server_address)
        .expect("Failed to connect to the sender");
    println!("-> Successfully connected to sender: {}", server_address);

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

    // --- HIGHLIGHT START ---

    // Now, use the received filename to create a new file on the local disk.
    // `File::create` will create the file if it doesn't exist, or overwrite it
    // (by truncating it to 0 bytes) if it does.
    // The operation returns a `Result`, so we `.expect()` to handle potential errors.
    // The `file` handle must be mutable (`mut`) because we will be writing data
    // into it, which is a mutating operation that changes the file's state.
    let mut file = File::create(&metadata.filename)
        .expect("Failed to create file on local disk");

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

    // --- HIGHLIGHT END ---
}

Deconstructing the File Creation Logic

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

  • let mut file = File::create(&metadata.filename)...: This is the core of our task.
    • File::create(&metadata.filename): We call the create function, passing a reference to the filename string from our metadata struct. The function only needs to read the path, so we pass a borrowed reference (&) instead of giving it ownership of the string.
    • .expect(…): We handle the Result. If the file can’t be created (e.g., due to a permissions error), our program will stop with this specific, helpful message.
    • mut file: This is a fundamentally important concept in Rust. Why must file be mutable? Because a file handle represents a stateful resource. When we write data to the file in the upcoming steps, we are changing its contents and advancing an internal cursor. Since the act of writing mutates the state of the file on disk, Rust requires us to be explicit about this intent by marking the variable that holds the file handle as mut. This enforces safety and clarity in our code.

You have now successfully prepared the destination. You have an open communication channel to the sender (the stream), which is your source of bytes, and you have an open, empty file on disk (the file), which is your destination for those bytes.

With both the source and the destination ready, the stage is perfectly set for the core I/O loop. The next logical steps will be to initialize a byte counter, create a buffer, and begin reading the file content from the stream and writing it into your newly created file.

Further Reading

Initialize a Byte Counter for File Transfer Progress

Mục tiêu: In the Rust file receiver, initialize a mutable u64 counter to track the number of bytes received. This counter will be used to determine when the file transfer is complete by comparing its value to the total file size specified in the metadata.

You have done an excellent job preparing the receiver! You’ve connected to the sender, received and decoded the file’s metadata, and even created the destination file on your local disk. You have your data source (the stream) and your data destination (the file) ready to go.

Before we can start the main transfer loop, however, we need a reliable way to know when to stop. How will the receiver know when it has received the entire file? This is where the metadata you just received becomes invaluable. Our current task is to set up the mechanism to track our download progress.

The Receiver’s Compass: A Byte Counter

On the sender side, the I/O loop knew when to stop because it received an “End-of-File” (EOF) signal when reading from the local file. The receiver doesn’t have this luxury. A network TcpStream doesn’t have a built-in EOF marker for a logical file transfer. If the sender simply closes the connection, it’s an abrupt end, not a clean completion signal.

A far more robust and reliable method is to use the size information we so carefully transmitted in our FileMetadata. The protocol is simple and clear: the sender has promised to send exactly metadata.size bytes of file content. Our job as the receiver is to read bytes from the network and count them until our count matches that promised size.

To do this, we need a variable to act as our counter. We will initialize it to zero before the transfer begins and increment it with every chunk of data we receive.

Let’s add this counter to your start_receiver function in src/receiver.rs.

// src/receiver.rs

use crate::FileMetadata;
use std::fs::File;
use std::net::TcpStream;

pub fn start_receiver(server_address: &str) {
    // ... (connection, deserialization, and file creation logic remains the same)
    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");
    println!(
        "-> Created new file '{}'. Ready to receive data...",
        metadata.filename
    );

    // --- HIGHLIGHT START ---

    // Initialize a counter to track the number of bytes we have received so far.
    // This is crucial for determining when the file transfer is complete.
    // The loop's termination condition will be `bytes_received == metadata.size`.
    //
    // We explicitly type it as `u64` to match the type of `metadata.size`, ensuring
    // our application can handle files larger than 4 GB. The variable must be
    // declared as `mut` because we will be incrementing its value inside our
    // upcoming download loop.
    let mut bytes_received: u64 = 0;

    println!(
        "-> Initialized byte counter. Total size to receive: {} bytes.",
        metadata.size
    );

    // --- HIGHLIGHT END ---
}

Deconstructing the Counter

This single line of code is simple, but every part of it is chosen deliberately for correctness and safety.

  • let mut bytes_received: We declare a new variable named bytes_received. The mut keyword is essential. It marks the variable as mutable, meaning its value is allowed to change. We will be adding to this counter with every chunk of data we download, so it must be mutable. By default, Rust variables are immutable, which helps prevent accidental changes and makes code easier to reason about.
  • : u64: This is an explicit type annotation. We are telling the Rust compiler that bytes_received must be a u64 (a 64-bit unsigned integer). This is a critical choice for robustness. We defined the size field in our FileMetadata struct as a u64 so we could support files larger than 4GB. Our counter must use the same type to ensure we can correctly compare our progress against the total size without any risk of integer overflow.
  • = 0;: We initialize the counter to zero. This is the logical starting point, as we have not yet received any of the file’s content bytes. The metadata bytes do not count towards this total.

You have now successfully set up the primary control mechanism for our upcoming download loop. This bytes_received counter will be the single source of truth for our progress.

With this counter in place, the next logical steps are to create a buffer to hold the incoming data chunks and then to build the I/O loop itself. Inside that loop, you will read from the stream, write to the file, and—most importantly—increment this counter, checking after each chunk to see if the transfer is complete.

Further Reading

Implement the Core I/O Loop for a Rust File Receiver

Mục tiêu: Set up a while loop to continuously read data chunks from a TcpStream into a buffer until the complete file is received, handling various read outcomes like success, connection closure, and errors.

Excellent work setting up the bytes_received counter! You’ve established the “finish line” for our download. With the destination file created and our progress tracking mechanism in place, it’s time to build the engine that will get us there: the core I/O loop.

This task is the mirror image of the sender’s logic. Where the sender read from a file and wrote to the network, we will now read from the network and prepare to write to a file. This process starts with reading the incoming data chunks into a temporary holding area—a buffer.

Setting Up the I/O Loop and Buffer

Just as on the sender side, it would be incredibly inefficient to try and receive an entire multi-gigabyte file into memory at once. The standard, robust approach is to receive the file in manageable chunks using a buffer. We’ll create a buffer of the same size as the sender’s for consistency and efficiency: 8192 bytes (8 KiB).

With the buffer ready, we need a loop that will continue to execute until we have received the total number of bytes promised by the sender. The while loop is the perfect tool for this job. Our loop’s condition will be simple and clear: continue as long as bytes_received < metadata.size.

Inside this loop, we will perform the main action for this task: reading data from the TcpStream into our buffer. To do this, we’ll use the .read() method, which is available on TcpStream because it implements the std::io::Read trait.

First, let’s bring the necessary Read and Write traits into scope at the top of src/receiver.rs. We’ll need Write in the next task, so it’s good practice to add it now.

// src/receiver.rs

use crate::FileMetadata;
use std::fs::File;
// HIGHLIGHT START
// Import the `Read` and `Write` traits from `std::io`.
// - `Read` provides the `.read()` method for our `TcpStream`.
// - `Write` will provide the `.write_all()` method for our `File` in the next task.
use std::io::{Read, Write};
// HIGHLIGHT END
use std::net::TcpStream;

Now, let’s add the buffer and the I/O loop to the start_receiver function.

// src/receiver.rs

// ... (your existing use statements)

pub fn start_receiver(server_address: &str) {
    // ... (connection, deserialization, file creation, and counter logic remains the same)

    let mut bytes_received: u64 = 0;

    // --- HIGHLIGHT START ---

    // Create a buffer of 8 KiB to hold the incoming data chunks.
    // It must be `mut` because the `stream.read()` operation will write data into it.
    let mut buffer = [0u8; 8192];

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

    // This loop continues as long as we have not yet received all the bytes
    // promised by the sender in the metadata.
    while bytes_received < metadata.size {
        // `stream.read` attempts to read bytes from the network into our buffer.
        // It returns a `Result` indicating how many bytes were actually received.
        let bytes_read = match stream.read(&mut buffer) {
            // `Ok(0)` means the sender has closed the connection. If this happens
            // before we've received all the data, it's an unexpected closure.
            Ok(0) => {
                println!("-> Sender closed the connection unexpectedly.");
                break; // Exit the loop.
            }
            // `Ok(n)` means `n` bytes were successfully read from the stream.
            Ok(n) => {
                println!("   - Received {} bytes from sender.", 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 file.
                n // The number of bytes read is the result of this match arm.
            }
            // An error occurred during the read. A common transient error is
            // `Interrupted`, which we can safely retry by continuing the loop.
            Err(ref e) if e.kind() == std::io::ErrorKind::Interrupted => {
                continue; // Retry the read.
            }
            // Any other error is treated as fatal for the transfer.
            Err(e) => {
                panic!("Error reading from stream: {}", e);
            }
        };

        // We will use `bytes_read` in the next tasks to write to the file
        // and to increment our `bytes_received` counter.
    }

    // --- HIGHLIGHT END ---
}

Deconstructing the Receiver’s I/O Loop

This new block of code is the heart of our receiver. Let’s analyze it piece by piece.

  • let mut buffer = [0u8; 8192];: This creates our 8 KiB buffer on the stack, identical to the sender’s. It must be mut because stream.read() will modify its contents by filling it with data from the network.
  • while bytes_received < metadata.size: This is our loop’s termination condition. Before each iteration, Rust checks if the number of bytes we’ve received is still less than the total file size. As soon as this condition becomes false, the loop will terminate, and the download will be considered complete.

  • let bytes_read = match stream.read(&mut buffer) { ... }: This is the core read operation.

    • stream.read(&mut buffer): We call the read method on our TcpStream, passing a mutable reference to our buffer. This is a blocking call; the program will pause here until some data arrives from the sender or the connection is closed.
    • Return Value: The method returns a Result<usize>, which we handle with a match statement for maximum clarity and correctness.
    • Ok(0): For a TcpStream, receiving Ok(0) means the remote peer (the sender) has shut down its writing side of the connection. If we receive this signal before our byte counter has reached the total size, it means the transfer was cut short. We print a message and break out of the loop.
    • Ok(n): This is the success case. We’ve received n bytes of data, which are now stored in the first n positions of our buffer. We print a message confirming the receipt. The match arm evaluates to n, which gets stored in the bytes_read variable.
    • Err(...): We handle a potential Interrupted error by simply retrying, and we treat any other network read error as a fatal panic.

You have now successfully implemented the reading portion of the receiver’s I/O loop. Your application can now listen for incoming data and read it into a buffer, chunk by chunk. You have also set up the primary control structure (while loop) that will ensure the download stops at the correct moment.

The bytes_read variable now holds the number of valid bytes in your buffer for each iteration. The next logical step is to take this data and write it to the destination file you created earlier.

Further Reading

Write the buffer’s contents into the new file.

Mục tiêu:

Fantastic work! You’ve successfully implemented the core of the receiver’s I/O loop. In each iteration, your code now reads a chunk of incoming data from the network stream and stores it in your buffer. The bytes_read variable correctly tells you exactly how many bytes of valid data are in that buffer.

You are now holding a precious chunk of the file in your computer’s memory. The next and most crucial step is to save this data permanently by writing it to the destination file you created on your local disk.

From Memory to Disk: Writing the Buffer with std::io::Write

This task is the direct counterpart to what you just did. Where you used the std::io::Read trait to get data from the TcpStream, you will now use the std::io::Write trait to put data into the File. The std::fs::File type implements this trait, giving us access to the powerful and convenient write_all() method.

The write_all() method is the perfect tool for this job because it guarantees that it will continue writing until every single byte from the buffer you provide has been saved to the file. This simplifies our code, as we don’t need to manually handle cases where the operating system can only write a partial chunk at a time.

The Most Important Detail: Slicing the Buffer

There is one critical detail we must handle with extreme care. When the sender sends the last chunk of the file, the number of bytes it sends (bytes_read) will almost certainly be less than your total buffer size (8192 bytes).

For example, if the file is 10,000 bytes long, the receiver will get two chunks:

  1. A full chunk of 8192 bytes.
  2. A final, smaller chunk of 1708 bytes.

When you receive that second chunk, your 8192-byte buffer will contain 1708 bytes of real file data, followed by 6484 bytes of leftover data (likely zeros) from the buffer’s previous state. If you were to naively write the entire buffer to the file, you would append thousands of incorrect garbage bytes, corrupting the downloaded file.

The solution is a fundamental and elegant feature of Rust: slicing. We can create a “view” into our buffer that includes only the valid data we just received. The syntax for this is wonderfully simple: &buffer[0..bytes_read]. This creates a slice that starts at the beginning of the buffer (index 0) and includes exactly bytes_read bytes. We will pass this perfectly sized slice to write_all(), ensuring we only ever save exactly what we received from the sender.

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

// src/receiver.rs

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

pub fn start_receiver(server_address: &str) {
    // ... (connection, deserialization, file creation, and counter logic remains the same)

    let mut buffer = [0u8; 8192];

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

    while bytes_received < metadata.size {
        let bytes_read = match stream.read(&mut buffer) {
            Ok(0) => {
                println!("-> Sender closed the connection unexpectedly.");
                break;
            }
            Ok(n) => {
                println!("   - Received {} bytes from sender.", n);

                // --- HIGHLIGHT START ---

                // Here is the crucial step: we write the received chunk to the file.
                // We MUST use a slice of the buffer, `&buffer[0..n]`, to ensure we only
                // write the bytes that were actually read from the stream in this iteration.
                // Writing the entire buffer would corrupt the file with garbage data
                // on the final, smaller chunk.
                //
                // The `write_all` method can fail (e.g., if the disk is full), so it
                // returns a `Result` which we handle with `.expect()` for now.
                file.write_all(&buffer[0..n])
                    .expect("Failed to write chunk to file");

                println!("   + Wrote {} bytes to file.", n);

                // --- HIGHLIGHT END ---

                n // Return n to be stored in `bytes_read`
            }
            Err(ref e) if e.kind() == std::io::ErrorKind::Interrupted => {
                continue;
            }
            Err(e) => {
                panic!("Error reading from stream: {}", e);
            }
        };

        // The next steps will use `bytes_read` to update the counter.
    }
}

Deconstructing the File Write Operation

Let’s focus on the powerful line of code you just added.

  • file.write_all(&buffer[0..n]): This is the heart of the receiver’s work.
    • file: This is our mutable File handle, representing the open destination file on disk.
    • .write_all(): This is the method provided by the std::io::Write trait. It’s our reliable tool for saving the data.
    • &buffer[0..n]: This is the slice. Let’s break it down further:
      • buffer: Our 8192-byte array in memory.
      • &...: We are creating a borrowed slice, which is a view into the buffer’s data. This is extremely efficient as it avoids making a copy.
      • [...]: The square brackets indicate a slicing operation.
      • 0..n: This is a range expression. It specifies a range that starts at index 0 and ends just before index n (where n is the number of bytes we just received). This creates a view into our buffer that is exactly the right size.
    • .expect(…): Writing to disk is an I/O operation that can fail (e.g., the disk runs out of space, permissions change). For now, we use .expect() to handle this Result and stop the program with a clear error if the write fails.

You have now successfully completed one full cycle of the receiver’s main job. In each loop iteration, you read a chunk of data from the network and save that exact chunk to the local file.

The core data transfer mechanism is now in place! The next logical step is to update our progress tracker. You will now take the bytes_read value and use it to increment the bytes_received counter, moving you one step closer to the finish line.

Further Reading

Update Progress Counter in File Download Loop

Mục tiêu: Fix an infinite loop in the file download logic by updating the progress counter. Increment the bytes\_received total with the number of bytes read in each loop iteration, ensuring to cast the usize value to u64 to match the counter’s type.

Excellent work! You have successfully implemented the core I/O operations of the receiver. In each loop iteration, a chunk of data is read from the network and safely written to the destination file. The data is being saved, but our program’s internal “bookkeeping” is not yet complete. The while bytes_received < metadata.size loop condition will never change, creating an infinite loop.

Our current task is to fix this by updating our progress tracker. We must take the number of bytes we just processed and add it to our master counter, bytes_received. This is the crucial step that moves us closer to the finish line with every chunk we download.

Closing the Loop: Updating the Progress Counter

After successfully writing a chunk of data to the file, we have the exact number of bytes processed in the bytes_read variable. We now need to add this value to our bytes_received total. This is a simple arithmetic operation, but it involves a subtle and important detail in Rust’s type system that we must handle correctly.

The usize vs. u64 Distinction and Type Casting

Let’s look at the types of the two variables involved: * bytes_received: We explicitly declared this as a u64 to match metadata.size, ensuring our application can handle files larger than 4GB. * bytes_read: This variable gets its value from the stream.read() method, which returns a Result<usize>. Therefore, bytes_read has the type usize.

The usize type is a special integer type in Rust. Its size is platform-dependent: it’s 32 bits on a 32-bit system and 64 bits on a 64-bit system. It’s used for anything related to memory indexing, sizes of collections, and, as we see here, the results of I/O read operations.

Because bytes_received and bytes_read have different types (u64 vs. usize), we cannot directly add them. Rust’s strict type system requires us to be explicit about converting one type to another. This is called type casting. We will cast bytes_read from usize to u64 using the as keyword: bytes_read as u64.

This cast is perfectly safe in our scenario. On a 64-bit system, usize is the same as u64, so the cast does nothing. On a 32-bit system, a usize can hold values up to ~4 billion. While a file can be larger than this, a single read operation into an 8 KiB buffer will never return a number that overflows a u64. By casting to u64, we safely convert the platform-specific size into our platform-agnostic 64-bit counter.

Let’s add this final piece of logic to our I/O loop in src/receiver.rs.

// src/receiver.rs

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

pub fn start_receiver(server_address: &str) {
    // ... (connection, deserialization, file creation, and counter logic remains the same)

    let mut buffer = [0u8; 8192];
    let mut bytes_received: u64 = 0;

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

    while bytes_received < metadata.size {
        let bytes_read = match stream.read(&mut buffer) {
            Ok(0) => {
                println!("-> Sender closed the connection unexpectedly.");
                break;
            }
            Ok(n) => {
                // First, write the valid chunk of data to the file.
                file.write_all(&buffer[0..n])
                    .expect("Failed to write chunk to file");

                println!("   + Wrote {} bytes to file.", n);

                // Return `n` so it can be assigned to `bytes_read`.
                n
            }
            Err(ref e) if e.kind() == std::io::ErrorKind::Interrupted => {
                continue;
            }
            Err(e) => {
                panic!("Error reading from stream: {}", e);
            }
        };

        // --- HIGHLIGHT START ---

        // Now, increment our master counter by the number of bytes we just processed.
        // We must cast `bytes_read` (which is a `usize`) to a `u64` to match the
        // type of our `bytes_received` counter. The `+=` operator is shorthand
        // for `bytes_received = bytes_received + ...`.
        bytes_received += bytes_read as u64;

        // --- HIGHLIGHT END ---
    }

    println!("\n-> Download complete. Received a total of {} bytes.", bytes_received);
}

Deconstructing the Update Operation

Let’s focus on the single, crucial line you added outside the match block but still inside the while loop.

  • bytes_received += bytes_read as u64;:
    • bytes_received += ...: This is the add and assign operator. It’s syntactic sugar for bytes_received = bytes_received + (bytes_read as u64). It takes the current value of bytes_received, adds the new value to it, and updates bytes_received with the result.
    • bytes_read as u64: This is the explicit type cast we discussed. It tells the compiler, “I know bytes_read is a usize, but I want you to treat it as a u64 for this operation.” This satisfies the type system and allows the addition to proceed.

With this line, you have completed the feedback cycle for your download loop.

  1. The while loop checks the condition.
  2. Data is read from the network (stream.read).
  3. Data is written to the disk (file.write_all).
  4. The progress counter is updated (bytes_received += ...).
  5. The loop repeats.

This cycle will continue until bytes_received is no longer less than metadata.size. At that moment, the while loop’s condition will become false, and the loop will terminate naturally and correctly.

The core mechanism of your receiver is now complete! The final task in this step is to recognize and confirm that this while loop condition is the correct and sufficient mechanism to break the loop once the entire file has been downloaded.

Further Reading

Break the loop once the number of received bytes equals the file size from the metadata.

Mục tiêu:

Incredible work! You have successfully constructed the entire data processing pipeline for the receiver. In each iteration of your loop, a chunk of data is read from the network, safely written to the destination file, and your progress counter is diligently updated. The engine is running perfectly.

We now arrive at the final, and perhaps most elegant, part of this process: the “off switch.” Every loop needs a reliable exit condition, and in this task, we will confirm and understand why the mechanism you’ve already built is the correct and robust way to gracefully conclude the file transfer.

The Receiver’s Contract: Trusting the Metadata

On the sender side, the I/O loop terminated when it received an “End-of-File” (EOF) signal while reading from the local disk. The receiver’s situation is different. A TcpStream doesn’t provide a neat “End-of-File-Transfer” signal. A closed connection could be an error, not a successful completion.

This is precisely why our protocol’s first step—sending the FileMetadata—is so critical. The metadata.size field is more than just a number; it’s a contract or a promise from the sender. The sender has promised to send exactly that many bytes of file content. The receiver’s job is to hold the sender to this promise.

The while loop you’ve constructed is the perfect embodiment of this contract. Let’s review its structure and confirm its role as the sole arbiter of when the download is complete.

The Elegance of the while Loop Condition

The core of the termination logic lies in the simple, declarative condition you established a few tasks ago: while bytes_received < metadata.size. This line acts as the gatekeeper for every single iteration of the loop.

Let’s trace the lifecycle:

  1. Check: Before the loop’s body runs, Rust checks if bytes_received (initially 0) is less than metadata.size. If it is, the loop proceeds.
  2. Execute: A chunk of data is read from the network and written to the file.
  3. Update: The bytes_received counter is incremented by the number of bytes just processed.
  4. Repeat: Execution jumps back to step 1, and the condition is checked again with the new, larger value of bytes_received.

This cycle continues, with bytes_received steadily climbing towards metadata.size. Eventually, during the final iteration, the counter is incremented to a value that is exactly equal to metadata.size.

The next time the condition in step 1 is checked, bytes_received < metadata.size will evaluate to false. At this moment, the loop’s contract has been fulfilled, and it terminates gracefully and naturally. Execution continues to the first line of code after the loop, signifying a successful download.

The Final start_receiver Logic

Here is the complete, final version of the start_receiver function. It showcases how all the pieces you’ve built—the connection, the metadata, the file, the buffer, the counter, and the loop—work together in harmony.

// src/receiver.rs

use crate::FileMetadata;
use std::fs::File;
use std::io::{Read, Write};
use std::net::TcpStream;

pub fn start_receiver(server_address: &str) {
    // 1. Establish a connection to the sender.
    println!("-> Attempting to connect to sender at: {}", server_address);
    let mut stream = TcpStream::connect(server_address)
        .expect("Failed to connect to the sender");
    println!("-> Successfully connected to sender.");

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

    // 3. Create the destination file and initialize the progress counter.
    let mut file = File::create(&metadata.filename)
        .expect("Failed to create file on local disk");
    let mut bytes_received: u64 = 0;
    println!("-> Created file '{}'. Ready to receive {} bytes.", metadata.filename, metadata.size);

    // 4. Create the buffer and start the main download loop.
    let mut buffer = [0u8; 8192];
    println!("\n-> Starting file download...");

    // --- HIGHLIGHT START: The Termination Logic in Action ---

    // This `while` loop is the core of the receiver. It continues to execute
    // as long as the number of bytes we've received is less than the total
    // file size promised by the sender in the metadata.
    while bytes_received < metadata.size {
        let bytes_read = match stream.read(&mut buffer) {
            Ok(0) => {
                // Sender closed the connection before sending all the data.
                println!("-> Connection closed by sender unexpectedly.");
                break;
            }
            Ok(n) => {
                // We received `n` bytes. Write them to the file.
                file.write_all(&buffer[0..n]).expect("Failed to write chunk to file");
                n // This `n` is assigned to `bytes_read`.
            }
            Err(ref e) if e.kind() == std::io::ErrorKind::Interrupted => {
                // A transient error, retry the read.
                continue;
            }
            Err(e) => {
                panic!("Error reading from stream: {}", e);
            }
        };

        // This is the crucial step that makes progress. By incrementing our counter,
        // we ensure that the `while` loop's condition will eventually become `false`,
        // allowing the loop to terminate correctly.
        bytes_received += bytes_read as u64;
    }
    // --- HIGHLIGHT END ---

    // This line is only reached after the loop has terminated.
    println!("\n-> Download complete. Received a total of {} bytes.", bytes_received);

    // We should also check if we received the expected amount of data.
    if bytes_received == metadata.size {
        println!("-> File transfer successful!");
    } else {
        eprintln!("-> Error: File transfer incomplete. Expected {} bytes but received {}.", metadata.size, bytes_received);
    }
}

Congratulations! You have officially implemented the entire core logic for the receiver. Your application can now connect to a sender, understand the incoming file’s properties, create a destination file, and reliably download its content, chunk by chunk, stopping at the perfect moment.

What’s Next?

You have now built two powerful, independent pieces of logic: a fully functional sender and a fully functional receiver. They are the heart and lungs of your application. The next major step is to connect them to the brain: the command-line interface you built in the very first step. You will modify main.rs to call start_sender or start_receiver based on the subcommand the user provides, truly bringing your entire application to life.

Further Reading