Comment capturer des paquets réseau en Rust avec Tauri

Introduction

Pour comprendre comment capturer des paquets réseau en Rust dans une application Tauri, je vais te montrer mon cheminement complet — depuis l’idée d’un simple compteur jusqu’à une sonde réseau robuste.

Ce n’est pas juste un tutoriel. C’est un journal technique, une sorte de carnet de bord dans lequel chaque problème m’a permis d’apprendre quelque chose de nouveau : sur les threads, la gestion d’état, la communication UI/backend, ou les particularités de la crate pcap.

🛠 Étape 1 – Démarrer avec un compteur dans un thread

Avant de capturer des paquets réseau, je veux maîtriser le principe d’un thread Rust contrôlé par Tauri. Voici une fonction très simple qui lance un thread de comptage :

use tauri::command;
use std::time::Duration;
use std::thread;

/// Cette commande démarre un thread qui compte chaque seconde.
#[command(async)]
pub fn start_counter() {
    thread::spawn(move || {
        let mut count = 0;
        loop {
            count += 1;
            println!("Compteur: {}", count);
            thread::sleep(Duration::from_secs(1));
        }
    });

    println!("Thread de comptage lancé !");
}

🧩 Étape 2 – Ajouter le contrôle `start` / `stop` du thread

🧠 Objectif

Créer un compteur Rust contrôlable à travers des commandes Tauri :

✅ Démarrer le thread avec start_counter
✅ L’arrêter proprement avec stop_counter

📦 Architecture du code

🧱 Backend (Rust)

Tu introduis :

une structure globale AppState partagée dans un Arc<Mutex<...>>
un CounterHandle qui possède un stop_flag partagé entre thread et handler
deux commandes Tauri :
- start_counter qui vérifie qu’il n’y a pas de thread déjà actif
- stop_counter qui signale au thread qu’il doit s’arrêter

💡 Extrait clé

pub fn stop(&self) {
    self.stop_flag.store(true, Ordering::Relaxed);
}

➡️ Cela coupe la boucle du thread dans while !stop_flag.load(...).

🔂 Boucle de capture avec interruption

thread::spawn(move || {
    let mut count = 0;
    while !stop_flag.load(Ordering::Relaxed) {
        count += 1;
        println!("Compteur: {}", count);
        thread::sleep(Duration::from_secs(1));
    }
    println!("Thread terminé.");
});

🧠 Pourquoi `Arc<AtomicBool>` ?

Arc permet de partager la donnée entre le thread et l’extérieur (via le CounterHandle)
AtomicBool évite les verrous pour un flag booléen simple
Ordering::Relaxed est suffisant ici : pas besoin de synchronisation complexe

🔗 Intégration avec Tauri

Commande `start_counter`

if app.counter.is_some() {
    println!("Déjà en cours.");
    return;
}

➡️ Tu empêches le démarrage de plusieurs threads (bonne pratique).

Commande `stop_counter`

if let Some(counter) = app.counter.take() {
    counter.stop();
}

➡️ Tu “consommes” le compteur en le retirant de l’état global (take()).

📊 Diagramme de séquence

🧠 Résultat de cette étape

✅ Tu contrôles le lancement et l’arrêt du thread à volonté.
✅ Tu gères un seul thread actif à la fois.
✅ Tu poses les bases pour les étapes suivantes : pause, resume, puis pcap.

📁 Étape 3 – Ajout de `pause` et `resume` avec `Condvar`

🌟 Objectif

Contrôler l’état d’exécution d’un thread via une pause réversible, sans tuer le thread, pour préparer les futurs cas d’usage comme la capture réseau avec interruption temporaire.

📄 Description technique

Tu introduis ici un mécanisme de pause/reprise avec :

Un Arc<(Mutex<bool>, Condvar)> appelé pause_flag
Le thread se met en attente (Condvar::wait) tant que pause_flag == true
Une fonction pause() qui met true
Une fonction resume() qui met false et notify_all()

🛠️ Architecture de la boucle

while !stop_flag.load(Ordering::Relaxed) {
    let (lock, cvar) = &*pause_flag;
    let mut paused = lock.lock().unwrap();

    if *paused {
        println!("[DEBUG] Le thread est en pause, en attente...");
    }

    while *paused {
        paused = cvar.wait(paused).unwrap();
        println!("[DEBUG] Signal de reprise reçu");
    }

    drop(paused);

    count += 1;
    println!("Compteur: {}", count);
    thread::sleep(Duration::from_secs(1));
}

🔊 Fonctionnement en flowchart

🔗 Pourquoi `Condvar` ici ?

Permet de bloquer le thread efficacement (pas de spin/sleep inutile)
Attente conditionnelle, sans gaspiller de CPU
Synchronisation typique dans les threads bloquants

📊 Bilan de l’étape

Fonction	Rôle
`start()`	Lance le thread si pas déjà actif
`stop()`	Coupe la boucle et réveille s’il était en pause
`pause()`	Met le thread en attente
`resume()`	Réveille le thread bloqué

📉 Limites observées

Si on ne veut pas bloquer le thread (ex : avec pcap en mode nonblock), ce modèle est trop complexe
Risques de deadlock ou de signal perdu si mal utilisé

✅ C’est pour cette raison qu’à l’étape suivante, tu as décidé d’abandonner Condvar au profit d’un simple AtomicBool.

📊 Etape 4 — Intégration de `pcap` avec pause/reprise

🚀 Objectif

Passer du compteur simple à une vraie capture de paquets réseau via la crate pcap, tout en gardant la possibilité de mettre la capture en pause ou de l’arrêter grâce à des flags de contrôle partagés avec le thread de capture.

🔧 Code clé : struct `CaptureHandle`

pub struct CaptureHandle {
    stop_flag: Arc<AtomicBool>,
    pause_flag: Arc<(Mutex<bool>, Condvar)>,
}

stop_flag : permet d’interrompre la boucle de capture
pause_flag : permet de suspendre temporairement le thread sans le tuer

🪨 Logique de la boucle de capture

while !stop_flag.load(Ordering::Relaxed) {
    // pause si activée
    let (lock, cvar) = &*pause_flag;
    let mut paused = lock.lock().unwrap();
    while *paused {
        println!("[DEBUG] Pause active, en attente...");
        paused = cvar.wait(paused).unwrap();
        println!("[DEBUG] Reprise de la capture");
    }
    drop(paused);

    match cap.next_packet() {
        Ok(packet) => println!("[CAPTURE] paquet de {} octets", packet.data.len()),
        Err(e) => println!("[ERROR] Erreur de capture : {:?}", e),
    }

    let stats = cap.stats().unwrap();
    println!(
        "Received: {}, dropped: {}, if_dropped: {}",
        stats.received, stats.dropped, stats.if_dropped
    );
}

🛀 Flowchart

⚠️ Limites identifiées

Condvar peut bloquer le thread alors que pcap supporte le mode non-bloquant
La gestion des erreurs devient plus complexe si des signaux sont manqués (ex : notify_all() raté)
Ce modèle est plus adapté à des processus CPU-bloquants que à de la capture IO non-bloquante

📊 Conclusion

Cette étape permet de valider la chaîne :

Contrôle de thread avec pause/reprise sur une vraie capture réseau
Intégration du pcap::Capture dans un thread
Premiers tests de robustesse via stop() et resume()

❌ Mais les limites du modèle avec Condvar se font sentir.

🚧 Prochaine étape : remplacer Condvar par un simple AtomicBool pour un modèle plus adapté au non-blocking.

🚀 Etape 5 — Remplacement de `Condvar` par `AtomicBool`

🔄 Objectif

Remplacer la pause/reprise basée sur Condvar par une solution plus simple et plus robuste avec un AtomicBool, mieux adapté à la capture réseau en mode non-bloquant (setnonblock()).

🔧 Architecture du `CaptureHandle`

pub struct CaptureHandle {
    stop_flag: Arc<AtomicBool>,
    pause_flag: Arc<AtomicBool>,
}

stop_flag : indique au thread de s’arrêter
pause_flag : contrôle le gel temporaire de la capture

⚖️ Pourquoi abandonner `Condvar`

`Condvar`	`AtomicBool`
Bloque le thread	Polling actif mais contrôlé
Difficile à synchroniser avec `pcap`	Compatible avec `setnonblock()`
Risques de signal perdu	Simplicité, aucun verrou requis

✅ Comportement de la boucle de capture

if pause_flag.load(Ordering::Relaxed) {
    thread::sleep(Duration::from_millis(100));
    continue;
}

Cela permet au thread de rester réactif et non-bloquant tout en réduisant la charge CPU.

📊 Affichage intelligent des stats

Un cache last_stats permet d’éviter d’afficher les statistiques en boucle :

if last_stats != Some(current) {
    println!("[STATS] Received: {}, dropped: {}, if_dropped: {}", ...);
    last_stats = Some(current);
}

🛀 Flowchart

🔍 Ce qu’on gagne

Simplicité de la logique de pause
Plus de compatibilité avec les captures pcap non bloquantes
Moins de complexité et de risque de bug

🎉 Tu as maintenant :

Un thread de capture contrôlable en start, stop, pause, resume
Une capture réseau performante et robuste
Un code propre, testable et cross-plateforme

Prochaine étape : 📊 **Séparer complètement la capture des paquets et leur traitement **

🧠 Étape 6 — Thread séparé pour traitement + stats

🎯 Objectif

Séparer complètement la capture des paquets et leur traitement (parse, stats, etc.) dans deux threads indépendants.

📦 Architecture

Un CaptureHandle avec deux flags : stop_flag et pause_flag
Un thread de capture qui lit les paquets via pcap et les envoie dans un canal
Un thread de traitement qui lit depuis ce canal, décode les paquets, met à jour les compteurs et affiche les stats
Un enum CaptureMessage pour transmettre soit un paquet, soit les statistiques pcap::Stat

📄 Enum pour messages

enum CaptureMessage {
    Packet(PacketOwned),
    Stats(Stat),
}

📄 Thread de capture

thread::spawn(move || {
    // boucle de capture pcap
    match cap.next_packet() {
        Ok(packet) => {
            let owned = codec.decode(packet);
            tx.send(CaptureMessage::Packet(owned)).unwrap();
        },
        // ...
    }
    // stats périodiques
    if let Ok(stats) = cap.stats() {
        tx.send(CaptureMessage::Stats(stats)).unwrap();
    }
});

📄 Thread de traitement

thread::spawn(move || {
    while let Ok(msg) = rx.recv() {
        match msg {
            CaptureMessage::Packet(pkt) => {
                println!("Packet len={} ts={}.{:06}", pkt.data.len(), pkt.header.ts.tv_sec, pkt.header.ts.tv_usec);
                // traitement, analyse...
            }
            CaptureMessage::Stats(stats) => {
                println!("[STATS] received={}, dropped={}, if_dropped={}...", stats.received, stats.dropped, stats.if_dropped);
            }
        }
    }
});

📊 Flowchart – Éviter les paquets perdus en déléguant le traitement

✅ Ce que cette étape apporte

Gain	Détail
📦 Séparation des responsabilités	capture vs traitement
🚀 Meilleure performance	capture non bloquée, traitement découplé
🧱 Meilleure architecture	threads indépendants, plus testables

🔜 Prochaines étapes d’optimisation

🔄 Utiliser crossbeam::bounded() pour remplacer mpsc::sync_channel

🧱 Étape 7 — Transition de `mpsc` vers `crossbeam::channel`

Pourquoi changer ?

std::sync::mpsc est simple, mais limité :
- pas de fonction len()
- performances moindres en haute fréquence
- moins de flexibilité sur la stratégie de saturation

Avantages concrets de `crossbeam::channel`

Fonctionnalité	`mpsc`	`crossbeam::channel`
Taille bornée (`bounded`)	✅ (avec `sync_channel`)	✅
`try_send()`	❌	✅
`len()` pour monitoring	❌	✅
Performances	Moyennes	Excellentes
Sécurité thread	Bonne	Très bonne

Code modifié

let (tx, rx) = crossbeam::channel::bounded::<CaptureMessage>(10_000);

Et dans le thread :

if let Err(err) = tx.try_send(CaptureMessage::Packet(owned)) {
    error!("[TX] Packet dropped (buffer plein) : {}", err);
}

🚦 Scénarios de saturation

Le canal est plein car le thread de traitement est trop lent
Grâce à try_send(), on peut logguer ou ignorer les paquets plutôt que bloquer
Avec rx.len() on peut détecter la saturation imminente et agir proactivement (pause, discard, alertes…)

📄 Étape bonus : mise en place d’un backoff exponentiel

Quand pcap n’a pas de paquet à lire, on dort un tout petit peu — mais progressivement plus longtemps, jusqu’à 10 ms max.

let mut backoff = 1; // µs
backoff = (backoff * 2).min(10_000);

Cela réduit la charge CPU tout en gardant une réactivité raisonnable.

📄 Étape bonus : monitoring du canal

On mesure rx.len() dans le thread de traitement, et on déclenche un warn! si le canal est proche de la saturation :

if rx.len() > 9000 {
    warn!("[BACKPRESSURE] Canal presque plein !");
}

Cela permet de :

Visualiser en prod si le thread de capture produit trop vite
Éventuellement adapter dynamiquement la stratégie (discard, buffer, etc.)

📄 Thread de traitement

thread::spawn(move || {
    while let Ok(msg) = rx.recv() {
        match msg {
            CaptureMessage::Packet(pkt) => { /* traitement */ },
            CaptureMessage::Stats(stats) => { /* stats */ },
        }

        if rx.len() > 9000 {
            warn!("Canal presque saturé !");
        }
    }
});

✅ Ce que cette étape apporte

Gain	Détail
📦 Séparation des responsabilités	capture vs traitement
🚀 Meilleure performance	capture non bloquée, traitement découplé
🧱 Meilleure architecture	threads indépendants, plus testables
⚠️ Détection proactive	backpressure visible dans les logs

📊 Flowchart – Éviter les paquets perdus en déléguant le traitement

🔜 Prochaines étapes d’optimisation

♻️ Réutiliser les buffers (Vec<u8> pré-alloués)
🧠 Implémenter un pool d’objets pour éviter les reallocations fréquentes

Tu es maintenant prêt à benchmark chaque taille de buffer, et visualiser en direct l’impact sur la perf 🧪🚀

Comment capturer des paquets réseau en Rust avec Tauri

Introduction

🛠 Étape 1 – Démarrer avec un compteur dans un thread

🧩 Étape 2 – Ajouter le contrôle start / stop du thread

🧠 Objectif

📦 Architecture du code

🧱 Backend (Rust)

💡 Extrait clé

🔂 Boucle de capture avec interruption

🧠 Pourquoi Arc<AtomicBool> ?

🔗 Intégration avec Tauri

Commande start_counter

Commande stop_counter

📊 Diagramme de séquence

🧠 Résultat de cette étape

📁 Étape 3 – Ajout de pause et resume avec Condvar

🌟 Objectif

📄 Description technique

🛠️ Architecture de la boucle

🔊 Fonctionnement en flowchart

🔗 Pourquoi Condvar ici ?

📊 Bilan de l’étape

📉 Limites observées

📊 Etape 4 — Intégration de pcap avec pause/reprise

🚀 Objectif

🔧 Code clé : struct CaptureHandle

🪨 Logique de la boucle de capture

🛀 Flowchart

⚠️ Limites identifiées

📊 Conclusion

🚀 Etape 5 — Remplacement de Condvar par AtomicBool

🔄 Objectif

🔧 Architecture du CaptureHandle

⚖️ Pourquoi abandonner Condvar

✅ Comportement de la boucle de capture

📊 Affichage intelligent des stats

🛀 Flowchart

🔍 Ce qu’on gagne

🎉 Tu as maintenant :

🧠 Étape 6 — Thread séparé pour traitement + stats

🎯 Objectif

📦 Architecture

📄 Enum pour messages

📄 Thread de capture

📄 Thread de traitement

✅ Ce que cette étape apporte

🔜 Prochaines étapes d’optimisation

🧱 Étape 7 — Transition de mpsc vers crossbeam::channel

Pourquoi changer ?

Avantages concrets de crossbeam::channel

Code modifié

🚦 Scénarios de saturation

📄 Étape bonus : mise en place d’un backoff exponentiel

📄 Étape bonus : monitoring du canal

📄 Thread de traitement

✅ Ce que cette étape apporte

📊 Flowchart – Éviter les paquets perdus en déléguant le traitement

🔜 Prochaines étapes d’optimisation

🧩 Étape 2 – Ajouter le contrôle `start` / `stop` du thread

🧠 Pourquoi `Arc<AtomicBool>` ?

Commande `start_counter`

Commande `stop_counter`

📁 Étape 3 – Ajout de `pause` et `resume` avec `Condvar`

🔗 Pourquoi `Condvar` ici ?

📊 Etape 4 — Intégration de `pcap` avec pause/reprise

🔧 Code clé : struct `CaptureHandle`

🚀 Etape 5 — Remplacement de `Condvar` par `AtomicBool`

🔧 Architecture du `CaptureHandle`

⚖️ Pourquoi abandonner `Condvar`

🧱 Étape 7 — Transition de `mpsc` vers `crossbeam::channel`

Avantages concrets de `crossbeam::channel`