TCP-Server Programmierung

[BR472]

Hallo Community,
ich bin gerade dabei mir mit Visual Basic das GSP MFT200A zu programmieren, weil ich es gerne für mein Fahrpult haben möchte. Unter der Kategorie "Monitoring" zeigt das Gerät, die aktuell gefahrene Geschwindigkeit an. Zurzeit entsteht diese Zahl einfach durch eine Zufallszahl, was allerdings hinreichend unrealistisch ist.
Bei dem Zusi Display wird die Geschwindigkeit doch via TCP-Server ausgelesen und ausgegeben.
Könnt ihr mir dabei helfen, dass mein FIS-Gerät, dies auch beherrscht. In Sachsen Quellcode für die Verbindung zwischen meinem GSP MFT200A und dem TCP-Server mit Zusi.

Vielen Dank schon im vorraus für eure Hilfe.

Liebe Grüße Tobi

[Carsten Hölscher]

Schau mal in der Doku zum TCP-Server - ist evtl. nur auf der CD. Dort ist alles mit Beispielen erklärt.

Carsten

[BR472]

Hallo Carsten,
ich habe diese Dokumentation gefunden. Leider ist sie für Delphi geschrieben und meine Programmierkenntnisse reichen leider nicht aus, dass umzuschreiben zu VB2008.

@All:
Kann mir jemand etwas bei dem Quellcode für die Abfrage der Geschwindigkeit aus Zusi via TCP-Server und der daraus resultierenden Ausgabe in einem Label helfen?
Würde mich sehr freuen.

Liebe Grüße Tobi

[Andreas Karg]

Benutzt du Visual Basic.NET? In dem Falle hätte ich nämlich eine handliche kleine Datei für dich. Ich hab' mir vor einiger Zeit mal zum Einarbeiten in C# eine Schnittstelle zu Zusi geschrieben und sogar halbwegs dokumentiert. Der Benutzer der DLL muss nur noch die Verbindung herstellen und mitteilen, was er haben will. Die eingehenden Daten werden automatisch verarbeitet und gespeichert. Von da können sie dann ausgelesen werden.

[BR472]

Hallo Andreas,
ja, ich benutze Visual Basic.NET. Und es wäre super, wenn du mir diese Datei zur Verfügung stellen könntest. Ich würde sie selbstverständlich nicht weitergeben.
Schon jetzt einmal vielen Dank dafür.
Mein Mail-Adresse steht im Account drin.
Liebe Grüße Tobi

[Andreas Karg]

So. Hab mal die Dokumentation halbwegs fertig gebastelt und das Ganze hochgeladen:
Zusi-Datenausgabe-DLL für .NET

Stehe für Fragen zur Verfügung, allerdings hab' ich momentan studienbedingt wenig Zeit.

Vielen Dank für Ihre Kooperation.

Edit: Link einstweilen entfernt, da veraltete Version.

[BR472]

Hallo Andreas,
vielen Dank schon einmal für die Datei. Ich habe sie auch als Verweis in VB eingebunden und mir auch deine ausführliche Dokumentation durchgelesen, dabei scheitert es allerdings. Die Doku ist zwar echt gut, nur ich komme damit nicht klar.
Könntest du möglicherweise, sofern du Zeit haben solltest, mir dabei helfen, dass VB über deine DLL und den TCP-Server die Geschwindigkeit ausließt. Leider weiß ich schon nicht, wie man die Instanz als Klasse erzeugt.
Über deine Hilfe wäre ich sehr dankbar.
Liebe Grüße Tobi

[Max Senft]

Hi,

ohne jetzt die Funktionsfähigkeit überprüft zu haben *sollte* es laut der Anleitung so funktionieren:

Diese Zeilen sollten beim Drücken auf einen Verbinden-Knopf (oder ähnlichem) ausgeführt werden:

Code: Alles auswählen

Dim myCon As Zusi_Datenausgabe.ZusiTCPConn = New Zusi_Datenausgabe.ZusiTCPConn()
myCon.RequestedData.Add(myCon.IDs.Item("Geschwindigkeit"))
myCon.Connect("localhost", 4711)

Diese Zeilen sollten - laut Anleitung - durch einen Timer z.B. alle 1000ms ausgelöst werden, wobei das Dim natürlich irgendwo vorher, z.B. global passieren sollte:

Code: Alles auswählen

myCon.RefreshData()
Dim curGeschwindigkeit As Single = myCon.FloatData.Item(myCon.IDs.Item("Geschwindigkeit"))

Grüße
Max
PS: Die Übersicht welche Members die DLL alle hat bekommst du - zumindest in VisualStudio 2005 VB - im Objektbrowser.

[BR472]

Hallo Max,
das funktioniert leider nicht.
Einerseits ist my.Con nicht deklariert, obwohl ich es global eingesetzt habe, vor den gesamten Quellcode. Und andererseits tritt der Fehler auf: SocketExpection wurde nicht behandelt.
Könntest du da nocheinmal reinschauen?
Liebe Grüße Tobi

[Roland Ziegler]

@BR472: Jetzt mal vorsichtig gefragt: Wie sind denn Deine programmiertechnischen Vorkenntnisse? Wie tief bist Du in die Welt der Klassen und Objekte bisher vorgedrungen?

@Andi: Sollte so ein Socket-Empfänger nicht rein ereignisgesteuert arbeiten? Also seine empfangenen Daten über Callbacks oder Events abgeben? Okay, würde komplizierter wg. Multithreading, aber das könnte man in .Net ja wieder zwangsweise kanalisieren. Der Anwender würde sich den Timer sparen. Der derzeitige Ansatz ist ansonsten sicherlich extrem simpel für den Anwender, kann aber m.E. nur als Einstieg dienen.

[Max Senft]

Hi,

du solltest im Connect-Aufruf die korrekten Daten eintragen. Desweiteren wäre eine Abfrage, ob der Connector überhaupt verbunden ist nicht verkehrt. Schau dir im Objektbrowser doch einfach mal alle Elemente von Zusi_Datenausgabe an. Andi hat die Sachen wirklich alle gut erklärt.

Gruß
Max

[Andreas Karg]

Roland: Wenn ich dich richtig verstehe, müsste also mein Empfänger selber merken, wann frische Daten im Stream anstehen und sie zusammenpacken. Dann löse ich ein Ereignis aus (OnDataReceived oder sowas), das als Parameter die empfangenen Datensätze enthält. Richtig?
In dem Falle sollte ich mir eine andere Socket-Schnittstelle suchen als System.Net.Sockets.TCPClient. Weder das Ding noch sein Streamobjekt haben Ereignisse für den Dateneingang. Ich müsste mir also demnach in meinen Empfänger direkt einen Timer einbauen, worauf ich dann doch verzichten wollte.

So seh' ich das jedenfalls im Moment. Bin für Hinweise, wie's besser geht, natürlich aufgeschlossen.

[Christopher Spies]

Hallo Andreas,

In dem Falle sollte ich mir eine andere Socket-Schnittstelle suchen als System.Net.Sockets.TCPClient. Weder das Ding noch sein Streamobjekt haben Ereignisse für den Dateneingang. Ich müsste mir also demnach in meinen Empfänger direkt einen Timer einbauen, worauf ich dann doch verzichten wollte.

das ist Unsinn!
TCPClient hat zwar nicht direkt Ereignisse, wohl aber Methoden für den asynchronen Empfang. Ich habe das so gelöst, dass ich TCPClient.BeginReceive aufrufe und eine Callback-Funktion "OnReceive" in meiner ZusiTCPClient-Klasse übergebe. Wenn Daten eintreffen, wird diese Funktion aufgerufen. Sofern ein vollständiges Paket mit neuen Daten eingetroffen ist, löse ich in der "OnReceive"-Funktion ein Ereignis "GotData" aus und rufe dann wieder TCPClient.BeginReceive auf, um für das nächste Paket empfangsbereit zu sein.
Diese Vorgehensweise sollte auch Thread-sicher sein.

Sollte so ein Socket-Empfänger nicht rein ereignisgesteuert arbeiten? [...] Der Anwender würde sich den Timer sparen.

Es gibt natürlich Anwendungsfälle, bei denen ein Zeitgeber nützlich ist. Zusi verschickt Daten in unregelmäßigen Abständen, maximal ca. 10 Mal pro Sekunde. Wenn regelmäßige Aktualisierung einer Anzeige oder Neuberechnung von Werten (in größeren Abständen) gewünscht ist, kommt man um einen Zeitgeber nicht herum. Ereignisse stören dann eher.

Gruß
- Christopher

Edit: Roland geantwortet

[Roland Ziegler]

Andi, TCP bringt ja neben der gesicherten Verbindung sein uraltes Design mit, auf einen Text-Datenstrom ausgerichtet zu sein. Die übliche Nutzung ist aber seit über 20 Jahren die des Binär-Datenstroms.

In .Net wäre ein möglicher Ansatz der, TCPClient nur für den Verbindungsaufbau zu nutzen und für den Datenaustausch direkt auf der Klasse Socket aufzusetzen. Der Empfänger läuft dann in einer Schleife (eigener Thread) und versucht permanent, Daten vom Socket zu lesen mit Receive(). Receive kann man irgendwie dazu bringen, auf Timeout zu laufen, wenn nichts kommt. (Das ist dann ein internes Socket-Timeout und .Net-unabhängig, iirc.) Ideal und sehr performant ist dieses Vorgehen für binäre Telegrammstrukturen, die aus einem Kopf fester Länge und einem Datenteil variabler Länge bestehen. Im Kopf steht die Länge des variablen Teils. Man liest dann zunächst den Kopf und anschließend den Datenteil in genau zwei Receive-Aufrufen, sofern kein Timeout eintritt.

Hat man sein Telegramm, wird es ggf vorverarbeitet und die Inhalte anschließend über Callback, Event oder sonstiges Delegate an einen angemeldeten Consumer weitergeleitet.

Man kann diesen Ansatz perfektionieren, indem man ein solches Telegrammformat aus festen und variablem Teil abstrahiert und per Schnittstelle oder abstrakter Basisklasse seinem Socket-Wrapper übergibt. Dieser Socket-Wrapper würde dann ohne Code-Modifikation für alle gleichartigen Telegrammtypen beliebiger Anwendungen geeignet sein.

Um vor dem Anwender den separatem Receive-Thread zu verbergen und ihn vom Locking zu verschonen, kann man auf ISynchronizeInvoke zurückgreifen, zumindest, wenn der Anwender diese Schnittstelle unterstützt. Das ist für GUIs generell der Fall.

Zu Timern: Ein alter Spruch des echtzeitnahen Software-Designs lautet Thou Shalt Not Poll! Wenn auch selten absolut durchsetzbar, so hilft der gute Vorsatz doch ungemein, und der Durchsatz wird es danken.

[Andreas Karg]

Hmm. Das mit dem Extrathread werd' ich mal ausprobieren. Wie bringe ich diesen dann dazu, den Rechner nicht komplett mit überflüssigen Schleifendurchläufen auszulasten? Ist Thread.Sleep() dafür geeignet? Dass es funktioniert, weiß ich... Aber das trifft auf das "gute" alte goto auch zu...

[Roland Ziegler]

Idealerweise kein Sleep. Die Receive-Funktion sollte blockieren, im Modus "Blocking" für den Socket.

Man kann natürlich auch Non-Blocking wählen, da meine ich zu erinnern, dass dann das Verhalten auf original Windows-.Net ein Sleep erforderte, auf Mono aber nicht. Den von Christopher vorgeschlagenen Ansatz mit asynchronem Lesen auf höherer Ebene hatte ich meiner Erinnerung nach wieder verworfen (lange her), weil die Diagnose im Störungsfall irgendwie aufwändig wurde.

[Christopher Spies]

Hallo Roland!

Ideal und sehr performant ist dieses Vorgehen für binäre Telegrammstrukturen, die aus einem Kopf fester Länge und einem Datenteil variabler Länge bestehen. Im Kopf steht die Länge des variablen Teils. Man liest dann zunächst den Kopf und anschließend den Datenteil in genau zwei Receive-Aufrufen, sofern kein Timeout eintritt.

Hat man dann nicht immer noch das Problem, dass TCP einen Datenstrom überträgt, also auf Telegrammgrenzen keine Rücksicht nimmt? Ein Datentelegramm kann dann mittendrin geteilt sein.

Zu Timern: Ein alter Spruch des echtzeitnahen Software-Designs lautet Thou Shalt Not Poll! Wenn auch selten absolut durchsetzbar, so hilft der gute Vorsatz doch ungemein, und der Durchsatz wird es danken.

Was hat Pollen jetzt mit Timern zu tun? Timer verwendet man ja gerade, um nicht pollen zu müssen. "Echtzeit" bedeutet ja nur, dass Vorgänge in vorgegebenen Zeitintervallen ablaufen.

Den von Christopher vorgeschlagenen Ansatz mit asynchronem Lesen auf höherer Ebene hatte ich meiner Erinnerung nach wieder verworfen (lange her), weil die Diagnose im Störungsfall irgendwie aufwändig wurde.

Was genau ist das Problem mit der Diagnose im Störungsfall? Ich habe bisher nur triviale Anwendungsfälle ausprobiert.

Gruß
- Christopher

[Roland Ziegler]

Hat man dann nicht immer noch das Problem, dass TCP einen Datenstrom überträgt, also auf Telegrammgrenzen keine Rücksicht nimmt? Ein Datentelegramm kann dann mittendrin geteilt sein.

Richtig, es bleibt ein Strom und es gibt keinerlei Garantie, dass ein Telegramm als ein Block übertragen wird (aber jede Menge Software, die irrtümlich davon ausgeht). Eine korrekt arbeitende Anwendung muss ggf einen Moment warten. Nicht ewig, dafür sorgt der Nagle-Algorithmus im Socket.

Was hat Pollen jetzt mit Timern zu tun? Timer verwendet man ja gerade, um nicht pollen zu müssen. "Echtzeit" bedeutet ja nur, dass Vorgänge in vorgegebenen Zeitintervallen ablaufen.

Polling ohne Timer sollte ja eigentlich nur ein Relikt aus jenen Single-User/Single-Task-Umgebungen früherer Tage sein. Ausnahmen mögen noch manche DirectX-Anwendungen darstellen, aber auch dort hat die Ereignissteuerung Einzug gehalten, wenn auch über Timer.

Polling mit Timer ist immer noch Polling. Unabhängig von einem Datenereignis wird CPU-Zeit gefressen. Noch wesentlicher: In der Verarbeitungskette entsteht eine zusätzliche Verzögerung, die nicht mehr von der Rechenleistung abhängt. Wenn man so etwas vermeiden kann, sollte man das tun.

Was genau ist das Problem mit der Diagnose im Störungsfall? Ich habe bisher nur triviale Anwendungsfälle ausprobiert.

Ich meine, es ging um die "WouldBlock"-Meldung, die ich haben wollte, und von echten Störungen unterscheiden musste. Es musste erkannt werden, ob bei Ausbleiben von Daten ggf. aktiv geschlossen werden sollte, oder schon von der eigenen oder der Gegenseite eine Schließung eingeleitet wurde. Aber das ist schon lange her und ich bin mir nicht mehr ganz sicher, ob es das war.

[Christopher Spies]

Hallo Roland!

Polling mit Timer ist immer noch Polling. Unabhängig von einem Datenereignis wird CPU-Zeit gefressen. Noch wesentlicher: In der Verarbeitungskette entsteht eine zusätzliche Verzögerung, die nicht mehr von der Rechenleistung abhängt. Wenn man so etwas vermeiden kann, sollte man das tun.

Du hattest den Begriff "Echtzeit" ins Spiel gebracht. "Echtzeit" heißt für mich nur, dass man a priori garantieren kann, dass eine bestimmte Operation mit einer bestimmten Wahrscheinlichkeit innerhalb einer bestimmten Zeit abgeschlossen wird. Ist die Wahrscheinlichkeit 1, der Abschluss einer Operation innerhalb einer definierten Zeit also garantiert, spricht man von "harten" Echtzeitbedingungen, sonst von "weichen".
Es gibt reaktive Systeme, die auf diskrete Ereignisse reagieren. Diese kann man dann natürlich über Interrupts o. ä. erfassen und benötigt kein Polling. Wenn die Auftrittsrate der einzelnen Ereignisse beschränkt ist und die Ereignisse priorisiert sind, kann für jedes mögliche Ereigniss eine maximale Reaktionszeit bestimmt werden. Zu den "harten" Echtzeitsystemen gehören aber beispielsweise auch digitale Regelungen, die in festen Zeitabständen eine zeitkontinuierliche Größe abtasten. Diese Zeitabstände kann man durch "Warteschleifen" im Programm herstellen, was nur bei sehr einfachen Systemen funktioniert, oder man verwendet einen Zeitgeber. Wie soll man auf den verzichten können?

Ich meine, es ging um die "WouldBlock"-Meldung, die ich haben wollte, und von echten Störungen unterscheiden musste. Es musste erkannt werden, ob bei Ausbleiben von Daten ggf. aktiv geschlossen werden sollte, oder schon von der eigenen oder der Gegenseite eine Schließung eingeleitet wurde.

Meinst Du mit "Schließung" die Schließung der TCP-Verbindung?

Gruß
- Christopher

[Roland Ziegler]

Du hattest den Begriff "Echtzeit" ins Spiel gebracht. "Echtzeit" heißt für mich nur, dass man a priori garantieren kann, dass eine bestimmte Operation mit einer bestimmten Wahrscheinlichkeit innerhalb einer bestimmten Zeit abgeschlossen wird. Ist die Wahrscheinlichkeit 1, der Abschluss einer Operation innerhalb einer definierten Zeit also garantiert, spricht man von "harten" Echtzeitbedingungen, sonst von "weichen".

Ich benutze den Begriff "echtzeitnah", der Deinen "weichen" Bedingungen wohl nahe kommt. Die Diskussion um die Unterscheidung kam in den 90ern auf, als erstmalig im größeren Stil Feld-, Wald- und Wiesensysteme wie NT für Zwecke eingesetzt wurden, für die man vorher ausschließlich dedizierte Echtzeitsysteme benutzt hatte. Ich fand die strikte Trennung schon vorher merkwürdig, weil schon zuvor die zu lösendenden Aufgaben so harte Randbedingungen oft gar nicht wirklich stellten.

Das Wesen der echtzeitnahen Verarbeitung liegt im Fully Preemptive Kernel der meisten moderneren Multitask-Systeme. Die Universalsysteme arbeiten meist in Kombination mit Zeitscheiben. Es gab (und gibt sicher heute noch) auch Systeme ohne Zeitscheiben, damals z.B. VAXELN, die dann auf jeden Fall Disziplin der Entwickler einforderten.

Gemeinsam ist aller Ereignissteuerung, dass sie, wie Du anführst, per Interrupt initiiert wird. Nur wechselt der Modus ja sinnvollerweise recht bald von Kernel in User, und der weitere Ablauf der Ereigniskette ist durchaus und gewollt mit einer Reihe zusätzlicher Taskwechsel und Kontext-Switches verbunden. Das ursprüngliche DEC-Modell der internen Tasksynchronisation ist mit NT so richtig erfolgreich geworden. Die Sockets aber stammen bekanntlich nicht von DEC. Der dort verwendete "Select"-Mechanismus zur Ereignisweitergabe gründet auf einer anderen Philosophie, die Unix in diesem Bereich geprägt hat.

Interessant ist die Abstraktion dieses Musters als "Reactor" (Douglas Schmidt et al. : Pattern Oriented Software Architecture, Vol 2, Patterns for Concurrent and Networked Objects). Die Implementierung in Schmidts eigenem ACE zeigt entsprechend auch zwei Ausprägungen: "Select" für Unix und "WMFO" (wait for multiple objects) für NT. Beide aber basieren auf Grundfunktionen des Kernels: Ohne Polling, auch nicht zeitgesteuert, auf mehrere mögliche Ereignisse warten zu können, die durchaus interrupt-initiiert sein können, um dann gerichtet zu dispatchen (Reactor als Klasse in einem geeigneten Framework ist aber m.W. so nicht für .Net/Mono verfügbar).

Meinst Du mit "Schließung" die Schließung der TCP-Verbindung?

Ja. Im realen Leben, d.h. vor allem im WAN, sind Sockets ja bei weitem nicht so zuverlässig und langlebig, wie uns die Tutorien zur Socketprogrammierung immer weismachen wollen.