Documentation
Temps réel et datagrammes
Le temps réel, dans VIGIL-MESH, tient à une règle simple : les datagrammes passent avant les flux de service. Cette page décrit comment cette priorité est conçue et pourquoi, en direct, la latence que vous ressentez est essentiellement celle de votre réseau. Ce sont des objectifs de conception, décrits comme tels, jamais présentés comme des mesures.
Datagrammes contre flux de service
VIGIL-MESH distingue deux natures de trafic sur une même connexion. Les datagrammes portent le temps réel : voix, vidéo, télémétrie, commande d'engin. Les flux de service portent le reste : établissement de session, échanges de contrôle, transferts fiables. Les deux cohabitent, mais ils n'ont pas le même droit de passage.
Les datagrammes sont strictement prioritaires sur les flux de service. Quand une trame temps réel et un octet de flux de service se disputent le lien au même instant, c'est la trame temps réel qui part d'abord. Un flux de service saturé ne peut donc pas retarder un datagramme prêt à émettre.
Datagrammes
Le temps réel. Priorité stricte, pas de retransmission qui bloque le flux suivant, livraison au fil de l'eau.
Flux de service
Le contrôle et les transferts fiables. Utiles mais jamais prioritaires : ils cèdent le passage aux datagrammes.
Cette séparation évite la tête de ligne bloquante : un paquet de service en attente de retransmission ne fige pas les trames temps réel qui le suivent. Chaque datagramme progresse indépendamment, sans être pris en otage par la fiabilité d'un autre flux.
Objectif de conception
Nous nous fixons une cible mesurable pour l'effet du trafic de fond sur le temps réel. Elle exprime ce que l'architecture doit tenir, pas ce qu'un banc aurait déjà démontré.
Cet objectif ne chiffre aucun temps de trajet absolu : il ne dit pas « tant de millisecondes ». Il borne l'écart entre le temps réel au repos et le temps réel sous charge, ce qui est précisément ce que la priorité stricte des datagrammes est censée garantir.
Pourquoi la latence en direct est celle du réseau
Sur un chemin direct validé, VIGIL-MESH n'ajoute qu'une seule couche de chiffrement de bout en bout au trajet réseau : pas de tunnel dans un tunnel, pas de double chiffrement. Le temps réel ne fait donc pas de détour caché ; il suit le chemin le plus court validé.
La conséquence est directe : la latence que vous ressentez en direct est essentiellement celle de votre propre réseau, pas une surcouche imposée par VIGIL-MESH. La priorité des datagrammes protège cette latence du bruit des flux de service.
In English
In VIGIL-MESH, real-time traffic rides on datagrams, which are strictly prioritised over service streams: a real-time frame always leaves before a service byte contending for the same link, so a busy transfer cannot delay it. This also avoids head-of-line blocking — one stream's retransmission never freezes the datagrams that follow.
Our design target — a target, not a measurement — is that under a background transfer, p95 datagram latency stays at or below twice the idle latency.
On a validated direct path we add only one end-to-end encryption layer, so the live latency you feel is essentially your own network's; see /docs/performances for how we separate measured, demonstrated and targeted claims.