Neustart von idFTP nach EIdConnClosedGracefully?

[andreasm82]

Hallo,

ab und an kommt es vor, dass es bei langsamen Verbindungen, Verbindungsabbrüchen usw. zu einer Exception kommt.
Soweit ja kein Thema.
Jedoch funktioniert FTP nach einer Exception rein gar nicht mehr, da indy ftp dann grundsätzlich bei jedem Übertragungsversuch die EIdConnClosedGracefully Exception kommt.

Erst wenn ich das komplette Programm neustarte, funktioniert FTP auch wieder. Dies ist jedoch ein Unding, da das Programm dauerhaft laufen muss.

Wie kann ich nun im Fehlerfall Indy ftp neustarten, so dass sich dieses quasi wieder neu initialisiert und die alten Fehlermeldungen vergisst?

[DelTurbo]

http://www.delphipraxis.net/151089-i...bindungen.html

[andreasm82]

Genau, das war mein alter Thread :-)

Dieses Problem ist nun aber ein generelles. Es kommt auch vor, wenn Dateien auf dem Server nicht vorhanden sind und ich diese downloaden möchte, usw.

Ich habe vieles im Programm berücksichtigt, aber noch lange nicht alles. Und bei indy bin ich mir nie sicher, ob nicht doch einmal eine Meldung kommt, die ich bisher nicht abgefangen habe.

Daher die Frage, wie man indy ftp neustarten kann.

idftp.reinitialize hilft schonmal nicht. danach kommen noch immer die gleichen Fehlermeldungen bzgl. EIdConnClosedGracefully.

[DelTurbo]

Hmm,

nachdem ich den idFTP so geändert habe wie beschrieben, damit er auf jeden fall "wiederkommt", habe ich eigentlich keine probs mehr.

Allerdings sind meine sachen dynamisch. Das heisst ich erstelle sie zur laufzeit. Habe ich einen fehler, dann lösche ich den kram und lege es neu an.

Ich weiss ja nicht wie weit dein program ist. Aber vielleicht solltest du umsteigen. In dem FTP bereich hatte ich mal CleverComponents ausprobiert und war überracht wie einfach und stabil alles sein kann. Leider kann ich sie nicht nutzen da sie bei einigen sachen kein SSL macht.

Ansonsten machten die sachen einen guten eindruck. Noch ein nachteil ist, das es nichtmehr auf windows 2k läuft.

Leider ist mein projekt schon zu weit um ein Downgrade von Indy zu machen. Und ich habe schon zu viel zeit ins fixen von dem kram gesteckt. Im moment stecke ich schon wieder fest. Das hätte ich alles vorher wissen müssen.... :(

[andreasm82]

Stimmt, da hast du einen großen Vorteil, indem du alles per Laufzeit generierst. Dies mache ich leider nicht und nun ist es auch sehr schwer, alles umzustellen. Dies würde bei mir ein längerer Umstellungsprozess bedeuten.

Was ich bei Indy ftp auch seltsam finde, dass die EIdConnClosedGracefully Fehlermeldungen schon bei geringsten Änderungen auftreten können. Momentan benutze ich z.B. zum Beenden einer FTP Verbindung nur ein Quit.
Davor verwendete ich ein Abort und danach ein quit , dies führte ab und an auch zu den EIdConnClosedGracefully fehlern.
Auch ein Disconnect klappt nicht 100%ig.

Ich bin mir auch nicht 100%ig sicher, ob der passive Transfermodus und Übertragungsmodus Binary besser sind oder vielleicht sogar die Probleme machen. Es tritt alles eben recht sporadisch auf...

[DelTurbo]

Zitat:

Zitat von andreasm82 (Beitrag 1035121)

Auch ein Disconnect klappt nicht 100%ig.

Jo, das spinnt auch rum. Wenn du es mit True machst sollte es klappen.

Source.Disconnect(True);

Ich bin damals zweigleisig gefahren. Wenn du die Clever nimmst, brauchst du nur wenige änderungen in deinem programm. z.b. aus .Disconnect wird .Close usw.

Wäre ja vielleicht mal ein versuch wert.

[andreasm82]

Danke.

Besteht noch die Frage, was genau der Unterschied zwischen disconnect und quit ist.
Und was das True bewirkt, denn dies ist nirgends beschrieben.

Dokumentiert ist ja disconnect unter idftp nicht (Symbol Reference > Classes > TIdFTP Class > TIdFTP Methods ), ist wohl etwas übergeordnetes. Wobei dann die Frage ist, ob dem FTP Server dann auch das Beenden ordnungsgemäß signalisiert wird.

[DelTurbo]

Zitat:

Zitat von andreasm82 (Beitrag 1035310)

Besteht noch die Frage, was genau der Unterschied zwischen disconnect und quit ist.
Und was das True bewirkt, denn dies ist nirgends beschrieben.

Quit ist Disconnect ohne True.

Disconnect mit True sagt der gegenseite noch mit einem QUIT bescheid das schluss ist. Ohne True wird einfach zugemacht.

[andreasm82]

Seit ich disconnect(true) verwende, hatte ich mal keine Probleme mehr mit EIdConnClosedGracefully...

Aber man soll ja niemals nie sagen... Wer weiß, ob es nochmal auftritt.:roll:


Ich überlege gerade, eine neuere Tiburon Version zu nutzen, wobei ich im Changelog in der letzten Zeit keine Änderungen bzgl. FTP gesehen habe. Ist dann auch davon auszugehen, dass nichts am Indy ftp gemacht wurde? Es könnte ja sein, dass nicht alle bzw. nur die wichtigsten Änderungen im Changelog vermerkt werden.

[DelTurbo]

Freut mich das es klappt. Ob du updaten willst musst du selber wissen. Ich würde es mir gut überlegen. Mir ist keine "anlaufstelle" bekannt ist wo man bugs melden könnte, bzw. ein "richtiges" changelog sehen kann.

Zum updaten... Ich zieh mir ab und zu mal eine neue svn-version. Dann lass ich WinMerge drüberlaufen und sehe was sich geändert hat. Wenn eine änderung sinnvoll für mich ist, dann nehm ich die in mein 4017er mit rein. Zumal ich den nachteil habe das Delphi7 wohl nichtmehr richtig unterstützt wird.

Achso, am IdFTP wurde nix geändert. Ausser eine sache die mit FXP zu tun hat. Aber das ist für dich wohl eher uninteresant.

Gruss

[andreasm82]

Super, vielen Dank!

dann werde ich das Update besser noch lassen. Aber ich schaue ab und an mal in den Changelog herein.


Dass es keine richtige Anlaufstelle gibt, um bugs zu melden, ist schade.
Vielleicht sollte ich bugs einfach dem einen Entwickler melden, der ja auch hier im Forum aktiv ist?

[DelTurbo]

Zitat:

Zitat von andreasm82 (Beitrag 1036883)

Vielleicht sollte ich bugs einfach dem einen Entwickler melden, der ja auch hier im Forum aktiv ist?

Kannst du gerne versuchen. Ich habe das auch mehrmals gemacht. Es reichte nicht zu sagen da ist ein fehler. Ich musste jedesmal extra ein demo-prog machen. Es wurde auch kein Thread für diese sachen erzeugt, wo andere hätten mitlesen können bzw. auch was hätten zu sagen können. Das ging alles über PN. Das ist relativ zermürbend. Ich fix die sachen selber. Geht wesentlich schneller. Allerdings nur die sachen, die mir in meiner software auffallen.

Da der fehler den du hast nicht reprodizierbar ist, sehe ich schwarz. Ich hatte den fehler zwar auch, aber ich hab ihn einfach selber so gut es ging und meinen bedürfnissen nach rausgehohlt.

Gruss

[Assertor]

Hallo,

jetzt stolper ich über diese Thread und hier steht so viel falsches, dass geht ja langsam nicht mehr :shock:

Fangen wir mal ganz oben an:

Exceptions sind nicht nur Fehler, sondern eben Exceptions. Es macht auch einen Unterschied zu erwähnen, ob diese Silent Exceptions sind, d.h. nur in der IDE beim Debugger auftreten oder auch bei einer Ausführung ohne Debugger.

Zum Thema Indy, Exceptions und "Connection Closed Gracefully" gibt es seit vielen Jahren (über Google gut zu findende) Infos:
http://www.indyproject.org/KB/index....exceptions.htm
http://www.indyproject.org/KB/index....ngeidconnc.htm
http://www.swissdelphicenter.ch/en/showarticle.php?id=1

Die "Warnung" von DelTurbo zu Updates nach einer gewissen Revision halte ich für falsch, es ist einfach seine persönliche Meinung.

Was ich nicht stehen lassen kann:

Zwei Dinge, die DelTurbo ausführt, sind wissentlich falsch
1. Indy hätte keine Anlaufstellen
2. Es wären auf meinen Wunsch keine Threads zu den Themen erzeugt worden

DelTurbo selbst wollte damals PNs statt Threads, dies klingt in obigem Post nun anders... Über die Kommunikationsprobleme zwischen DelTurbo und mir und Erwartungshaltung an OpenSource von DelTurbo gibt es hier genügend Threads.

Desweiteren bin ich hier zwar vertreten, aber ich kann nicht jede PN dazu beantworten. Dies ergibt sich schon aus der Anzahl der Delphi und Indy Installation, hier in der DP auch aus der Anzahl der Forenmitglieder und Indy Themen.

Nun zu den Anlaufstellen:

Projektseiten und Issue Tracker
http://code.google.com/p/indyproject/issues/list
http://indy.codeplex.com/workitem/list/basic

Newsgroups
Bei Atozed (NNTP): news://news.atozedsoftware.com/
Bei Embarcadero (NNTP): embarcadero.public.delphi.internet.winsock
Bei Embarcadero (Web): https://forums.embarcadero.com/forum.jspa?forumID=74

Bugreports
Es gehört zum guten Ton in der Delphi bzw. Entwickler Community ein reproduzierbares Demo bzw. genügend Code für Bugreports bereitzustellen. Da muß auch ich durch, wenn ich etwas im QualityCentral bei Embarcadero als Delphi-Fehler erfasse. Informationen über Betriebssystem, Delphi Version, Testumgebung etc.pp. gehören auch dazu.

Für offizielle Bugreports mit Delphi ausgelieferter Indy Versionen, bitte das QualityCentral nutzen.

Dort werden Bug Reports auch von Embarcadero gelegentlich bewertet. Viele werden auch geschlossen, weil die Qualität einfach zu schlecht ist (eben kein Quelltext, keine deutliche Sprache und/oder kein Demo). Soviel zum Thema mühselig - so ist das nunmal...

Webseite
Die Webseite (http://indyproject.org/) ist bekannt, aber ebenso wie bei den Kollegen vom JEDI Team hoffnungslos veraltet. Dies liegt an mangelnder Unterstützung durch Freiwillige. Summa summarum ist Indy ein OpenSource Projekt mit starker gegenseitiger Abhängigkeit zu Embarcadero Delphi & C++ Builder. Das Team ist inzwischen bei uns aber leider sehr klein.

Das Problem mit Connection Closed Gracefully
Änderungen wie von DelTurbo vorgeschlagen, z.B. die Try-Catch-A, verdecken nur ein anderes Problem. Dies ist nicht zu empfehlen, da ja die Möglichkeit besteht diese Exception mit Grundlagenwissen Delphi abzufangen und die Komponente z.B. neu zu instanzieren.

Übrigens: Bei einer Designtime Komponente läßt sich z.B. mit GExperts IDE Add-In per Mausklick die Design- in eine Runtime-Komponente "verwandeln". Dann steht einer Wiederverwendung doch nichts im Weg.

Das aktuelle Problem ist bekannt, tritt sporadisch auf. Erfasst ist ein ähnlich gelagertes Problem z.B. bereits hier:
http://code.google.com/p/indyproject...il?id=81&can=1

Sehr zu empfehlen ist der Thread "Connection closed gracefully redux" von unserem Team Mitglied Remy Lebeau (TeamB) im EMBT Forum:
https://forums.embarcadero.com/messa...ssageID=166101

Es also schon helfen, nach dem Disconnect den Input Buffer zu leeren (egal ob HTTP oder FTP Komponente):

Delphi-Quellcode:

if Assigned(IOHandler) then IOHandler.InputBuffer.Clear;

Delphi 6 & 7
Im Moment liegt die Priorität bei der Entwicklung auf aktuellen Versionen, insbesondere im Bereich Vereinfachung und besserer Support für Unicode.

Delphi 6 & 7 laufen zu 99,9% nicht anders als Delphi 2009 & 2010. Die Probleme, die es gibt beziehen sich auf die Komponenten Packages. Das wird später gefixt, da hier sowieso eine größere Änderungen kommen soll.

Hier im Forum waren trotzdem genügend in der Lage, dies Installationsprobleme selbst zu lösen und nutzen aktuellste Revisionen von Indy mit D7 (Components-By-Code geht sowieso).

Zum Projekt
Leider kann bei einer so großen Library wie den Indys vieles nicht "mal eben so" gefixt werden, da viele Änderungen andere Teile in Mitleidenschaft ziehen könnten. Das Prinzip "1 Bug gefixt, dafür 10 neue offen" bringt ja niemandem etwas. Es gibt gerade bei WinSocks einige Fallstricke, über die Entwickler die mal eben eine "Internet Kompo" bauen wollen, immer wieder fallen.

Die vergangenen Probleme von DelTurbo beziehen sich auf Komponenten, IRC und FXP (FTP Server-zu-Server), die leider keine hohe Verbreitung bei unseren Nutzern haben und deswegen auch keine hohe Priorität. Dafür fehlt einfach die Zeit und die Manpower. Sie sind eine einfache Beigabe, insbesondere weil weder das eine noch das andere einer Normierung unterliegt. Bei FTP, HTTP, SMTP etc gibt es ja im Gegenzug die bekannten RFCs.

Seit kurzem haben wir alle offenen Bugs im internen Bugtracker von Embarcadero schließen können, darüber freue ich mich zumindest sehr.

@Andreas: Ich hoffe, das hat dir etwas weiter geholfen. Melde Dich gerne bei Google Code oder CodePlex an, um unseren Issue Tracker zu füllen. Das gilt natürlich auch für alle anderen.

Gruß,
Assertor

[andreasm82]

Vielen Lieben Dank für die ausführliche Antwort.

Ich habe das "if Assigned(IOHandler) then IOHandler.InputBuffer.Clear;" mal hinzugefügt und werde es testen.
Ich melde mich dann die Tage nochmal, ob es problemlos funktioniert oder doch noch Probleme auftreten sollten.

Zitat:

Delphi 6 & 7 laufen zu 99,9% nicht anders als Delphi 2009 & 2010. Die Probleme, die es gibt beziehen sich auf die Komponenten Packages. Das wird später gefixt, da hier sowieso eine größere Änderungen kommen soll.

Gut zu wissen, denn ich wollte gestern das aktuelle Indy tiburon testen, doch ich kriege es unter Delphi 7 nicht zum laufen. Die Installation der Packages klappt nicht auf dem gewohnten Weg.

[andreasm82]

Och mann... der Hinweis mit dem leeren des Input Buffers funktioniert bei FTP.
Ich hatte seitdem keine Probleme mehr.

Doch bei HTTP tritt dies noch immer auf:

Zitat:

10.08.2010 08:52:29 Downloading http page from 192.168.31.8
10.08.2010 08:52:29 Error DownloadHTTPPage: EIdSocketError:Socket Error # 10054
Connection reset by peer.

Hier mein momentan verwendeter Code:

Zitat:

HttpPageContent := form1.idhttp1.Get(WebPage);

form1.idhttp1.Disconnect(true);
if Assigned(form1.idhttp1.IOHandler) then form1.idhttp1.IOHandler.InputBuffer.Clear;

hierbei habe ich das ganze schon mit und ohne dem disconnect,
mit und und ohne inputbuffer.clear probiert...

[andreasm82]

Hallo,

auf dem FTP Server fand ich eben zufällig:

Indy10Tiburon_4448.zip
Indy10_4452.zip

Ist die Indy10_4452 eine neue, aktualisierte, stabile Version?
Was sagt die Zahl 4452 aus ? Versionsnummer?
Dann wäre Indy10_4452 ja aktueller als Indy10Tiburon_4448 oder?
Welche Änderungen gibt es in Indy10_4452 gegenüber der letzten 10er version?
(im changelog steht nur etwas von merged usw)

Ich nutze ja derzeit noch die 4017 von Tiburon. Und scheinbar hängt sich mein Programm damit noch ab und an auf. Ich würde daher gerne auf was stabiles wechseln.

[Assertor]

Hallo Andreas,

Zitat:

Zitat von andreasm82 (Beitrag 1056195)

auf dem FTP Server fand ich eben zufällig:

Indy10Tiburon_4448.zip
Indy10_4452.zip

Ist die Indy10_4452 eine neue, aktualisierte, stabile Version?
Was sagt die Zahl 4452 aus ? Versionsnummer?
Dann wäre Indy10_4452 ja aktueller als Indy10Tiburon_4448 oder?
Welche Änderungen gibt es in Indy10_4452 gegenüber der letzten 10er version?
(im changelog steht nur etwas von merged usw)

Ich nutze ja derzeit noch die 4017 von Tiburon. Und scheinbar hängt sich mein Programm damit noch ab und an auf. Ich würde daher gerne auf was stabiles wechseln.

Wir hatten gerade in den letzten Tagen den Merge gemacht, d.h. ja die Indy10_4452.zip ist aktueller. Der Tiburon Branch wird etwas später gelöscht (später, damit Nutzer Ihre Links anpassen können). Etwas offiziell stabiles gibt es nicht, weder von uns noch von Embarcadero. Das sieht man ja nicht zuletzt daran, dass die Shipping Versionen von Indy in D2009 oder D2010 Bugs enthalten, die bei uns schon gefixt sind (z.B. E-Mail Attachment Namenproblem in der D2009 Indy Version, in D2010 z.B. das FTP Binary-Mode Problem).

"Irgendwann" wird es wieder etwas offiziell stabiles geben, aber da ist noch viel zu tun. Ist natürlich auch die Frage, wie definiert sich stabil. Source ohne Bugs gibt es ja wohl nirgendwo (siehe bspw. QC), aber wenn stabil in Richtung besser getestet (automatisiert) und mit Setup/Installer geht: das ist geplant.

Ich hoffe, die Info hilft Dir weiter :)

Viele Grüße,
Assertor

[andreasm82]

Vielen Dank!

[andreasm82]

Zitat:

if Assigned(form1.idhttp1.IOHandler) then form1.idhttp1.IOHandler.InputBuffer.Clear;

So etwas benötige ich auch für die Indy ICMP Client komponente, mit der ich Gegenstellen anpingen möchte. Habe es aber nicht herausgefunden.

Dummerweise kommt es nämlich auch mit dieser Komponente alle paar Tage mal vor, dass das Programm die Fehlermeldung bzgl. connection closed gracefully ausspuckt. Es hilft dann nur ein Neustart des Programms... dies möchte ich jedoch abfangen.

Kennt jemand so einen Befehl?

[andreasm82]

EIdConnClosedGracefully Meldungen kommen mit neueren Indy Versionen inzwischen nicht mehr. Das scheint intern behoben zu sein.

Was jedoch merkwürdig ist:
Ab und an kommt beim Herunterladen einer Datei über FTP die Meldung "EIdReplyRFCError:Syntax error in parameters or arguments".
Aber es handelt sich jedes mal um den gleichen Aufruf und die gleiche Datei.
Ich nutze derzeit Indy10_4571

Woran könnte dies liegen?

Auszug aus meiner Logdatei des Programms:

Code:

28.02.2011 11:22:27 FTP connected to 192.168.31.12
28.02.2011 11:22:31 Downloading m110228.txt...
28.02.2011 11:22:32 Error DownloadData: EIdReplyRFCError:Syntax error in parameters or arguments.

[andreasm82]

Suche noch immer nach einer Lösung für das Problem "EIdReplyRFCError:Syntax error in parameters or arguments"

Ich habe folgendes festgestellt:

- Lade ich von einem FTP Server daten, klappts

- Lade ich jedoch zuerst von einem, dann direkt danach von einem anderen FTP Server daten, so kommt die Meldung ab und an.


In meinem Programm ist er, wenn die Meldung erscheint, an dieser Stelle:

// Auflisten
IdFTP.list(listbox.items,'',false);

// Prüfen, ob etwas in Liste
if listbox.items.count > 0 then <----- Da kommt die Meldung