FTP FTP-Client funktioniert nicht bei Modem-Verbindungen

[gschmi01]

Hallo

Ich verwende die Klasse FTPClient von Commons Net (3.0.1) für FTP-Dateitransfer.
commons.apache.org

Das funktioniert gut, solange die Verbindung schnell genug ist, z.B. 150 kbit/s und mehr. Mit einer Modem-Verbindung von 56 kbit/s kann ich mit dem FTP-Server in Verbindung treten und die Dateiliste abrufen, aber es treten 3 Fehlerzustände auf (Stack-Traces siehe unten):
- Nach dem Hinaufladen einer Datei zum Server gibt es ein Read Timeout (die Datei ist aber vollständig angekommen)
- Herunterladen einer Datei (auch nur 1 kByte) ist nicht möglich
- Beim Logout gibt es wieder ein Read Timeout

Andere FTP-Programme kommen mit einer Modem-Verbindung problemlos klar (WS-FTP etc.).

Möglicherweise könnte eine passende Einstellung der verschiedenen Timeouts das Problem lösen. Leider bin ich kein Spezialist in FTP oder Netzwerk-Verbindungen im Allgemeinen. Die derzeitigen Einstellungen sind:

• DefaultTimeout = 0 (default)
• SocketTimeout = 0 (default)
• ConnectTimeout = 0 (default)
• ControlKeepAliveTimeout = 300 seconds, entsprechend dem Beispiel in der API
• ControlKeepAliveReplyTimeout = 1000 milliseconds (default)

Kennt jemand eine passende Einstellung der Timeouts oder eine andere Lösung für mein Problem?

PS:
Ich habe bereits auf Commons Net gepostet, aber außer einer Rückfrage kam nichts.



1. Datei zum Server hinaufladen

Zeile 590 input = new FileInputStream(pathFilename);
Zeile 591 result = ftpC.storeFile(serverFilename, input);

Mit der Zeile 591 wird eine Ausnahme geworfen und mit diesem catch-Block abgefangen:
catch(SocketTimeoutException ste) {
text1 = ste.getMessage();
text2 = ste.getCause();
ste.printStackTrace();
}

text1 = Read timed out
text2 = null
printStackTrace():
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(Unknown Source)
at sun.nio.cs.StreamDecoder.readBytes(Unknown Source)
at sun.nio.cs.StreamDecoder.implRead(Unknown Source)
at sun.nio.cs.StreamDecoder.read(Unknown Source)
at java.io.InputStreamReader.read(Unknown Source)
at java.io.BufferedReader.fill(Unknown Source)
at java.io.BufferedReader.read(Unknown Source)
at org.apache.commons.net.io.CRLFLineReader.readLine(CRLFLineReader.java:58)
at org.apache.commons.net.ftp.FTP.__getReply(FTP.java:310)
at org.apache.commons.net.ftp.FTP.__getReply(FTP.java:290)
at org.apache.commons.net.ftp.FTP.getReply(FTP.java:632)
at org.apache.commons.net.ftp.FTPClient.completePendingCommand(FTPClient.java:1561)
at org.apache.commons.net.ftp.FTPClient.__storeFile(FTPClient.java:581)
at org.apache.commons.net.ftp.FTPClient.storeFile(FTPClient.java:1704)
at InternetServer.putServerFiles(InternetServer.java:591)



2. Datei vom Server herunterladen:

Zeile 510 output = new FileOutputStream(pathFilename);
Zeile 511 result = ftpC.retrieveFile(serverFilename, output);

Die Methode retrieveFile() liefert "false" zurück, es wird jedoch keine Ausnahme geworfen.



3. Ausloggen vom Server

Zeile 218 ftpC.logout();

Mit der Zeile 218 wird eine Ausnahme geworfen und mit diesem catch-Block abgefangen:
catch(IOException ioe) {
ioe.printStackTrace();
}

printStackTrace():
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(Unknown Source)
at sun.nio.cs.StreamDecoder.readBytes(Unknown Source)
at sun.nio.cs.StreamDecoder.implRead(Unknown Source)
at sun.nio.cs.StreamDecoder.read(Unknown Source)
at java.io.InputStreamReader.read(Unknown Source)
at java.io.BufferedReader.fill(Unknown Source)
at java.io.BufferedReader.read(Unknown Source)
at org.apache.commons.net.io.CRLFLineReader.readLine(CRLFLineReader.java:58)
at org.apache.commons.net.ftp.FTP.__getReply(FTP.java:310)
at org.apache.commons.net.ftp.FTP.__getReply(FTP.java:290)
at org.apache.commons.net.ftp.FTP.sendCommand(FTP.java:474)
at org.apache.commons.net.ftp.FTP.sendCommand(FTP.java:547)
at org.apache.commons.net.ftp.FTP.sendCommand(FTP.java:596)
at org.apache.commons.net.ftp.FTP.quit(FTP.java:804)
at org.apache.commons.net.ftp.FTPClient.logout(FTPClient.java:941)
at InternetServer.ftp(InternetServer.java:218)

 

[Empire Phoenix]

Benutzt der ftpclient evtl einen zu großen buffer?
versuch mal den zu verringern. (evtl. gibts ne einstellung für, sonst halt im source)

 

[gschmi01]

Hallo

Die Voreinstellung der Buffer-Größe ist 1024 Bytes. Ich habe die Größe auf 256 reduziert, allerdings mit dem gleichen (negativen) Ergebnissen, siehe Stack-Traces von oben.

 

[Empire Phoenix]

Dann würde ich einfach mal mit wireshark gucken was passiert, evtl ist der felher dann sichtbar.

 

[gschmi01]

Hallo

Ich habe die FTP-Kommunikation mit Wireshark aufgezeichnet. In diesem Screenshot
WiresharkTransmissionCompleted (auf Download unter den Dateidaten klicken)
ist das Ende des Datei-Uploads zu sehen, in dessen Umfeld das SocketTimeout auftritt:

No. 110: Eine solche Meldung wird vom Server meistens vor dem nächsten Upload-Paket gesendet
No. 109, 111: Hier werden die letzten beiden Pakete des Datei-Uploads zum FTP-Server gesendet
No. 112...125: Das kann ich nicht interpretieren.

No. 126: Hier wird vom FTP-Client ein QUIT an den Server gesendet. In meiner Applikation ist das nicht programmiert! Damit sind auch die beiden anderen Fehler erklärt, von denen ich berichtet habe:
- Herunterladen einer Datei (auch nur 1 kByte) ist nicht möglich
- Beim Logout gibt es wieder ein Read Timeout
Wenn keine Verbindung mehr zum Server besteht ist klar, daß es da Fehler gibt.

Damit konzentriert sich m. E. die Analyse auf die Pakete 112...125, in deren Umfeld es zu einem SocketTimeout kommt. Kannst Du damit etwas anfangen?

 

[gschmi01]

Hallo

Da jedesmal ein SocketTimeout auftritt, habe ich einige Versuche damit unternommen:

• SocketTimeout von 1000...34000 ms schrittweise nach Fibonacci erhöht (Sekunden-Reihe)
• SocketTimeout an diversen Programmstellen abgefragt

Beobachtung:

• Vor dem API-Funktionsaufruf ftpC.storeFile(serverFilename, input) erhält man den eingestellten Wert für SocketTimeout
• Im catch-Block (also nachdem die beschriebene Ausnahme geworfen wurde) erhält man immer SocketTimeout = 1000

Es sieht also derzeit danach aus, als ob in der Funktion storeFile() immer SocketTimeout = 1000 fix gesetzt wird, das bei langsamen Datenverbindungen zu einen Problem werden könnte. Ich werde in den Sourcen und bei Commons Net nachfassen, ob und warum dem so ist.

Fall es andere Vorschläge zur Vorgehensweise gibt, bitte posten.

 

[Empire Phoenix]

funktioniertes denn wenn du den timeout da einfach auf zb 9999999 setzt?

 

[gschmi01]

Hallo

Nein, eine solche Einstellung für SocketTimeout funktioniert auch nicht.
Siehe mein nächstes Posting zur technischen Erklärung.

 

[gschmi01]

Hallo

Ich habe die Sourcen zur Klasse FtpClient (3.0.1) von Commons Net heruntergeladen und analysiert, relevante Code-Fragmente siehe unten.

Dabei ist aufgefallen, daß ein vom Anwender gesetzter Wert für controlKeepAliveReplyTimeout intern als SocketTimeout verwendet wird (561, 562, 3292). Durch das Auftreten einer Exception wird die Funktion cleanUp() nicht mehr aufgerufen (3312), wodurch das Rückspeichern des ursprünglichen Werts von SocketTimeout entfällt. Aus diesem Grund hatte ich nach dem Aufruf von __storeFile() immer SocketTimeout = 1000 erhalten, da dies der von mir gewählte Wert für controlKeepAliveReplyTimeout war.

Dieser interne Umgang mit SocketTimeout und controlKeepAliveReplyTimeout erscheint mir fragwürdig. Aufgrund der API-Dokumentation hätte ich andere technische Umstände dahinter erwartet. Wegen der vorgefundenen Funktion des Codes habe ich auf meine Festlegungen

keepAliveTimeout = 300;
keepAliveReplyTimeout = 1000;
ftpC.setControlKeepAliveTimeout(keepAliveTimeout);
ftpC.setControlKeepAliveReplyTimeout(keepAliveReplyTimeout);

verzichtet und auskommentiert, und siehe da.....: Es funktioniert!!!!!!

Die vorher intern aktivierte Einstellung SocketTimeout = 1000 hat zu der Fehlfunktion geführt. Das wirft natürlich die Frage auf, ob man diese FtpClient-Implementierung bei niederratigen Kanälen und der Überwachung von "Control channel keep-alive" durch Netzwerk-Router wirklich immer anwenden kann. Ich habe da meine Zweifel und werde das bei Commons Net posten. Wenn eine Antwort kommt, hänge ich sie an diesen Thread an.


gschmi01




545 private boolean __storeFile() {
....
560 CSL csl = null;
561 if (__controlKeepAliveTimeout > 0) {
562 csl = new CSL(this, __controlKeepAliveTimeout, __controlKeepAliveReplyTimeout);
563 }
....
566 try
567 {
568 Util.copyStream(local, output, getBufferSize(),
569 CopyStreamEvent.UNKNOWN_STREAM_SIZE, __mergeListeners(csl),
570 false);
571 }
....
586 }



3279 private static class CSL implements CopyStreamListener {
....
3288 CSL(FTPClient parent, long idleTime, int maxWait) throws SocketException {
3289 this.idle = idleTime;
3290 this.parent = parent;
3291 this.currentSoTimeout = parent.getSoTimeout();
3292 parent.setSoTimeout(maxWait);
3293 }
....
3312 void cleanUp() throws IOException {
3313 while(notAcked-- > 0) {
3314 parent.__getReplyNoReport();
3315 }
3316 parent.setSoTimeout(currentSoTimeout);
3317 }

....
3319 }