IdUDPServer hat manchmal Datenverlust --> wie macht das Wireshark?

[Poolspieler]

Hallo OlafSt,
ich werde mir Deinen Ansatz genau anschauen - und das für mich zutreffende umsetzen. Danke!

Welches Argument spricht gegen Indy?
Bzw. welche Vorteile bietet UdpSockUtil?

Ich persönlich (aber das ist nur meine Meinung...) versuche immer so viel wie möglich mit den Bordmitteln von Delphi zu programmieren.
Ich nutze z.B. TChart Prof. Und da fängt das Problem schon an. Bei jeder neuen Delphiversion muss ich erstmal ein bis zwei Monate warten, bis es eine lauffähige Version von Steema für die neue Delphiversion gibt.
Für manche Projekte habe ich auch schon die TMS-Komponenten genutzt - da ist es nicht viel anders.

Deshalb versuche ich neue (und auch laufende) Projekte möglichst nicht mit Drittanbietern zu "belasten".

Viele Grüße,

Poolspieler

[OlafSt]

Die XE4-Implementation der Indy-UDP-Komponenten hat ne Macke. Habe das nicht weiter verfolgt (mir war das Fixen, neukompilieren und neu-Einbinden einfach zu kompliziert und ich hatte reichtlich Termindruck) und das ganze auf UdpSockUtil ungestellt. Die lassen sich problemlos von Version zu Version mitnehmen und gepflegt werden die auch noch

UdpSockUtils arbeitet direkt mit Sockets, direkter am System gehts kaum noch. Womit sich auch das mitschleppen dicker Units erübrigt. Aber - das ist jedem selbst überlassen.

Ansonsten bin ich da ganz bei dir - so wenig Fremdkomponenten wie möglich. Nur: Wirklich toll aussehende Anwendungen kriegt man damit nicht hin

[Poolspieler]

Hallo,
ich gebe Dir in allen Punkten Recht.
Was mit XE4 und Indy war, weiß ich nicht mehr. Aber irgend ein Update gab es damals... Aktuell nutze ich XE7.

Ich werde mein Glück mit Indy noch etwas weiter versuchen (weil es ja prinzipiell schon mal damit läuft) - optional kann ich mir mal UdpSockUtils anschauen.

Zitat:

Ansonsten bin ich da ganz bei dir - so wenig Fremdkomponenten wie möglich. Nur: Wirklich toll aussehende Anwendungen kriegt man damit nicht hin

Stimmt, deswegen nutze ich manchmal z.B. die TMS Komponenten...

Viele Grüße,

Poolspieler

[mensch72]

TChart 500T Datenpunkte... wenn die Verarbeitung / Anzeige teilweise nicht hinter her kommt, worauf kommt es denn dann in deiner Anwendung an?

Lieber mal ein paar Daten "weglassen" und dafür aber die Anzeige möglichst immer wieder "realtime" synchron halten, ODER eine Art "Gummiband" mit Dynamischen Puffer, welcher alles "irgendwann" dann eben verzögert darstellt und erst wenn wenig los mal wieder realtime synchron ist.

Fall 1 wird gerne bei Börsendaten genommen, denn da zählt letztendlich nur der aktuelle Kurs, wenn da mal einer zwischendurch fehlt ist das zwar nicht schön, aber kein Kurs ist da teils besser wie ein alter und nun schon falscher Kurs, von dem man nicht weiß, das er "alt" ist.

Meine Lösung: 3 "Block"-Puffer mit 4 möglichen States:"Write","Data","Read","Free"
- nur die StateZugriffe müssen synchronisiert werden, eine einfache kurze CriticalSection reicht hier, sind ja nur 1 oder 2 Variablenzugriffe zu schützen
- der Empfangsthread setzt synchronisiert den Puffer mit "WriteState" auf "DataState" und wechselt zyklisch den anderen Puffer von "Free/Data-State" auf "WriteState", ein Pufferwechsel wird dem WorkThread "signalisiert"
- der WorkThread setzt synchronisiert den Puffer mit "ReadState" auf "FreeState" und setzt den Puffer mit "DataState" auf "ReadState", dann werden die Daten des neuen "ReadState" Puffers beliebig langsam verarbeitet/angezeigt
- wenn die Anzeige sagen wir mal 3sec dauert und der Empfangsthread alle 1sec den Puffer wechselt, dann werden eben mal 2sec keine Empfangsdaten angezeigt, dann aber dafür sofort wieder die aktuellsten... für Visuelle Aufgaben ist das oft die eleganteste Lösung... für vollständige Datenlogs ist das aber ungeeignet, da muss es dann ein dynamischer FiFo sein. => Bei FiFo-Lösungen aber immer einen Empfangs-TimeStamp mit abspeichern! Nur so kann man bei der "späteren" Verarbeitung/Anzeige dann erkennen, das es alte Daten mit Zeitverzug sind

[Poolspieler]

Hallo mensch72,
die Anwendung ist eine Art Realtime-Oszilloskop auf bis zu 40 Kanälen.
Daten kann man leider nicht auslassen, da man ja sowohl den "Brumm", als auch das gleitende Mittel sehen will --> beides wird angezeigt. Die "Rohdaten" und ein gleitendes Mittel über X Werte.
Für die Anwendung sind auch einzelne Peaks (Ausreißer) wichtig.
Normalerweise macht es keinen Sinn, alle Kanäle gleichzeitig anzuzeigen - es kann aber Situationen (Fehlersuche) geben, in denen das schon Sinn macht.

Auch Deinen Lösungsansatz (vielen Dank dafür!) werde ich mir genau anschauen. Der klingt auch sehr gut.
Ich werde Euch mitteilen, welche Lösung für mich die sinnvollste war, bzw. welche ich umgesetzt habe!

Viele Grüße,

Poolspieler

[jaenicke]

Zitat von Poolspieler:

Aber woher weiß der Empfangsthread, ob der verarbeitende Thread die Daten schon abgeholt hat? Stichwort "Pufferüberlauf"...

Das muss man prüfen. Da mit den Atomic...-Funktionen die Zugriffe threadsicher passieren, ist aber keine weitere Synchronisation nötig. Und die atomaren Funktionen werden direkt in Assembler umgesetzt, das ist Compilermagic. So entsteht wenig Aufwand für die Synchronisation, auch wenn man noch weitere Sachen prüfen muss.

Zitat von Sir Rufo:

Hier mal so ein grober Entwurf, der aber schon tut

Auf den ersten Blick würde ich sagen, dass der Austausch der Pointer der beiden Queues in TMessageQueueThread<T>.Execute genau kurz nach dem Assemblerbefehl passieren kann, der den bisherigen Pointer in TReceiveThread.Execute holt. So würde dann Enqueue auf der Queue ausgeführt, die in DoProcessQueue verarbeitet wird. Oder sehe ich das falsch?