Sofware-Struktur für kontinuierliche UDP-Kommunikation

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