Comment partager des périphériques série sur un réseau

Oui, lorsque le port partagé est une connexion serveur en mode Raw, il permet plusieurs clients, et chaque client connecté reçoit une copie de la sortie de l’appareil. C’est idéal pour un appareil qui émet des données vers de nombreux consommateurs (un récepteur GPS, un flux de capteurs). Notez que le mode Telnet (RFC 2217) est de type pair à pair — un seul client à la fois — car le contrôle du port par session ne peut pas être partagé, donc le partage multi-client implique le mode Raw et l’abandon de la négociation à distance du débit en bauds/des signaux.

Une limite importante : de nombreux ordinateurs peuvent lire en toute sécurité un seul appareil, mais de nombreux ordinateurs écrivant des commandes vers un seul appareil, c’est dangereux. Une ligne série n’a pas d’arbitrage multi-maître, donc les commandes qui se chevauchent provenant de différents clients s’entrelacent en octets corrompus sur l’unique port physique. Diffusion vers de nombreux lecteurs, oui ; plusieurs rédacteurs non contrôlés, non — arbitrez les commandes via un seul client contrôleur si l’appareil fonctionne en mode commande/réponse.

Réponse de Nikolai Svarachevsky · Développeur principal

Non — et il vaut la peine d’être clair, car c’est une supposition courante. SEC est un transmetteur transparent d’octets, pas un convertisseur de protocole. Les octets qui entrent dans le port série ressortent inchangés par le port virtuel ; Modbus RTU reste Modbus RTU. Votre application à l’autre extrémité parle toujours exactement le protocole série du périphérique — SEC ne fait que transporter cette conversation sur le réseau.

Si vous avez réellement besoin que le tramage RTU soit reconditionné en Modbus TCP (tramage différent, pas de CRC, un en-tête de transaction TCP approprié), il s’agit d’une traduction de protocole, et il vous faut plutôt une passerelle Modbus dédiée. SEC convient lorsque les deux extrémités parlent déjà le même protocole série et que vous avez seulement besoin de le faire passer sur un réseau. « Atteindre le périphérique à distance », c’est notre rôle ; « changer ce que parle le périphérique », ce n’est pas le nôtre.

Réponse de Nikolai Svarachevsky · Développeur principal

La couche logicielle elle-même ajoute peu — généralement une faible surcharge de moins de 10 ms dans des conditions locales normales. Mais nous ne donnerons pas un chiffre universel unique, car la valeur qui compte est dominée par votre réseau, et non par le SEC : sur un LAN, la latence totale ajoutée est minimale ; sur internet ou via un VPN, l’aller-retour réseau est le véritable coût, et il peut aller de quelques millisecondes à des centaines selon la distance et la congestion.

La bande passante n’est pratiquement jamais le goulot d’étranglement — les débits de données série sont infimes par rapport à n’importe quel réseau moderne. La latence est l’élément à prendre en compte dans la conception. Si votre protocole la tolère (streaming, interrogation peu fréquente), vous ne la remarquerez jamais. S’il impose des fenêtres de réponse serrées, mesurez l’aller-retour réel sur votre trajet effectif avant de vous engager, et rappelez-vous que les contrôles de mise en mémoire tampon du SEC échangent un peu de latence supplémentaire contre un découpage plus propre lorsque vous en avez besoin.

Réponse de Bohdan Miniv · Ingénierie QA

Oui. Les paramètres de connexion de SEC incluent des contrôles de mise en paquets précisément pour cela, notamment une option « envoyer les données lorsqu’un caractère avec un code donné est reçu ». Réglez-la sur l’octet de fin de message de votre protocole (un retour chariot ou un saut de ligne pour de l’ASCII orienté ligne, par exemple) et SEC accumulera les octets entrants et les enverra au réseau comme une seule unité lorsque ce délimiteur arrivera, au lieu de transférer les octets au coup par coup.

C’est réellement utile pour préserver l’intégrité du découpage des messages sur un réseau qui, autrement, scinderait ou regrouperait un flux d’octets, et cela s’associe aux contrôles connexes — retenir pendant un certain temps, ou envoyer une fois qu’un bloc atteint une taille donnée. Le compromis à garder à l’esprit : toute règle de type « attendre jusqu’à… » ajoute par conception un peu de latence, puisque vous retenez délibérément les octets jusqu’au déclencheur. Pour la plupart des protocoles à trames, c’est exactement le comportement souhaité.

Réponse de Nikolai Svarachevsky · Développeur principal

L’exigence minimale est simple : installez SEC sur la machine qui possède le port série que vous souhaitez partager. Ce côté publie le port sur le réseau, et l’autre extrémité peut communiquer avec lui comme avec une connexion réseau ordinaire — si votre application distante peut elle-même ouvrir un socket TCP brut, elle se connecte directement et n’a pas besoin que SEC soit installé. Cette extrémité distante peut même être un périphérique matériel (un terminal ou un serveur de console) qui parle déjà le protocole sur le réseau.

Vous n’avez besoin de SEC aux deux extrémités que lorsque les deux extrémités doivent présenter un véritable port COM à leur logiciel local. Dans ce cas, chaque nœud exécute SEC pour exposer le port localement et SEC transporte les données entre eux. En termes simples : installez SEC sur chaque nœud où une application s’attend à voir un port COM, et ne l’installez pas là où le logiciel parle déjà directement en TCP — ou lorsque l’extrémité est un périphérique matériel.

Réponse de Nikolai Svarachevsky · Développeur principal