🚀 go-pugleaf

FTP Probleme mit Windows NT 4.0 SP6a

Seit ich auf meinen Servern, auf denen mehrere Webs und FTP-Sites unter IIS
4 laufen, den SP6a installiert habe, kommt es zu eindeutig reproduzierbaren
H�ngern im FTP Verkehr beim Upload oder Download von Webseiten zur
korrespondierenden FTP-Site. Besonders schlimm ist dies beim Zugriff vom MAC
aus (z.B. MAC OS 8.6 mit Clientprogramm Fetch 3.0.3) Der Clientrechner
bleibt teilweise in einer Deadlock Situation h�ngen. Als Ursache konnte ich
eine Situation mehrfach mit dem Netzwerkmonitor nachmessen. Dabei erfolgte
der Download einer kleinen HTML-Datei vom MAC aus. Der FTP-Server quittierte
den erfolgten Datenverkehr mit der FTP-Response �226 Closing data
connection. Requested file action successful� nach RFC 959 �ber die
Steuerport TCP-Verbindung (Port 21). Die zugeh�rige TCP-Datenverbindung auf
Port 20 wurde danach aber nicht beendet! Deshalb scheint der MAC weiterhin
auf Daten zu warten. Er zeigt eine immer geringer werdende
Daten�bertragungsrate an. Die Datei wird nicht geschlossen, obwohl sie
nachweislich vollst�ndig �bertragen wurde. Wenn man die selbe Messung mit
einem Windows2000 Server wiederholt, baut dieser jeweils nach der
�bertragung die TCP Datenverbindung auf Port 20 ab. Dieses �fehlerhafte
 Verhalten von NT 4.0 scheint auch erst seit dem SP6a aufzutreten. Nicht nur
MAC-Clients haben diese Probleme. �hnliche Situationen gibt es auch mit
Windowsclients, dies konnte ich bisher nur nicht so detailliert nachmessen.
Interessant ist au�erdem, dass diese Deadlock Situation auch noch von
irgendwelchen Dateieigenschaften abzuh�ngen scheint. Bei manchen Dateien
(meist etwas gr��eren) baut n�mlich die Clientseite nach der �bertragung die
Port 20 Verbindung ab. Damit gibt es dann nat�rlich auch keine Deadlock
Situation.

Ist dieses Scenario bereits bekannt? Wie k�nnte man dieses Verhalten
beeinflussen? Es sieht so aus, als ob die Sache auch nicht von der
FTP-Server- oder Clientversion abh�ngt, sondern eher ein Fehler des
TCP/IP-Stacks ist. Verschiedene Client- oder Serverprogramme zeigen das
gleiche Verhalten.


Original Zitat aus RFC959:

The data connection shall be closed by the server under the conditions
described in the Section on Establishing Data Connections.  If the data
connection is to be closed following a data transfer where closing the
connection is not required to indicate the end-of-file, the server must do
so immediately. Waiting until after a new transfer command is not permitted
because the user-process will have already tested the data connection to see
if it needs to do a "listen"; (remember that the user must "listen" on a
closed data port BEFORE sending the transfer request).  To prevent a race
condition here, the server sends a reply (226) after closing the data
connection (or if the connection is left open, a "file transfer completed"
reply (250) and the user-PI should wait for one of these replies before
issuing a new transfer command).


*********************************************
*Wind Internethaus GmbH
*Lothar Moosmann
*An der Hammerhalde 70
*D-78050 Villingen-Schwenningen
*http://www.windinternethaus.de
*info@windinternethaus.de
*info@lothar-moosmann.de
*Tel:  +49 7721 509927
*Fax: +49 7721 509928
*********************************************