Transfert de données série vers le cloud

Oui, mais avec une vraie réserve qu’il faut prendre en compte dans la conception. Un port COM physique est ouvert de manière exclusive — un seul processus à la fois — donc une application locale et le cloud ne peuvent pas tous deux utiliser directement le même port réel. Le modèle viable est une paire de ports virtuels sur la machine locale : l’application locale communique avec un port virtuel, SEC fait le pont vers le port réel, et la connexion cloud partage ces mêmes données relayées.

L’avertissement honnête : une fois qu’une application locale et une application cloud sont toutes deux connectées à un même appareil, leur trafic peut se mélanger. Les données entrantes depuis l’appareil sont diffusées vers les deux consommateurs (ce qui convient pour la lecture seule), mais si les deux côtés envoient des commandes, ces commandes s’entrelacent sur l’unique UART physique et se corrompent mutuellement. Donc, « local et cloud en même temps » est sûr pour une lecture partagée ; pour commander l’appareil, assurez-vous qu’un seul côté écrit à la fois.

Réponse de Nikolai Svarachevsky · Développeur principal

Oui — c’est une topologie en fan-in et elle fonctionne bien. Sur la machine cloud, vous créez un port COM virtuel par source, chacun alimenté par une connexion client entrante depuis son site respectif (ou par des serveurs sur chaque site auxquels le cloud se connecte en sortie — les types de connexion sont interchangeables). Votre application cloud voit alors un port COM distinct et propre pour chaque appareil distant.

La règle de conception qui permet de garder cela cohérent : attribuer à chaque source son propre port virtuel plutôt que de fusionner plusieurs appareils dans un seul port. Si vous faites passer plusieurs appareils par un seul port, leurs octets arrivent entremêlés sans aucun moyen de savoir lequel provient de quel appareil. Un port par appareil distant — et n’oubliez pas que la liaison de chaque site a sa propre latence Internet, donc dimensionnez les délais d’attente par source, et non selon une hypothèse unique.

Réponse de Nikolai Svarachevsky · Développeur principal

Le débit n’est presque jamais affecté d’une manière que vous remarqueriez, car les débits de données série sont minuscules par rapport à la bande passante du réseau — même une liaison série rapide n’est qu’un filet d’eau à côté d’une connexion internet normale, donc SEC n’est pas limité par la bande passante. Ce que SEC et le réseau ajoutent, c’est la latence, et non un plafond de débit : une faible surcharge logicielle plus le temps d’aller-retour du trajet vers le cloud.

Pour un transfert continu ou en masse, cette latence est un délai ponctuel du pipeline et le débit effectif reste élevé. Là où elle se manifeste, c’est dans un trafic bavard de type requête/réponse, où chaque échange paie l’aller-retour et le débit effectif baisse même si la bande passante brute est ample. Si c’est votre cas sur un long trajet vers le cloud, réduisez le nombre d’allers-retours (regroupez les requêtes, gardez un poller local à l’appareil) plutôt que de vous attendre à ce que SEC accélère la liaison.

Réponse de Bohdan Miniv · Ingénierie QA

L’état des lignes de signal est pris en charge lorsque vous utilisez le mode Telnet (RFC 2217) : les changements RTS/DTR de l’application distante sont transmis et appliqués au port physique, et les états de ligne comme CTS/DSR/DCD sont renvoyés. En mode Raw, rien de tout cela n’est pris en charge — Raw ne transporte que les données. Donc, pour le contrôle des signaux, utilisez le mode Telnet.

La vraie limite est le timing, pas la capacité. RFC 2217 transporte les changements des lignes de contrôle dans la bande et de manière faiblement synchronisée avec le flux de données, donc sur une liaison cloud avec mise en mémoire tampon et latence internet, le moment exact où une ligne change par rapport aux données n’est pas déterministe. Pour les signaux d’état et la configuration, cela convient. Pour les usages en temps réel — commutation de direction RS-485 semi-duplex pilotée par logiciel, ou BREAK précisément temporisé — ne pilotez pas la ligne à distance via internet ; gérez ce timing localement sur l’appareil et utilisez la liaison cloud uniquement pour les données.

Réponse de Nikolai Svarachevsky · Développeur principal

Oui. En mode Raw, SEC dispose d’un onglet Signal Lines où vous pouvez configurer quelles lignes de signal sont activées ou désactivées lors de la connexion — vous pouvez ainsi avoir une ligne activée lorsqu’un client réseau se connecte et désactivée lorsqu’il se déconnecte. C’est exactement l’indicateur « un client distant est maintenant connecté » que vous décrivez, et c’est un paramètre pris en charge plutôt que quelque chose que vous devez improviser.

Il est utile de bien comprendre la distinction avec le mode Telnet : dans ce mode, SEC reflète les états réels des lignes matérielles entre les deux extrémités, de sorte que les lignes suivent le périphérique plutôt que la connexion. Le comportement configurable des lignes à la connexion/déconnexion est une fonctionnalité du mode Raw. Définissez les lignes spécifiques ainsi que leurs états à la connexion / à la déconnexion dans cet onglet ; si votre ligne cible ou la polarité souhaitée ne figure pas parmi les options, décrivez l’objectif exact au support et nous confirmerons ce que la version actuelle permet.

Réponse de Bohdan Miniv · Ingénierie QA

SEC dispose d’un paramètre keep-alive qui gère exactement cela. Il vérifie périodiquement que le lien est toujours actif, de sorte qu’une connexion qui a été interrompue silencieusement soit détectée et fermée au lieu de rester là en semblant active. En ajustant la temporisation du keep-alive, vous contrôlez à quel point SEC surveille étroitement le lien — des intervalles plus courts détectent une interruption plus rapidement, des intervalles plus longs sont plus souples.

La raison pour laquelle c’est important est qu’un chemin réseau interrompu silencieusement — une connexion TCP « semi-ouverte » où un côté a disparu sans fermeture correcte — peut sinon sembler connecté jusqu’à ce que quelque chose essaie réellement d’envoyer des données. La vérification keep-alive est ce qui met cela en évidence rapidement et permet à la connexion de se rétablir proprement. Ajustez la temporisation selon vos besoins : suffisamment stricte pour détecter rapidement une véritable interruption, suffisamment souple pour qu’un appareil naturellement silencieux ne soit pas signalé pendant des périodes normales d’inactivité.

Réponse de Bohdan Miniv · Ingénierie QA