WebSockets : gardez la conversation ouverte

Ce que vous saurez faire

Distinguer transport et protocole métier, contrôler les messages reçus et prévoir le retour après une interruption. Une connexion ouverte ne suffit pas à garantir un état correct.

1. Donner un contrat aux messages

WebSocket transporte des données ; votre application leur donne un sens. Pour notre tableau de mesures fictif, choisissons un objet avec un type, une valeur et un numéro de séquence. Ce contrat doit être partagé avec le serveur.

// Exemple : nécessite votre propre serveur compatible.
const socket = new WebSocket('wss://example.com/metrics');
socket.addEventListener('message', ({ data }) => {
  if (typeof data !== 'string') return;
  try {
    const message = JSON.parse(data);
    if (
      message?.type !== 'measurement' ||
      !Number.isFinite(message.value) ||
      !Number.isSafeInteger(message.sequence)
    ) return;
    console.log(message.sequence, message.value);
  } catch {
    console.warn('Message non conforme');
  }
});

Ce code ignore les messages binaires et les objets inattendus. Il ne constitue pas un client complet. Avant un envoi, vérifiez aussi que readyState vaut WebSocket.OPEN. bufferedAmount renseigne sur les octets en attente d’envoi ; il ne prouve pas que le destinataire les a traités. L’API classique ne fournit pas de régulation automatique du flux entrant.

Référence : API WebSocket.

2. Penser la reconnexion comme un retour à la réalité

Le protocole prévoit une fermeture de connexion, mais pas la sauvegarde de vos événements métier. Une interruption impose donc une stratégie applicative. Dans notre exemple, conservons le dernier numéro reçu et demandons au serveur les événements suivants. Si son historique ne suffit plus, rechargeons un état complet.

Évitez une reconnexion immédiate en boucle. Un délai croissant avec une part aléatoire répartit les tentatives. Après une déconnexion volontaire, ne relancez pas la connexion. Chaque nouvelle socket doit également nettoyer les écouteurs et temporisateurs devenus inutiles.

3. Séparer accès et connexion

Le chiffrement wss:// protège le transport, pas les règles métier. Un canal établi n’autorise pas automatiquement l’accès à tous les salons. Le serveur doit contrôler l’identité, les abonnements et les actions sensibles, et borner les messages acceptés.

Référence : protocole WebSocket.

À vous de jouer

Le tableau a reçu la mesure 41, perd la connexion, puis reçoit la 45. Peut-il simplement afficher 45 et continuer ?

Correction commentée

Cela dépend du contrat. Si chaque mesure remplace intégralement l’état affiché, 45 peut suffire. Si les événements sont des variations à additionner, les événements manquants faussent le total. Notre protocole doit alors rejouer 42 à 44 ou fournir un nouvel état complet. Un test de coupure révèle cette différence bien mieux qu’une démonstration sur un réseau stable.