Hallo,

ich habe in mein Projekt für die Kommunikation zwischen Client und Server Indy 10 eingesetzt. Nach dem die Code sich vergrössert, hat auch folgendes problem angefangen.

Der Client und der Server kommunizieren, wenn sie Lust haben na, ja also die Daten gehen manchmal verloren. mach mal funktioniert es aber ohne Probleme.

woran kann das liegen?

Der Server liest:


und schickt:


Der Client liest:


und schickt :


EDIT:
Also, der Server bekommt die erste Nachricht und bearbeitet damit immer richtig. Aber wenn er antwortet, liest der Client mach mal nicht!

Wenn du die TCP-Komponenten benutzt können keine Daten verloren gehen, denn TCP fängt das selbst ab.

Was ich mir vorstellen kann ist, dass wenn du nur sehr wenige Bytes schickst, der WriteBuffer die Daten zwar enthält, sie aber nicht abgeschickt werden. Schau mal nach, ob es eine Funktion gibt, mit der man das Buffering abschalten kann bzw. den Buffer leeren kann.

Markus

Ja es gibt dafür in der Klasse TIdTCPClient.IOHandler.InputBuffer die methode Clear, und für das Versand in der Klasse IOHandler die Methode WriteBufferClear.
Leider auch mit der beiden keinen Erfolg!

Das Problem war genau so: Der Klient hatte die Antwort vom Server in InputBuffer, aber konnte er irgendwie nicht merken, um zu starten, zu lesen. erst Nach der Starten des procedur für die Abbau der Verbindung, merkte er, dass was in Inputbuffer ist. Nach Lesen wird ja sowieso die Verbindung getrennt. wie gesatgt, das komisches war, dass das nicht regelmässig aufgetroffen war, daher zu debuggen auch sehr schwierig war.

Nach dem ich den TCP-Client in ein Thread die Daten dauernd lesen lässt, funktioniert die Receiving wieder einwandfrei, da er immer wieder Inputbuffer lesen muss.

Ich bin mir nicht sicher aber ich glaube dein Sleep ist in deiner Execute Prozedur nicht so gut aufgehoben.
Ich weiß nicht ob das was damit zu tun hat oder ob das jetzt total falsch ist was ich sage aber ich habe das noch nie gesehen, da ein sleep reinzupacken.

In einem Thread sollte man lieber beide funktionen nutzen (sleep und application.processmessages). ohne sie würde auch funktionieren.
Aber das problem ist, wenn man nicht sleep reinpackt, sieht man am meistens übe %50 CPU-Auslastung in Task-Manager.
wenn man nur Sleep reinschreibt, dann blockiert die Anwendung manch mal Messagesverkehr, so wie bei TTimer kann OnTimer-Event gar nicht aufgerufen werden. dafür ist Application.ProcessMessages da. sie sehen so kleinigkeiten aus, aber haben richtig grösse Beeinflus für die Anwendung.

bei Java ist das ja auch so, wenn man Thread nutzt, sollte man auch ein Sleep reinpacken, um CPU-Auslastung zu verkürzen.

ich dachte auch, dass Indy dieses schon in Komponenten drin implementiert hat, da in TIDTCPServer Thread schon implementiert ist. war aber nicht so. vielleicht gibt es dafür auch eine spezielle methode in Indy, was ich übersehen habe. Aber das Timer-Problem hat mich getroffen, und menge zeit gebracht raus zu finden