Umleitung von Daten der seriellen Schnittstelle über Telnet

Im Prinzip ja — RFC 2217 ist ein veröffentlichter Standard, daher kann SEC mit konformen Implementierungen von Drittanbietern interoperieren, einschließlich Hardware-Konsolen-/Terminalservern von Anbietern wie Digi, Lantronix und Moxa, die die Telnet-COM-Port-Control-Option bereitstellen, sowie mit Software-Endpunkten wie einem Linux-ser2net/pySerial-Server. Diese Interoperabilität ist einer der Gründe, den Telnet-Modus zu bevorzugen, wenn Sie eine Verbindung zu Nicht-SEC-Geräten herstellen.

Die ehrliche Einschränkung: Testen Sie die konkrete Kombination immer auf dem Prüfstand, bevor Sie sich darauf verlassen. Implementierungen unterscheiden sich darin, welche optionalen RFC-2217-Befehle sie unterstützen und wie strikt sie der Spezifikation folgen, sodass ein bestimmter Hardware-Server möglicherweise die Baudraten-Aushandlung verarbeitet, aber nicht irgendeinen Signalleitungsbefehl — oder umgekehrt. Es funktioniert normalerweise — aber „es ist ein Standard“ ist kein Ersatz dafür, in der Praxis zu bestätigen, dass Ihre beiden konkreten Geräte tatsächlich zusammenarbeiten.

Beantwortet von Bohdan Miniv · QA-Engineering

Die Flusssteuerungssignale werden dargestellt: RFC 2217 überträgt den Zustand der Steuerleitungen (RTS/CTS und den Flusssteuerungsmodus) zwischen den Enden, sodass Hardware-Handshake vom Protokoll verstanden wird, anstatt wie im Raw-Modus ignoriert zu werden. Für die Einrichtung und für Geräte, bei denen es bei der Flusssteuerung auf die korrekte Konfiguration ankommt, funktioniert das.

Die Einschränkung ist die Reaktionsfähigkeit über ein Netzwerk. Hardware-Flusssteuerung existiert, um einen schnellen Sender genau in dem Moment zu drosseln, in dem sich der Puffer eines Empfängers füllt — eine Echtzeitreaktion, gemessen in Zeichenzeiten. Über eine Netzwerkverbindung muss die CTS-Änderung mit ihrer Latenz und Pufferung über TCP zurückübertragen werden, sodass sie möglicherweise nicht schnell genug ankommt, um einen Überlauf bei einem Datenstrom mit hohem Durchsatz zu verhindern. In einem LAN mit geringer Latenz ist das normalerweise in Ordnung; über das Internet sollten Sie sich nicht darauf verlassen, dass entfernte Hardware-Flusssteuerung Pufferüberläufe bei einem schnellen Gerät verhindert. Wo immer möglich, sollte die Flusssteuerung lokal am physischen Port wirken und nur die Daten über die Verbindung übertragen.

Beantwortet von Nikolai Svarachevsky · Leitender Entwickler

Weil RFC 2217 die Parameter des Ports für eine einzelne Sitzung aushandelt und kontrolliert. Der ganze Sinn des Telnet-Modus besteht darin, dass ein verbundener Client die Baudrate festlegen, Signalleitungen umschalten und den Portstatus lesen kann — und es gibt keine schlüssige Möglichkeit, dass zwei Clients gleichzeitig jeweils diese Autorität über einen physischen Port haben. Wenn zwei Clients unterschiedliche Baudraten anfordern, wessen setzt sich durch? Das Protokoll hat darauf keine Antwort, daher ist der Modus als Peer-to-Peer definiert.

Genau deshalb gibt es den Raw-Modus für den Eins-zu-viele-Fall: Raw besitzt keine Kontrolle über Portparameter, sondern überträgt nur Bytes, sodass der Stream sicher an viele Clients dupliziert werden kann. Der Kompromiss ist die Kehrseite derselben Medaille — Raw gibt Ihnen mehrere Clients, aber keine Remote-Portsteuerung; Telnet gibt Ihnen volle Portsteuerung, aber nur einen einzelnen Peer. Wählen Sie den Modus, der dazu passt, ob Sie Steuerung oder Verteilung benötigen.

Beantwortet von Nikolai Svarachevsky · Leitender Entwickler

Da RFC 2217 als eine Option auf Telnet definiert ist, das über TCP läuft — und es hängt genau von den Garantien ab, die TCP bietet. Die Port-Steuerbefehle (Baudrate setzen, Signalleitungen setzen) werden In-Band ausgehandelt und verlassen sich darauf, dass der Datenstrom zuverlässig und in der richtigen Reihenfolge ankommt, wobei beide Enden einander bestätigen können. Das ist eine verbindungsorientierte Kommunikation.

UDP bietet nichts davon: keine Verbindung, keine Reihenfolge, keine Zustellgarantie, keine Bestätigung. Eine Aushandlung, die von einer zuverlässigen, geordneten Zustellung ausgeht, kann einfach nicht über ein Transportprotokoll laufen, das genau den Befehl verwerfen oder umordnen kann, der die Baudrate setzt. Daher sind die beiden Modi nach dem Transportprotokoll klar getrennt: RFC-2217-Signalisierung gehört auf TCP, und UDP ist nur für rohe Einwegdaten gedacht. Wenn Sie Signal-/Parametersteuerung benötigen, sind Sie zwangsläufig auf TCP angewiesen.

Beantwortet von Nikolai Svarachevsky · Leitender Entwickler