Übertragung serieller Daten in die Cloud

Ja, aber mit einem echten Vorbehalt, den Sie beim Design berücksichtigen müssen. Ein physischer COM-Port ist exklusiv geöffnet — jeweils nur ein Prozess — daher können eine lokale Anwendung und die Cloud nicht beide denselben echten Port direkt belegen. Das praktikable Muster ist ein virtuelles Port-Paar auf dem lokalen Rechner: Die lokale App kommuniziert mit einem virtuellen Port, SEC überbrückt ihn zum echten Port, und die Cloud-Verbindung teilt sich dieselben überbrückten Daten.

Die ehrliche Warnung: Sobald sowohl eine lokale App als auch eine Cloud-App mit einem Gerät verbunden sind, kann sich ihr Datenverkehr vermischen. Eingehende Daten vom Gerät werden an beide Empfänger verteilt (gut für schreibgeschütztes Lesen), aber wenn beide Seiten Befehle senden, werden diese Befehle auf der einzelnen physischen UART ineinander verschachtelt und verfälschen sich gegenseitig. Daher ist „lokal und Cloud gleichzeitig“ für gemeinsames Lesen sicher; zum Steuern des Geräts sollten Sie sicherstellen, dass immer nur eine Seite gleichzeitig schreibt.

Beantwortet von Nikolai Svarachevsky · Leitender Entwickler

Ja — das ist eine Fan-in-Topologie und sie funktioniert gut. Auf der Cloud-Maschine erstellen Sie einen virtuellen COM-Port pro Quelle, der jeweils von einer Client-Verbindung gespeist wird, die sich vom entsprechenden Standort aus einwählt (oder von Servern an jedem Standort, zu denen die Cloud eine ausgehende Verbindung herstellt — die Verbindungstypen sind austauschbar). Ihre Cloud-Anwendung sieht dann für jedes entfernte Gerät einen separaten, sauberen COM-Port.

Die Entwurfsregel, die das überschaubar hält: Geben Sie jeder Quelle ihren eigenen virtuellen Port, anstatt mehrere Geräte in einem Port zusammenzuführen. Wenn Sie mehrere Geräte in einen einzigen Port leiten, treffen ihre Bytes vermischt ein, ohne dass sich feststellen lässt, welches von welchem stammt. Ein Port pro entferntem Gerät — und denken Sie daran, dass die Verbindung jedes Standorts ihre eigene Internet-Latenz hat, also dimensionieren Sie Timeouts pro Quelle, nicht auf Basis einer einzigen Annahme.

Beantwortet von Nikolai Svarachevsky · Leitender Entwickler

Der Durchsatz wird fast nie in einer Weise beeinflusst, die Sie bemerken würden, denn serielle Datenraten sind im Vergleich zur Netzwerkbandbreite verschwindend gering — selbst eine schnelle serielle Verbindung ist im Vergleich zu einer normalen Internetverbindung nur ein Rinnsal, daher ist SEC nicht bandbreitengebunden. Was SEC und das Netzwerk hinzufügen, ist Latenz, keine Durchsatzobergrenze: ein kleiner Software-Overhead plus die Round-Trip-Zeit des Pfads zur Cloud.

Bei kontinuierlicher oder umfangreicher Übertragung ist diese Latenz eine einmalige Pipeline-Verzögerung und der effektive Durchsatz bleibt hoch. Sie macht sich bei gesprächigem Request/Response-Verkehr bemerkbar, bei dem jeder Austausch die Round-Trip-Zeit bezahlt und die effektive Rate sinkt, obwohl die rohe Bandbreite reichlich vorhanden ist. Wenn das Ihr Muster über einen langen Cloud-Pfad ist, reduzieren Sie die Anzahl der Round-Trips (Anfragen bündeln, einen Poller lokal am Gerät halten), anstatt zu erwarten, dass SEC die Verbindung beschleunigt.

Beantwortet von Bohdan Miniv · QA-Engineering

Der Zustand der Signalleitungen wird übertragen, wenn Sie den Modus Telnet (RFC 2217) verwenden: Die RTS/DTR-Änderungen der entfernten Anwendung werden übertragen und am physischen Port angewendet, und Leitungszustände wie CTS/DSR/DCD werden zurückgemeldet. Im Raw-Modus wird nichts davon übertragen — Raw überträgt nur Daten. Verwenden Sie also für die Signalsteuerung den Telnet-Modus.

Die ehrliche Grenze ist das Timing, nicht die Fähigkeit. RFC 2217 überträgt Steuerleitungsänderungen In-Band und nur lose mit dem Datenstrom synchronisiert, sodass über eine Cloud-Verbindung mit Pufferung und Internetlatenz der genaue Zeitpunkt, zu dem sich eine Leitung relativ zu den Daten ändert, nicht deterministisch ist. Für Statussignale und die Einrichtung ist das in Ordnung. Für Echtzeitanwendungen — softwaregesteuertes Halbduplex-RS-485-Richtungsumschalten oder präzise getaktetes BREAK — steuern Sie die Leitung nicht aus der Ferne über das Internet; behandeln Sie dieses Timing lokal am Gerät und verwenden Sie die Cloud-Verbindung nur für Daten.

Beantwortet von Nikolai Svarachevsky · Leitender Entwickler

Ja. Im Raw-Modus hat SEC einen Tab Signal Lines, in dem Sie konfigurieren können, welche Signalleitungen beim Verbindungsaufbau gesetzt oder abgesenkt werden — sodass Sie eine Leitung aktivieren können, wenn sich ein Netzwerk-Client verbindet, und deaktivieren, wenn er die Verbindung trennt. Das ist genau der Indikator „ein entfernter Client ist jetzt verbunden“, den Sie beschreiben, und es ist eine unterstützte Einstellung statt etwas, das Sie improvisieren müssen.

Es lohnt sich, den Unterschied zum Telnet-Modus zu verstehen: Dort bildet SEC die tatsächlichen Hardware-Leitungszustände zwischen den beiden Enden ab, sodass die Leitungen dem Gerät und nicht der Verbindung folgen. Das konfigurierbare Leitungsverhalten beim Verbinden/Trennen ist die Funktion des Raw-Modus. Stellen Sie in diesem Tab die spezifischen Leitungen und ihre Zustände beim Verbinden / Trennen ein; wenn Ihre gewünschte Leitung oder Polarität nicht zu den Optionen gehört, beschreiben Sie das genaue Ziel dem Support, und wir bestätigen, was der aktuelle Build erlaubt.

Beantwortet von Bohdan Miniv · QA-Engineering

SEC verfügt über eine Keep-Alive-Einstellung, die genau dies handhabt. Sie prüft in regelmäßigen Abständen, ob die Verbindung noch aktiv ist, sodass eine Verbindung, die unbemerkt abgebrochen ist, erkannt und beendet wird, anstatt einfach dazusitzen und aktiv zu wirken. Durch Anpassen des Keep-Alive-Timings steuern Sie, wie genau SEC die Verbindung überwacht — kürzere Intervalle erkennen einen Abbruch schneller, längere sind entspannter.

Der Grund, warum das wichtig ist, ist, dass ein unbemerkt unterbrochener Netzwerkpfad — eine „halb offene“ TCP-Verbindung, bei der eine Seite ohne ordnungsgemäßes Schließen verschwunden ist — andernfalls verbunden erscheinen kann, bis tatsächlich etwas versucht, Daten zu senden. Die Keep-Alive-Prüfung bringt das schnell ans Licht und ermöglicht es, die Verbindung sauber neu aufzubauen. Passen Sie das Timing an Ihre Anforderungen an: eng genug, um einen echten Abbruch umgehend zu erkennen, locker genug, damit ein von Natur aus stilles Gerät während normaler Leerlaufzeiten nicht fälschlich markiert wird.

Beantwortet von Bohdan Miniv · QA-Engineering