Données binaires (fd 4)

fd 4 transporte des charges utiles binaires brutes auxquelles les lignes de métadonnées de fd 3 font référence via byteLength. Il n’y a aucun framing sur fd 4 lui-même — le côté métadonnées indique au parseur exactement combien d’octets lire.

Ordre de lecture

Si fd 3 émet ces lignes dans cet ordre :

{"id":"a","type":"image","format":"png","byteLength":4096}
{"id":"b","type":"image","format":"jpeg","byteLength":12000}

…le parseur lit exactement 4 096 octets sur fd 4, les associe à id: "a", puis lit 12 000 octets pour id: "b". Les deux flux sont séquencés.

Canaux de données nommés

La plupart des cas d’usage utilisent le canal par défaut (fd 4, alias "data"). Pour des flux plus élaborés, vous pouvez déclarer des canaux nommés supplémentaires dans HYPERTERM_CHANNELS et les référencer depuis les métadonnées :

{"id":"raw-vid","type":"canvas2d","dataChannel":"video","byteLength":65536}

Le canal par défaut est "data" (fd 4). Les canaux personnalisés ne sont pas exposés par les bibliothèques client par défaut — ils sont destinés aux intégrations avancées qui souhaitent multiplexer des flux de données distincts (par exemple des trames vidéo et des charges utiles de contrôle).

Contre-pression

Les écritures sont bloquantes. Si τ-mux est occupé à rendre, la prochaine écriture du script sur fd 4 sera bloquée jusqu’à ce que le pipe de lecture se vide. C’est intentionnel — une E/S non bloquante risquerait une perte silencieuse de trames.

Mémoire

La charge utile binaire de chaque panneau devient un ArrayBuffer dans le moteur de rendu. Pour les images, le buffer est encapsulé dans une URL blob et affecté à un élément <img> — lorsque le panneau est effacé, l’URL est révoquée et le buffer est libéré.

Sécurité : le HTML & le SVG sont isolés

Les panneaux de type html ou svg — que le balisage arrive en inline (meta.data) ou en charge utile fd 4 — sont rendus dans une <iframe sandbox> verrouillée (pas de scripts, pas de same-origin) portant une Content-Security-Policy stricte (script-src 'none'). C’est valable sur l’application native comme sur le miroir web, afin qu’un producteur négligent ou compromis ne puisse pas exécuter de script dans la page hôte (qui, côté natif, détient tout le pont IPC de l’application). Les styles inline et les images data:/blob: sont autorisés ; les <script> et gestionnaires d’événements inline (onerror=…) ne s’exécutent jamais.

Si votre panneau doit transmettre des clics/touches à votre script, mettez interactive: true dans les métadonnées. Ce panneau est alors rendu directement (sans iframe) pour que ses événements DOM puissent être transmis — une frontière de confiance explicite, sur opt-in. À n’utiliser que pour du balisage que vous contrôlez entièrement.

Limites

Il n’y a pas de plafond strict, mais des limites pratiques :

Charge utile par panneau — quelques MiB conviennent. Des images de plusieurs centaines de MiB épuiseront la mémoire de la webview.
Débit en rafale — la contre-pression vous protège, mais émettre des trames plus vite que le moteur de rendu ne peut consommer signifie simplement que votre script bloque en attendant le moteur de rendu.