FTP Mysterium V7R1

[wolfgang.w]

@Zerberus
Du hast Post.

@Fuerchau
Ich habe das mit dem "mget *.xml" mal ausprobiert. Leider mit dem gleichen Ergebnis. Nach der 2. Dateiübertragung kommen die gleichen Fehlermeldungen und der Job bricht ab.

Da die AS/400 aber wohl schneller geworden ist, kann die den Get bereits absetzen bevor der Server auch tatsächlich im Empfangsmodus für neue Befehle ist.

Sollte der Client mit dem nächsten Get bzw. Port-Befehl nicht warten bis der Server die Abschlussmeldung des vorherigen Get gesandt hat? Wenn ja, dann ist der Server doch in jedem Fall wieder empfangsbereit - oder nicht?

Ursache könnte sein, dass die AS/400 nun auch mit Threading im FTP arbeitet.

Dazu habe ich keine Dokumentationen gefunden.

[Fuerchau]

Auch der FTP-Server wird wohl mit Threads arbeiten.
Wenn also der Sendethread seine Fertigmeldung abgibt, kann der Client eigentlich den nächsten Befehl senden.
Der Sendethread muss sich aber noch beenden und dem Listener für die Kommandos sein Ende mitteilen.
Wenn das u.U. länger dauert als die AS/400 nun den nächsten Befehl sendet kommt es zum Konflikt.

Da ich nun nicht weiß, wie ein mget implementiert ist kann ich auch hier nur raten.
Ggf. ist mget ein interner Befehl, der die Dateinamen vom Server abholt und dann eben automatisch mehrere get's generiert.
Wenn der Server aus dem mget selber einen mput machen kann wäre das eigentlich kein Problem.

Wer weiß, sobald meine Kunden auch auf V7 umsteigen, komme ich vielleicht in die selben Probleme da ich häufig mit mget arbeite.

Hier habe ich noch eine Doku:
Introduction to FTP

Interessant ist "SENDPASV 1", also einschalten des Modus.

When PASV mode is used, the client sends a command to the server informing the server of its intent to use PASV mode, and the server responds with a TCP port. The client then initiates a connection to the server on this port and the server begins transferring data.
In general, it is usually better to use PASV mode.

[BenderD]

... schnell hin, schnell her: wenn ein FTP Transfer mittendrin abkackt, ist das entweder ein Transportproblem, oder ein Bug im OS (ich tippe mal auf letzteres.
Was die Multithreading Diskussion angeht, müsste Multithreading das eher heilen als verschärfen; ob das in multiple Threads ablaufen könnte, müsste man mal die FTP Spezifikation zu Rate ziehen.

D*B

[Zerberus77]

Hallo Wolfgang,

also der Trace sieht gut aus. Was ich dir mit 99.9% Sicherheit sagen kann ist, dass es kein Fehler seitens der iSeries ist.

Der Trace/die Kommunikation sieht im Groben so aus:

*) Client sendet ein SYN Packet
*) Server antwortet mit SYN ACK
*) Anmeldung und 'cd' werden gemacht
*) Client sendet seinen PASV command
*) Datenverbindung (SYN - SYN ACK) wird hergestellt
*) Server sendet seine Daten und schickt ein 'Transfer completed successfully'
*) Server schickt den FIN mit dem letzten Datenpacket für die Datenleitung
*) Client sendet sein FIN auf der Datenleitung
*) Client sendet sein neues PASV
*) Server antwortet mit dem bekannten Fehler

Es kommt also zu keiner Überschneidung im Gegenteil, der 'Transfer completed successfully' kommt, obwohl noch nicht alle Daten am Client angekommen sind. Der Client wartet aber bis er sein letztes Datenpacket bekommen hat und vom Server das FIN erhalten hat. Erst dann wird die nächste Datei angefordert. Ein wenig stutzig macht mich die Reihenfolge, wie die Daten kommen. Das Problem mit dem 'frühzeitigen' 'Transfer completed successfully' habe ich nur bei grösseren Files gesehen, deine sind so 3-4 kb groß. Irgendwas im Netz dazwischen, oder der Server selbst dürfte da nicht ganz nachkommen.

Du sagst, das kam nach der Umstellung auf V7R1. Was mir da im Bereich TCPIP einfallen würde ist, das sich die Defaultwerte des SND und RCV Buffers geändert hat. Diese waren bis incl. V6R1M1 8192. Prüfe mal mit CHGTCPA - PF4 was bei dir da steht. Wenns grösser ist, ändere es mal auf 8192. Wenns dann geht, gibts definitiv ein Problem im Netzwerk. Normalerweise sollte ein Wert von 65535 drinnenstehen.

Ich denke, das die neue Maschine mit dem neuen OS jetzt für den Server 'zu schnell' ist. Möglicherweise ist ja jetzt auch ein GB Anschluss und vorher wars ein 100MB, das kann sich auch mal so 'negativ' auswirken. Ich habe jetzt nicht geprüft, ob die Version vom FTP Server aktuell ist, aber ich würd das auch mal prüfen lassen.

Wie schon gesagt, anhand der Tracedaten kann ich mit 99.9%iger Sicherheit sagen, dass es kein Fehler der FTP Client Software oder der iSeries ist.

MFG Zerberus

[wolfgang.w]

Hallo Zerberus

Vielen Dank für Deine Arbeit und Deine Unterstützung. Schade, dass man nichts eindeutiges ermitteln konnte, dann hätte man einen Aufhänger gehabt!

Die Pufferwerte in CHGTCPA habe ich vorher schon mal auf die 8192 (wie er auf der alten 520'er V5R3 Maschine war) runtergeschraubt. Ich habe es jetzt sicherheitshalber nochmals gemacht und einen Test durchgeführt. Leider war das Ergebnis immer noch das Gleiche!

Betreffend PTF ist die Maschine auf dem neuesten Stand (13037). Die Hyper habe ich noch nicht alle durchgesehen, aber auf die Schnelle habe ich nichts gefunden was dieses Problem betreffen könnte.

Summa Sumarum immer noch keine Lösung! Weiss jemand wie man so ein Problem am einfachsten der IBM meldet?