Graphe des messages du chat

Qui émet quoi, qui reçoit quoi, ce qui traverse le canal. Ce graphe est généré à l'ouverture de la page à partir des emits et receives des composants réels et du CHANNEL du catalogue : il ne peut pas diverger du code.

Scénarios commentés

Connexion

1. Le socket s'ouvre ; le canal client envoie handshake_request. Le serveur vérifie la compatibilité, crée une session, répond un jeton. Le canal serveur publie connection_event { connected } avec id et session.
2. gestion_connexion rattache la session : session.data.connectes (tableau partagé) et session.allowMessage (deny sauf accès et déconnexion).
3. L'utilisateur valide le formulaire : ecran_connexion publie acces_demande { ref, pseudo, mot_de_passe }. Broker client, canal, réseau, canal serveur (admis : pas encore de pseudo mais acces_demande est dans la liste blanche), broker serveur.
4. gestion_connexion crée ou vérifie l'utilisateur, écrit session.data.pseudo, publie acces_reponse { ref, accord } ciblé par id, puis presence_changee ciblé sur tous les connectés.
5. gestion_messages reçoit aussi acces_reponse (livraison locale au serveur) et sert l'historique : message_poste { historique }, ciblé.
6. Côté client, ecran_connexion se masque, ecran_fil s'affiche, peint la présence puis l'historique.

Envoi d'un message

1. ecran_fil publie message_demande { ref, texte }. Le broker client valide le pattern du ref et la longueur du texte.
2. Le canal serveur pose id/session, consulte allowMessage : le pseudo est en session, admis.
3. gestion_messages vérifie que la session figure dans les connectés, ignore un ref déjà enregistré (renvoi après coupure), enregistre, publie message_poste { message } ciblé sur tous les connectés, et efface la mention d'écriture.
4. Chaque ecran_fil ajoute la ligne, sans doublon grâce au ref.

Mention « écrit… »

1. Au premier caractère, ecran_fil publie presence_signalee { ecrit: true }, puis au plus une fois par seconde tant qu'on tape ; { ecrit: false } si le champ est vidé.
2. gestion_messages met à jour le connecté, arme une minuterie de 3 secondes, et diffuse presence_changee si l'état a changé. À l'expiration ou à l'envoi, il remet ecrit à faux et rediffuse.

Déconnexion volontaire

1. /quit : ecran_fil publie deconnexion_demande { ref } et se remet à zéro. ecran_connexion, abonné au même message, repasse à l'état vierge : une réaction locale à un message pourtant destiné au serveur.
2. Serveur : gestion_connexion efface le pseudo de la session (la porte se referme), retire la session des connectés, diffuse la présence aux autres.

Coupure et expiration de session

1. Socket fermé : le canal serveur publie connection_event { disconnected } ; gestion_connexion retire la session de la présence. La session survit pendant le TTL.
2. Le client revient avec son jeton (reconnexion automatique, ou rechargement de page dans le TTL) : resumed. gestion_connexion rattache la session, mais le pseudo a été effacé : l'utilisateur doit se réidentifier. C'est un choix du chat, pas du framework.
3. TTL écoulé sans retour : expired, dernière livraison où la session est lisible, puis destruction.

Dans la démo, le bouton « couper le lien » rejoue la coupure et l'expiration (TTL réduit à 8 secondes).