Sofware-Struktur für kontinuierliche UDP-Kommunikation

[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?