Émulation Serveur Minitel sur le web - 2

Déterrage de sujet (lelex64734 : Émulation Serveur Minitel sur le web)

… J’avais dit que ce soir, je ferais de la doc … je vais en faire un peu ici.

Ce qui est en apparence simple ne l’est pas totalement en réalité.

  • Aujourd’hui, l’émulateur WebSockets le plus simple est celui de Zigazou, extrait de MiEdit, il est disponible sur GitHub. Il doit s’installer sur un site Web et être paramétré pour pointer vers un serveur WebSocket donné.

  • Il est aussi possible de reprendre le code de CQUEST ou de JHR ou de JCM qui sont des versions légèrement modifiées.

  • Cet émulateur n’est pas sans défauts, son grand mérite étant d’être le seul à exister pour WS (*) et de fonctionner plutôt globalement bien (il me semble que SXPERT avait aussi fait un émulateur en JavaScript mais je ne me souviens pas s’il supportait WebSockets)

Ce que j’aurais à reprocher à cet émulateur tel qu’il est aujourd’hui

  • Ne prévoit pas la touche Connexion/Fin (aucun code renvoyé au serveur - la modification est toutefois facile)
  • Ne supporte pas l’ANSI ni le 80 colonnes ni la photo
  • Ne supporte pas les données binaires (n’accepte que l’Unicode, sinon, n’affiche rien)
  • Ne permet pas l’accès aux serveurs purement « telnet » (ex : EDTA - je ne sais s’il en existe encore d’autres)

Là ou ca se complique, c’est que chaque serveur (CQUEST/JHR/JCM) a choisi sa propre implémentation, et hormis l’examen du code JavaScript du serveur, impossible de prédire comment se connecter en WS à tel ou tel serveur. Exemples :

  • Hacker/JHR ne supporte pas le ping/pong mais reconnait le code « Connexion/Fin »
  • 3611/3615co.de/CQUEST accepte le ping/pong mais ignore le code « Connexion/Fin »
  • Teaser/JCM accepte le ping/pong et reconnait le code « Connexion/Fin » mais nécessite de déclarer le sous-protocole ‹ TTY ›
  • SM et Eureka ne répondant malheureusement plus [sait-on ce qu’ils sont devenus ?] je n’ai pas de détail les concernant, mais je m’attendrais à tous les bonheurs concernant leur mode de connexion.

(*) cette situation m’agaçant quelque peu, je suis en train de travailler sur plusieurs aspects qui sont plutôt très bien avancés :

  • Une passerelle Telnet+WebSockets=>WebSockets. Ceci permet d’utiliser les anciennes émulations type iTimtel ou HyperTerminal - J’ai testé avec succès lors de la dernière réunion Hacker mais je ne peux pas vraiment rendre cette passerelle publique dès aujourd’hui étant donné que Hacker a fixé une limite à 2 connexions par @IP… Je publierai le code Python sur GitHub et prévois une future version Telnet+WebSockets=>WebSockets+Telnet afin de faciliter l’accès à EDTA
  • Un moteur de serveur multi-voies modulaire (en Python aussi) et qui sera aussi publié sur GitHub lorsque j’aurai rédigé la documentation et finalisé [95% terminé] les quelques bricoles en attente.
  • Un Serial2WebSocket, équivalent à WebSocket2Minitel mais plus sophistiqué. Il permet d’utiliser n’importe quel port série (incluant RFC2217), est capable de sélectionner un serveur dans la liste des (rares) serveurs opérationnels et est utilisable soit directement avec un Minitel (comme WebSocket2Minitel) soit avec un modem Hayes (ce qui permet l’utilisation de tout équipement d’époque [Minitels sans prise péri-informatique, ordinausores]) -

Je peux imaginer de l’adapter pour qu’il puisse recevoir des appels [ATD vs ATA] mais il faudra ajouter des bidouilles hardwares pour la détection de sonnerie de la machine qui sera derrière.

A propos de l’émulateur de zigazou et des différentes implémentations…

Zigazou a initialement développé un éditeur vidéotex, c’est en voyant comment celui-ci décodait un flux vidéotex et l’affichait correctement que je lui ai suggéré d’en faire un émulateur.
C’est lui qui a choisit d’utiliser les websocket, ce qui était le plus simple pour un usage depuis un navigateur.

La partie protocole comme la gestion du connexion/fin est largement manquante y compris la partie écho local ou distant.

Je pense que j’ai fait la première implémentation en tant que service en ligne avec le 3611.re et 3615co.de et pour l’écho je l’ai géré directement dans mon code python.

Ensuite @jhr a tranformé le code des 90s de HACKER pour qu’il fonctionne avec cet émulateur, puis a implémenté son PAVI et géré l’écho à ce niveau. Il est parti aussi d’un code de l’émulateur qui avait évolué entre temps… je n’ai pas remis à jour ce code depuis longtemps de mon côté.

Voilà pourquoi on a des implémentations un peu différentes, même si on n’a pas vraiment touché au code de l’émulateur lui-même. J’avais juste ajouté un mapping des touches de fonction : flêches haut/bas/gauche/droite pour suite/retour/sommaire/guide comme c’était l’usage dans pas mal d’émulateurs anciens.

Il faudrait qu’on harmonise tout ça.

Merci à toi pour ces précisions « historiques » - le responsable de la gestion de l’écho et la gestion du protocole sont aussi deux bonnes questions si l’on souhaite « arriver à quelque chose de cohérent », unifier les méthodes de connexion. En toute logique :

  • Le protocole doit être géré par le terminal (l’émulateur)
    ==> MiEdit (et la majorité des émulateurs) : Point de protocole
    ==> Vrai terminal : Protocole il y a
    ==> En conséquence, impossible d’obtenir un comportement exactement similaire dans les 3 cas possibles (émulateur, terminal en local, terminal connecté), le serveur présumant de l’état du terminal et le terminal ayant un comportement différent en mode connecté ou non
  • L’écho doit s’effectuer au niveau du PAVI
    ==> Il n’y a plus de PAVI depuis 2012 … Comme la fonction d’écho est pourtant bien nécessaire, il est logique/inévitable (comme dans une optique RTC) de la reporter au niveau du serveur. C’est ce que « tout le monde » est contraint de faire.
    ==> Hacker est un cas particulier - il intègre son propre PAVI, ce qui est absolument génial car il fonctionne vraiment bien (en V23 uniquement mais c’est l’essentiel), et il peut indistinctement prendre les appels VoIP ou internet. C ‹ est la « bonne » solution pour mettre en ligne des serveurs multi-voies modernes, mais, malheureusement, JHR ne semble pas prêt soit à publier les détails de mise en oeuvre (et Asterix est complexe), soit à l’ouvrir au public et permettre une redirection vers les autres serveurs WS. La mise en oeuvre d’une sorte d › « émulateur de PAVI » [un peu comme 3615co.de mais en vrai] me paraît indispensable afin de refléter ce qui était l’ergonomie de l’époque (appel d’un numéro unique, changement de service sans déconnexion)
    ==> Les « RTC » - doivent gérer leur propre écho, et leur propre accès VoIP à la qualité aléatoire. Il ne semble pas exister aujourd’hui de solution permettant de relier directement un serveur Minitel « légacy » en WS ou en telnet [je ne sais pas si un besoin existe mais potentiellement …]. Deux approches sont néanmoins possibles :
  1. Réaliser un émulateur de protocole Minitel qui se fait passer pour un M2, à l’image de « TelnetBBS » qui simule un modem Hayes
  2. Utiliser un modem (ou un minitel) en local associé à un simulateur de ligne téléphonique (solution que j’utilise pour connecter un Minitel sans prise péri-info en WS) mais qui nécessite un minimum hardware adapté pour la détection de sonnerie.