View Full Version : FTP Mysterium V7R1
Da frage ich mich, wie das Script aufgebaut ist.
Gibst du mehrere Get's direkt hintereinander ab?
Vielleicht ist das neue System da einfach schneller und der 2. get wird ausgelöst bevor der erste fertig ist!
Mit dem DLY umgehst du halt die Schnelligkeit des Systems.
Warum klappt mget nicht?
wolfgang.w
25-09-13, 08:50
@Fuerchau
Das Script ohne Pausen ist nichts anderes als viele get-Zeilen nacheinander.
z.B.
get 20130924035807706_00061469.xml
get 20130924043211675_00061470.xml
get 20130925063354322_00061471.xml
get 20130925063426180_00061472.xml
get 20130925063519055_00061473.xml
get 20130925063625997_00061474.xml
get 20130925063724171_00061475.xml
etc.
Und genau das ist der Krux an der ganzen Sache. Mehrere get (wie auch der mget, was ja nichts anderes ist) nacheinander funktionieren nicht. Baue ich hingegen eine Pause zwischen jedem Get ein dann klappt es! Die Symptomatik ist wie du sagst, dass der 2. get ausgelöst wird bevor der 1 beendet ist. Aber wie kann das sein?
@Zerberus77
Vielen Dank für Dein Angebot. Ich habe mal einen Testlauf gemacht und die Ausgabe bereit gestellt. Wo soll ich Sie hinschicken?
Nun ja, im Passivmodus wird der Get nicht vom Client ausgeführt sondern als Put vom Server.
Der Aktivmodus (SENDPASV 0) wird aber ggf. vom Server abgelehnt.
Nun meldet der Server ggf. den Get als erledigt aber er kann einen neuen Befehl noch nicht verarbeiten.
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.
Je nach Serverauslastung kann der mal schneller oder auch langsamer sein.
Ist der schnell genug, klappts, wenn nicht, klappts nicht.
Durch deinen DLY gibst du dem Server nun ausreichend Zeit.
Warum kannst du keinen "mget *.xml" absetzen?
Dies würde dann vom Server automatisch in einen "mput" übersetzt werden.
Allerdings gilt auch hier, dass bei mehreren mget's der Server vielleicht zu langsam ist.
Ursache könnte sein, dass die AS/400 nun auch mit Threading im FTP arbeitet.
Zerberus77
25-09-13, 19:25
Hallo Wolfgang,
PM ist unterwegs.
MFG Zerberus
wolfgang.w
26-09-13, 08:30
@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.
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 (http://www.ftpx.com/ftpintro.aspx)
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.
... 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
27-09-13, 19:33
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
29-09-13, 11:19
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?
Hallo,
ich würde diese 1000 Ptf installieren.
IBM i Support: PTF Cover Letter: SI49734 (http://www-912.ibm.com/a_dir/as4ptf.nsf/ALLPTFS/SI49734)