Xterm.js: Contrôle de flux à l'aide de XON / XOFF

Nous avons supprimé XON / XOFF car il ne fonctionnait pas de manière fiable dans certains scénarios. Du fond de ma tête, je me souviens que nous avions des problèmes avec le shell ZSH, qui utilisait les séquences XON / XOFF pour quelque chose de différent. Je pense que le terminal Windows a également eu des problèmes avec ces séquences.

Quoi qu'il en soit - la façon dont j'ai résolu cela (également en utilisant WebSockets - dans mon cas socket.io mais cela n'a pas d'importance) est d'établir manuellement un mécanisme de contrôle de flux sur le socket lui-même.

Ainsi, chaque fois que des données arrivent sur la socket qui doit être écrite dans xterm.js, nous augmentons un compteur, et une fois que les données ont été écrites avec succès dans xterm.js (ce qui signifie qu'elles ont été rendues par xterm.js), nous diminuons ce compteur .

Si le compteur dépasse un certain seuil, nous envoyons un message pause sur le Websocket, qui du côté serveur mettra en pause le flux pty ( terminalStream.pause() ). Une fois que nous passons en dessous de ce seuil, nous envoyons un message resume sur le Websocket, qui du côté serveur reprendra le flux pty ( terminalStream.resume() ).

Notez que les méthodes terminalStream.pause() et terminalStream.resume() sont les méthodes de flux node.js intégrées pour gérer la contre-pression. node-pty ainsi que ssh2 prennent en charge la gestion de la contre-pression via ces méthodes.

// client
const MAX_PENDING_WRITES = 5;
let pendingWrites = 0;
let paused = false;
socket.on('data', (data) => {
  pendingWrites++;
  xterm.write(data, () => {
    pendingWrites--;
    if (pendingWrites > MAX_PENDING_WRITES && !paused) {
      paused = true;
      socket.emit('pause');
      return;
    }
    if (pendingWrites <= MAX_PENDING_WRITES && paused) {
      paused = false;
      socket.emit('resume');
      return;
    }
  });
});

// server
terminalStream.on('data', (data) => socket.emit('data', data);
socket.on('data', (data) => terminalStream.write(data));
socket.on('pause', () => terminalStream.pause();
socket.on('resume', () => terminalStream.resume();

Ce mécanisme fonctionne de manière assez fiable jusqu'à présent. La commande yes n'inondera plus la connexion. Il y a toujours un délai d'environ 0,5 seconde entre CTRL+C et l'arrêt réel de la commande dans les scénarios à haut débit, mais IMO c'est correct.

J'espère que cela aide.

@tandatle Consultez également la documentation sur le contrôle de

Edit: Désolé, j'ai oublié votre remarque sur les documents. Voulez-vous expliquer ce qui n'est pas clair? Oui, la section websocket n'est qu'un stub (pas d'extrait prêt à l'emploi), car je n'ai pas quoi créer des tonnes d'extraits pour différentes bibliothèques de socket et des besoins personnalisés (c'est difficile à faire correctement avec les websockets pour des raisons de sécurité uniquement) . N'hésitez pas à ajouter un extrait de code concret, qui couvre ces aspects.

@mofux @jerch Merci pour votre aide.
Je n'utilise pas node.js en backend, mais un processus écrit en C ++, donc je devrai peut-être faire quelques investigations supplémentaires pour choisir entre utiliser XON / XOFF et implémenter la gestion de backpresure dans mon processus backend.
Merci beaucoup.