Hi,

ich bekomme laufend (Ok, ab und an mal...) diese Fehlermeldung:



Ich hab absolut keine ahnung woran das liegt, denn 9 von 10 mal kommt sie nicht...

Ich kann mir das nur so erklären das z.B. der Client was anfragt und dann mit ReadLN auf das ergebniss wartet, dieses aber nich schnell genug bekomtm da der Server ausgelastet is oder sonstwas...

Kann ich da irgendwas gegen machen???

Einfach nur mit Try-Except unterdrücken möchte ich diese Meldung keinesfalls!..

*guckt hilflos*

Au'revoir,
Aya~

PS: Geht um Indy TCP/IP Server + Client

TimeOuts setzen... habe ich mal gehabt, da fing der server an über 5 Minuten ne Hash einer Datei zu generieren, worauf die clients gelangweilt die verbindung getrennt haben und der server dann geheult hat, weil niemand mehr mit ihm sprechen wollt. Ergo vor solche langen Operation des Timeout erhöhen und hoffen, des man glücklich wird?

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

Wie erhöh ich denn das Timeout??? *guckt unsicher*

Wenn das mit dem Erhöhen des Timeouts nicht klappt, dann würde ich an deiner Stelle zu jedem verbundenen Client permanent ein Keep-Alive-Signal schicken, so daß dieser die Verbindung nicht kappt.
Dazu musst du ja nichts weiter tun, als vom Server aus alle paar Sekunden irgendein Datenpacket an den Client zu senden, so dass dieser realisiert das am anderen Ende der Server noch "lebt".Das machen AFAIK z.B. viele FTP-Programme so, damit die Verbindung nicht gekappt wird falls der User längere Zeit nichts tut (hier geschiehts halt nur in der anderen Richtung vom Client zum Server).

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

TCPClient.TimeOut? evtl. receivetimeout? Server the same

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

mhh... das einzige was ich gefunden habe, was etwas mit Timeout zutun hat is "ReadLnTimedOut"... aber das is was anderes

Stichwort: Readtimeout

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

mhh... haben wir verschiedene Jedi versionen oder so...???
Bei mir gibt's kein ReadTimeOut :/

TIdTCPConnection.ReadTimeout

Auszug aus der Hilfe dazu :


Ob das dein Problem löst wage ich allerdings zu bezweifeln (lass mich allerdings gerne eines Besseren belehren).Probiers mal mit dem Keep-Alive-Signal das ich erwähnt habe...

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

mhh...

welche Indy Version habt ihr??? (bzw, wo bekomm ich'n die neueste???)
Das ReadTimeout gibt es bei mir net

Au'revoir,
Aya~

Der Auszug oben stammt aus der Hilfe zu Version 9 der Indykomponenten.Die neuste Version ist 10(beta), allerdings wird diese (noch) nicht offiziell unterstützt.Die Projekthomepage findet sich hier : <a href='http://www.nevrona.com/Indy' target='_blank'>http://www.nevrona.com/Indy</a>

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Ach.. bei mir gibt's im Server.OnExecute event den ReadTimeout..



meintet ihr den???

Au'revoir,
Aya~

So, nu habbi V9 Installiert, da hab ich es jetzt auch beim Client

Hab das Timeout nu auf 5000 gestellt, jetzt kommt die Fehlermeldung nemmer *grinst fröhlich*

Danke

Au'revoir,
Aya~

mhh... ganz 100%ig weg ist die meldung immernochnet ...

Ab und zu kommt sie noch *seufzt*

An so nem Datenpacket kann es auch nicht direkt liegen, denn die Verbindung wird aufgebaut, daten werden hin und hergeschickt und dann wird sie wieder getrennt...

ca. so:



Hilfe~

Au'revoir,
Aya~

Kannst du denn einen Hardwarefehler 100%tig ausschließen?
Das Problem hatte ich woanders auch schon mal. Da hatte die Netzwerkkarte einen Schuß und hat für kurze Zeiten mal die Vebindungen getötet. Was dafür gesogt hatte, dass die Anwendung abgesemmelt ist. Tritt das Problem denn nur bei einem Rechner auf?