Sofware-Struktur für kontinuierliche UDP-Kommunikation

[Matze]

Hi zusammen,

ich muss auf Nachrichten von einem Gerät warten, das mir per UDP Daten sendet. Teils fortlaufend, teils mit einer Pause.

Gelöst habe ich das bisher so:

Code:

UdpClient Client = new Client(Port);
Client.BeginReceive(new AsyncCallback(UDPRecvCallback), null);

private void UDPRecvCallback(IAsyncResult res)
{
    IPEndPoint RemoteIpEndPoint = new IPEndPoint(IPAddress.Any, 2000);
    byte[] received = Client.EndReceive(res, ref RemoteIpEndPoint);

    // Hier Werte protokollieren und visualisieren

    Client.BeginReceive(new AsyncCallback(recv), null);
}

In der Callback-Funktion "UDPRecvCallback" werden die empfangenen Werte verarbeitet (geparst), protokolliert und visualisiert.

Ich finde das persönlich aber etwas unsauber gelöst.

Ich würde gerne die Werte protokollieren und wenn diese protokolliert sind, die Daten bestätigen und anschließend wird noch ein "Fertig"-Telegramm ausgetauscht. Erst danach ist die Software bereit für ein neues UDP-Telegramm.
Das Gerät sendet mir die UDP-Daten auch so lange fortlaufend, bis die Software entsprechend antwortet und umgekehrt (um sicherzustellen, dass die Daten auch wirklich korrekt verarbeitet wurden):

Code:

Gerät       C#-Software
----------------------
Daten   ->
Daten   ->
...
        <- Daten quittieren
        <- Daten quittieren
        <- Daten quittieren
          ...
Fertig? ->
Fertig? ->
...
        <- Fertig!
        <- Fertig!
         ...

ggf. Wartezeit und das Ganze von vorne

Die Visualisieren sollte vielleicht komplett unabhängig ablaufen.

Was gibt es denn hier für Möglichkeiten, dies flexibel und ordentlich zu programmieren (C# + WPF)?

Grüße
Matze

[Phoenix]

Äh.. Du willst also sicherstellen, dass die Pakete alle ankommen?

Warum zum Teufel nimmst Du dann UDP und nicht TCP?
UDP ist ja gerade für nicht zuverlässige Paketzustellen da, wenn es mal nicht schlimm ist wenn welche fehlen (z.B. beim Video-Streaming).
TCP stellt sicher, das alles ankommt.

Warum willst Du also die TCP-Funktionalität nachprogrammieren, wenn Du sie (korrekt und fehlerfrei und vermutlich mit deutlichst weniger Overhead) einfach direkt nutzen könntest?

[Matze]

Zitat von Phoenix:

Warum zum Teufel nimmst Du dann UDP und nicht TCP?

Weil das Gerät eines Drittherstellers, mit dem ich kommunizieren muss, mit UDP kommuniziert und nicht mit TCP/IP. Ganz einfach.

Mit dem "Handshake-Telegramm" ist so auch sichergestellt, dass die Daten ankommen.

[Robotiker]

Ich bin mir nicht sicher, was du genau wissen willst, aber wenn es darum geht wirklich Paket für Paket z.B. in einen Thread zu verarbeiten würde ich das so machen

Code:

// Mit UdpClient myClient;
// und IPEndPoint theEndPoint;

if (myClient.Client.Poll(2000, SelectMode.SelectRead))
{
    byte[] buffer = myClient.Receive(ref theEndPoint);

    // ...
}

[Furtbichler]

Dein Callback nimmt nur die Daten auf, prüft Sie und behandelt die Antworten etc. z.B. über eine state machine.

Sobald die Daten committed sind, können sie weiterverarbeitet werden.

Du könntest sie in eine Queue packen oder einfach per Observer-Pattern verteilen.

Deine Visualisierung und Protokollierung wären dann subscriber.

[BUG]

Wenn du gleichzeitig empfangen (bzw. warten) und verarbeiten willst, wirst du Threads verwenden müssen.
Dabei wird eine Queue zur Kommunikation zwischen den Threads benutzt werden.

Ich fand diesen Vortrag ziemlich erleuchtend. Hier siehst du die ursprüngliche Design und hier das Ergebnis.
So weit wie die Vortragenden musst du das natürlich nicht treiben

[mjustin]

Zitat von BUG:

Wenn du gleichzeitig empfangen (bzw. warten) und verarbeiten willst, wirst du Threads verwenden müssen.

Das stimmt, aber nur wenn beides (UDP Kommunikation und Verarbeitung für Protokollierung und Visualisierung) im gleichen Prozess stattfindet. Nachteil einer Queue im gleichen Prozess ist, dass mit dessen Abbruch alle noch nicht protokollierten oder visualisierten Daten in der Queue verloren sind.

Lösungen wären dann Speichern der UDP Kommunikation in eine Datenbank, oder Einstellen in eine IPC Queue wie Named Pipes (oder shared Memory Mapped Files). Solange das performant möglich ist, kann es synchron mit dem Empfangen und Quittieren der UDP Daten geschehen.

[BUG]

Zitat von mjustin:

Das stimmt, aber nur wenn beides (UDP Kommunikation und Verarbeitung für Protokollierung und Visualisierung) im gleichen Prozess stattfindet. Nachteil einer Queue im gleichen Prozess ist, dass mit dessen Abbruch alle noch nicht protokollierten oder visualisierten Daten in der Queue verloren sind.

Ok, ich korrigiere mich:

Wenn du gleichzeitig empfangen (bzw. warten) und verarbeiten willst, wirst du mehrere Prozesse (egal ob leicht- oder schwergewichtig) verwenden müssen.

Zufrieden?

Ich hatte mir als Weg für eine Nachricht etwa so etwas vorgestellt:

Code:

                            => BESTÄTIGEN (=> BESTÄTIGUNG PROTOKOLLIEREN)
EMPFANGEN => PROTOKOLLIEREN
                            => VERARBEITEN

Dabei werden die einzelnen Schritte in der Pipeline jeweils Threads, die eigenständig arbeiten.
Interessant wäre eventuell auch eine Dublikatserkennung, falls eine Bestätigung verloren geht.

Davon abgesehen ist es vielleicht wirklich eine gute Idee, die Visualisierung von dem Empfangen und Protokollieren in zwei separate Programme zu trennen.
Da kommt es irgendwann doch darauf an, wie wichtig ist die Latenz und die Robustheit wirklich nun ist.
Btw: Was passiert eigentlich bei der fremden Hardware, wenn da der Buffer voll läuft, weil niemand bestätigt?

[mjustin]

Zitat von BUG:

Zufrieden?

Mit Pipelines / Queues und Threads würde ich es auch lösen. Eventuell unter Einsatz von TMonitor, damit läßt sich auch das Producer / Consumer Pattern (wobei Producer und Consumer jeweils ein Thread ist) in Delphi leicht realisieren.