vielleicht kann mir Delphi-Dau ja einer helfen.
Ich versuche gerade eine LowLevel Kommunikation zu einem Stück Hardware mit dem proprietären Protokoll des Herstellers umzusetzen.
Mein erster Versuch mittels ClientSocket und PHP-Skripten war nur teilweise von Erfolg.
Irgendwann kommt das Handshake durcheinander.
Also habe ich mich jetzt an Indy versucht und nutze eine Instanz vom Typ TIdTCPClient in meinem IO-Modul.
Grundsätzlich klappt das auch ganz gut, die Kommunikation ist stabil und das komplette Handling auf TCP Ebene inkl. Handshake ist in dem IO-Modul untergebracht.
Da ich aber kein Event gefunden haben, welches ausgelöst wird wenn im Buffer meines IOHandler Daten liegen, arbeite ich mit einem Timer der den Buffer prüft.
Nun bin ich darüber gefallen, dass der IPS ClientSocket keinen (sichtbaren?) Timer erzeugt.
Vermute aber mal das Der auch auf TIdTCPClient basiert ?
Bin ich mal wieder zu blind um das Event zu finden?
Und kann ich das überhaupt nutzen im SDK ?
Ist halt etwas unschön alle 500ms über einen Timer den Buffer zu prüfen.
Willst du das Modul für IPS bauen? Dann nutz doch den ClientSocket als I/O für dein Modul. Dafür sind die ja da. Dann bekommst du die Daten automatisch in dein Modul und schickst wieder bei Bedarf Daten an den ClientSocket raus
Ja das ist schon ein Modul für IPS zumindest ein Halbes.
Ich hatte ja auch erst überlegt den ClientSocket zu nutzen…
Aber das ist auch problematisch, da an einer IP n-mal Geräte hängen können und ich nicht den Datenstrom über 1-n Instanzen des Devices syncronisieren möchten, vom Handshake ganz abgesehen.
Also war die Idee einen eigenen Socket als IO-Device zu erstellen und über eigene Interfaces mit den Childs die Daten auszutauschen. (Alternative wäre noch ein Splitter zwischen ClientSockt und Devices gewesen).
Das IO-Modul läuft auch schon, bis auf ein paar Funktionen (Reconnect / Reregister am Server der Gegenseite etc.)
Mir ging es jetzt darum wie ich auf ankommende Daten am einfachsten prüfe.
Da die Gegenseite auch sporadisch Nachrichten versendet, hatte ich erst einen Timer per RegisterTimer eingesetzt.
Jetzt bin ich auch einen eigenen Timer auf TTimer umgestiegen.
Ob das jetzt optimal ist… ist meine Frage.
Mit Threads habe ich mich bisher noch gar nicht beschäftigt und die Events des IOHandler in Indy sind wohl eher buggy (wenn ich die Beiträge in einigen Foren so lese).
Michael
Ich gehe mal auf deine anderen Fragen nicht ein, da ich auf die saubere Lösung bestehe
Und die hast du auch genannt:
Alternative wäre noch ein Splitter zwischen ClientSockt und Devices gewesen
Worum hast du dich dagegen entschieden? Das ist die Lösung die auch IPS nutzt, und der ClientSocket nimmt dir ja alle Arbeit ab. Du musst im Splitter nur die Synchronisierung machen. Übrigens gut, dass du daran denkst. Oft wird das gerne mal vergessen Falls ich dir da also irgendwie Input/Demo-Quellcode schicken kann: Sag bescheid!
Also Demo-Quellcode ist ja immer gut. Immerhin ist ja man Lernwillig.
Habe auch die Woche noch über eine Lösung mit dem ClientSocket nachgedacht.
Ich habe keine Möglichkeit gesehen, zu verhindern dass der User einfach die IP ändert und auf Übernehmen klickt.
Allerdings kann auf diese Veränderungen ja reagieren und ggfls. übersteuern (z.B. den Port immer fest wieder einstellen).
Das ist aber zu spät, der Socket zur alten IP/Port ja schon zu und ich kann nun die Kommunikation zum Server nicht mehr sauber beenden
Das meine ich auch im Sinne von ‚beiden‘ Seiten sauber.
Inzwischen ist das Interface auch soweit Stabil und belastet mein Testsystem im idle nicht mehr.
Habe mich noch mehr mit dem Themen Threading, CriticalLocks, Events und Indy beschäftigt, und bin jetzt bei einen eigenen Thread zum Empfangen gelandet.
zumindest ein Halbes.
