Indy FTP: Probleme mit sehr langsamen Verbindungen

[andreasm82]

Hallo Leute,

wenn ich per FTP Daten von einem Server herunterladen mag, bei dem die Verbindung sehr langsam ist (z.B. funkverbindung, richtfunk, usw.) und die Verbindungsrate unter 2 kB/sek ist,
hängt sich indy ftp scheinbar auf.

Ich habe alle verfügbaren Timeouts im indy ftp auf klare Werte gesetzt, und dennoch hängt das Programm.
erst wenn ich den VPN Tunnel in das Zielnetzwerk beende, wird auch die Ftp verbindung gekappt.

Wie kann ich dies nun machen, dass indy ftp nicht stundenlang (ja wirklich, mehrere Stunden!) probiert,
eine Datei von gerade mal 50 Kbyte herunterzuladen ?

Folgende Werte verwende ich momentan:

Delphi-Quellcode:

      IdFTP.ReadTimeout := 30000;
      IdFTP.TransferTimeout := 30000;
      IdFTP.ConnectTimeout := 30000;
      idFTP.ListenTimeout := 10000;

[andreasm82]

Hmm noch keine Ideen? Fehlen euch noch Infos?

Ich setze übrigens Indy10 ein von ftp://indy.fulgan.com/ZIP/indy10.zip . Letztes Update laut Changelog Ende 2009.

[mjustin]

Zitat:

Zitat von andreasm82

Hmm noch keine Ideen? Fehlen euch noch Infos?

Ich setze übrigens Indy10 ein von ftp://indy.fulgan.com/ZIP/indy10.zip . Letztes Update laut Changelog Ende 2009.

Der Indy Tiburon Branch ist die aktuelle Entwicklungsversion mit sehr häufigen Updates, ftp://indy.fulgan.com/ZIP/IndyTiburon.zip

[andreasm82]

stimmt, nur bin ich nicht sicher, ob das Problem in Tiburon behoben ist und ich mir nicht evtl. andere Probleme einfange. Denn das System muss bei mir dann rund um die Uhr laufen.


Aber vielleicht weiß ja jemand von euch, ob dieses Problem evtl. in Tiburon behoben ist? dann würde ich es mal ausprobieren.

[DelTurbo]

Hi,

was heisst denn "hängt sich auf"??? Da ist doch der quellcode bei. Vielleicht kannste das eingrenzen, und mal sagen was du mit "hängt sich auf" meinst.

Auf eine quasi unstable version würde ich nicht gehen. Da kannste dir dann ganz andere sachen "einfangen". Was du aber machen könntest wäre es mal unter Indy9 übersetzen wenn du die möglichkeit hast. Nach meinen erfahrungen lief/läuft das stabieler.

Gruss

[andreasm82]

Aufhängen heißt, das Programm hängt an der Stelle, an der es eine Datei herunterladen soll.

Die Datei ist gerade mal 50kbyte groß und das Programm probiert diese stundenlang herunterzuladen. Ich habe auch keine besonderen Sachen einprogrammiert, d.h. er versucht die Datei lediglich 1x mal herunterzuladen.

Wenn ich dann aber den VPN Tunnel kille, so merkt das Programm das und wird wieder stabil.

[DelTurbo]

Sorry, aber ich frage nochmal nach. Wie spielt es sich denn ab.

Wieviel lädt er? 5k oder garnix?
Wenn der da "hängt", versucht er weiterhin das file zu laden? Also ist traffic da?
Steht die TCP-Verbindung auf beiden seiten noch?
Steht es auf Binary?

Kannst du den fehler reproduzieren? Also wenn du z.b. den stream auf 1k speed begrenzen würdest.

Hast du vielleicht die möglichkeit das mal unter Indy9 zu übersetzen?

Gruss

[andreasm82]

Zitat:

Wieviel lädt er? 5k oder garnix?

Er läd einen Teil, aber dann gehts nicht mehr weiter.

Zitat:

Wenn der da "hängt", versucht er weiterhin das file zu laden? Also ist traffic da?

So genau habe ich das nicht untersucht, wüsste auch nicht, wie ich dies dann überprüfen könnte, ob die Daten,
die über das Netzwerk übertragen werden, zu dieser Datei gehören. Evtl. müsste ich mal mit wireshark ran.

Zitat:

Steht die TCP-Verbindung auf beiden seiten noch?

Vermutlich ja. Denn erst wenn ich den VPN Tunnel schließe, tut sich im Delphi Programm wieder etwas - es gibt einen Übertragungsfehler.

Delphi-Quellcode:

Steht es auf Binary?

Nein, Ascii. Da es nur .txt Dateien sind.

Zitat:

Also wenn du z.b. den stream auf 1k speed begrenzen würdest.

Wie kann man dies mit Indy machen?


Ich habe soeben probiert, das neue Tiburon zu installieren, bin aber daran gescheitert.
Fulld7.bat ausgeführt, Pfad im Delphi zu dem D7 Ordner angegeben, IndySystem70.bpl als Package versucht zu installieren. Klappt nicht, da nur Entwurfszeit Package. Und alle Komponenten manuell hinzufügen, ist ja extrem viel Arbeit. In der alten Version klappte dies besser.

[Luckie]

Verstehst du unter "aufhängen" dass dein Programm nicht mehr reagiert? Dann solltest du das ganze eventuell mal in einen Thread auslagern.

[DelTurbo]

Hi,

wenn du auf so eine "unstable" version gehen willst, muss du entweder die 4017 oder 4032 nehmen. Alles was danach kam oder kommt, geht NICHTMEHR auf D7. Ich habe das schonmal hier im board angesprochen, aber es scheint leider keinen zu interesieren.

Nach meinen erfahrungen sind in der 4017 am wenigsten fehler drin.

Nochmal zu deinem prob. Bitte stell es mal auf binary. Das hat den vorteil das indy die "finger" davon lässt und nicht versucht es zu wandeln.

Soweit ich weiss hat indy nicht die möglichkeit den speed zu begrenzen. Das müsstest du entweder selber reinmachen, oder aber ein externes tool nutzen. Es wäre halt von vorteil dann könnte man den fehler gezielter suchen.

Das die verbindung auf BEIDEN seiten noch besteht solltest du vor dem killen mal genau nachsehen. Einfach mit TCPView. Auch wäres es wichtig zu wissen ob überhaupt noch traffic das ist. Vielleicht hängt indy ja in irgendeiner schleife fest.

So, lange rede, kurzer sinn. Erstmal mit Binary probieren. Dann denn rest.

Gruss

PS.: Wenn du nicht weisst wie du an die 4017 dran kommst (per SVN) dann sag bescheid, ich lade es dir hoch.

EDIT: Nun hatte ich es wieder vergessen. Man(n) wird halt alt. Indy hat oft probs mit dem SendCmd bei nicht "sauberen" verbindungen.

[andreasm82]

Wenn,dann müsste ich den Transfertype im Programmablauf umstellen, da ich sowohl Windows als auch Linux Systeme abfrage.

Zumindest bei den Linux-Systemen wäre Binary kein Problem, wenn da nicht die Compiler-Fehlermeldung wäre:

Zitat:

[Fehler] FTPUnit.pas(66): Undefinierter Bezeichner: 'ftBinary'
[Fehler] FTPUnit.pas(68): Undefinierter Bezeichner: 'ftASCII'
[Fataler Fehler] FTPUnit.pas(24): Verwendete Unit 'FTPUnit' kann nicht compiliert werden

Delphi-Quellcode:

if (TurbineController = 'CX')
then
  IdFTP.TransferType := ftBinary
else
  IdFTP.TransferType := ftASCII;

Und momentan ist die geschwindigkeit wieder hoch, so dass ich es nicht testen kann. Ich müsste mal schauen, wie ich die Geschwindigkeit irgendwie drosseln kann.

[DelTurbo]

Hi,

deklariert ist es in der IdFTPCommon. Also die einfach in die uses nehmen und es passt.

Gruss

[andreasm82]

Zitat:

deklariert ist es in der IdFTPCommon. Also die einfach in die uses nehmen und es passt.

Super, so klappt es.


Mit der anderen Version 4017 und der Geschwindigkeitsbegrenzung werde ich die Tage mal schauen.

[andreasm82]

Zitat:

Nach meinen erfahrungen sind in der 4017 am wenigsten fehler drin.

Momentan bin ich diese Version am testen.

Bei langsamen Verbindungen oder Abbrüchen hängte sich das Programm bisher mal noch nicht auf. Es erkannte nun einen socket Error (timeout oder connection reset by peer).
Hoffen wir mal, dass es so bleibt :)

Ist es erlaubt, dass ich diese Version auf meiner Homepage spiegele und als Download bereitstelle?
Denn die Installation war diesmal so problemlos, das konnte ich kaum glauben!
Compiliert, in delphi die beiden indy bpl Dateien eingebunden, fertig!
Wenn ich überlege, was ich mir bisher einen Stress gemacht hatte, da es nicht funktionierte (alte indy dateien gesucht und gelöscht,
Pfade im delphi überprüft, tempordner geleert, in delphi mehrmals in den optionen geschaut, .... ).
und diesmal gehts direkt.

[DelTurbo]

Freut mich das es geklappt hat.

Ob du das über eine WebPage weitergeben darsft weiss ich nicht. Da müsstest du dich mit den Indy-leuten in verbindung setzen. Das DOC-File was ich beigepackt hatte..... leider weiss ich nichtmehr ob das aus mehreren quellen stammt. Schon garnicht aus welchen.

Aber das kannst du ja quasi "abschreiben" und gleich ins deutsche übersetzen.

Gruss

[H4ndy]

Die Indies stehen unter einer modifizierten BSD- oder der MPL-Lizenz.
Damit kannst du damit machen was du willst, solange du es nicht als deinen eigenen Code ausgibts ("allows you to do almost anything you want with Indy, provided you provide proper attribution" - Quelle).

Du kannst das Paket also bedenkenlos auf deiner Homepage zum Download anbieten.

[andreasm82]

Zitat:

Nach meinen erfahrungen sind in der 4017 am wenigsten fehler drin.

Schade, diese Version scheint auch etwas buggy zu sein.

wenn ich mein Programm mehrere Tage am Stück laufen lasse, so kommt es irgendwann vor, dass ich bei FTP oder HTTP Verbindungen
scheinbar grundlose Fehlermeldungen bekomme. Es ist dann IMMER:
Fehler: EIdSocketError:Socket Error # 10054 Connection reset by peer.

Sobald ich das Programm neustarte, funktioniert wieder alles.
Am Programm selbst habe ich bzgl. FTP und HTTP nichts geändert.

In der Vergangenheit trat dies mit anderen Versionen der Indy Bibliotheken nie auf.

Was tun?

[DelTurbo]

Hi,

das problem kenn ich. Das kannst du selber fixen. Da du ja teilweise keine "sauberen" verbindung hast passiert es in idFTP.pas im SendCmd. Da ein try/except rein und es sollte behoben sein. Es gibt noch eine stelle wo er abkackt. Aber ich kann dir im moment nicht genau sagen wo das war. Leider kann ich dir keine exakte zeilennummer nennen, da ich mein idFTP schon zu sehr geändert habe damit es läuft.

Wenn du mit Indy arbeitest und besonders wenn du programme hast die einfach nur laufen sollen (24/7, rund um die Uhr) wäre es gut wenn du dir madException drauf machst. Dann siehst du auch genau wo der fehler passiert.

Ich habe meins so abgeändert, das er aufjeden fall "wiederkommt". Dann resette ich die verbindung indem ich sie trenne und neu verbinde.

[andreasm82]

Zitat:

Da du ja teilweise keine "sauberen" verbindung hast passiert es in idFTP.pas im SendCmd

Sorry, dass ich hierzu nochmal Nachfrage. Sendcmd wird in der idftp.pas zig mal aufgerufen, an welcher Stelle sollte das try except am besten hinein?

Vielen Dank!

[DelTurbo]

Wieso "sorry". Dafür ist das forum doch da. Anbei die änderung die ich bei mir gemacht habe. Müsste so ca. bei zeile 2000 sein. Ich hoffe das hilft dir weiter.

Gruss


Edit ich habe nun mal ein Compare gemacht. An folgenden stellen ist es enthalten. Mit diesen änderungen sollte es auf jedenfall wiederkommen. Wichtig ist das du dann beide Connections trennst und neu verbindest. Anders bekommt man (bzw. ich) das nichtmehr auf die füsse.

Delphi-Quellcode:

procedure TIdFTP.SendTransferType(AValue: TIdFTPTransferType);
var
  s: string;
begin
  s := '';
  case AValue of
    ftAscii: s := 'A';      {do not localize}
    ftBinary: s := 'I';     {do not localize}
    else
      raise EIdFTPUnsupportedTransferType.Create(RSFTPUnsupportedTransferType);
  end;
  try
    SendCmd('TYPE ' + s, 200); {do not localize}
  except
  end;
end;

Delphi-Quellcode:

procedure TIdFTP.DisconnectNotifyPeer;
begin
  if IOHandler.Connected then begin
    try
      IOHandler.WriteLn('QUIT');      {do not localize}
    except
    end;
    IOHandler.CheckForDataOnSource(100);
    if not IOHandler.InputBufferIsEmpty then begin
      GetInternalResponse;
    end;
  end;
end;

Delphi-Quellcode:

procedure TIdFTP.SendInternalPassive(const ACmd: String; var VIP: string;
  var VPort: TIdPort);
var
  i, bLeft, bRight: integer;
  s: string;
begin
  SendDataSettings;
  try
    SendCmd(ACmd, 227);      {do not localize}
  except
  end;

Delphi-Quellcode:

procedure TIdFTP.SendPBSZ;
begin
  {NOte that PBSZ - protection buffer size must always be zero for FTP TLS}
  if FUsingSFTP or (FUseTLS = utUseImplicitTLS) then begin
    //protection buffer size
    try
      SendCmd('PBSZ 0');  {do not localize}
    except
    end;
  end;
end;

Delphi-Quellcode:

procedure TIdFTP.SendDataSettings;
begin
  if FUsingSFTP then begin
    if not FUsingCCC then begin
      SendPBSZ;
      try
        SendPROT;
      except
      end;
      if FUseCCC then begin
        FUsingCCC := (SendCmd('CCC') div 100) = 2; {do not localize}
        if FUsingCCC then begin
         (IOHandler as TIdSSLIOHandlerSocketBase).PassThrough := True;
        end;
      end;
    end;
  end;
end;

[andreasm82]

Problem scheint gelöst zu sein :)


Dennoch noch die Frage, was genau die Unterschiede zwischen

IdFTP.ReadTimeout (gesetzt auf: 30Sek)
IdFTP.TransferTimeout (30Sek)
IdFTP.ConnectTimeout (30Sek)
idFTP.ListenTimeout (10Sek)

sind. Wann wird welcher Timeout gestartet?

Ich habe gerade folgendes getestet:
- FTP Verbindung aufgebaut
- Transfer einer Datei gestartet
- Netzwerkkabel während der Übertragung abgezogen
- Nach ca 60 Sekunden erhalte ich ( Error: EIdSocketError:Socket Error # 10065)

Wie kommt das Programm nun auf 60 Sekunden?
Aus welchen Timeouts setzen sich diese 60Sek zusammen? Einfach gesetztes Read + Transfertimeout ?

[andreasm82]

Ich dachte, es wäre gelöst. Doch leider trat es wieder bei einer sehr langsamen Verbindung auf.

Mein Programm hängt nun schon 10 Min bei dem FTP connect Befehl und es geht nicht weiter.
Da frage ich mich, wieso es die Timeouts gibt, die ich auf 30Sekunden einstelle, aber diese nichts bewirken...

Auch hängte das Programm beim FTP Get Befehl über 15min !


Gibt es noch weitere Befehle oder Timeouts, die zu setzen sind?