Diese
Exception im original Source der
INDY's zu kapseln oder zu entfernen ist eine ziemlich schlechte Idee, sie erfüllt nämlich eine sehr wichtige Aufgabe. Nur, das was du begreifen musst ist WAS die
Indy Programmier unter einer
Exception verstehen ! Wir gehen nur davon aus das
Exception Fehler im programfluß sind, nun die
Indy Programmierer sehen eine
Exception als Außnahmebedingung also nicht unbedingt als Fehler im Programfluß. Diese Sichtweise ist sehr umstritten und ärgert viele Programmiere am
Indy Konzept, aber man kan sich daran gewöhnen.
Nun, wenn die Verbindung einseitigt durch den Server oder Clienten geschlossen wurde OHNE das der Gegenpart darüber informiert wurde, dann entsteht diese
Exception. D.h. aber nicht das die Verbindung unterbrochen wurde sondern absichtlich getrennt wurde. Somit ist diese
Exception keine Fehlermeldung sondern eher eine Außnahme.
Bei
FTP werden zwei Verbindungen benötigt. Die eine, die Steuerleitung, ist immer verbunden und überterägt die
FTP Kommandos und deren Rückmeldungen. Auf Grund dieser Kommandos wird es nun erforderlich Daten zu übertragen. Dazu wird EXAKT laut
FTP Protokollen und
FTP RFC Standards eine Datenleitung=Datensocket, geöffenet. Somit ergibnt sich folgendes Bild:
1.) Kommando vom Client zum Server um eine Datenleitung aufzubauen, meisten PASV oder PORT
2.) bestätigung vom Server empfangen
3.) Datenleitung aufbauen = Sockets verbinden
4.) Kommando LIST an Server senden
4.1.) Daten auf Datenleitung empfangen
4.2.) Datenleitung schließen oder auf Schließen warten
4.3.) Bestätigung für LIST Kommando über Steuerleitung abwarten
4.4.) Datenleitung schließen falls noch offen
Du siehst das in den Schtitten 4.2. oder 4.4. die Datenverbindung getrennt werden kann. Die Reihenfolge ist sehr wohl abhängig von der Implemention der Server. Zb. Microsoft Server schließen erst nam dem Senden von 4.4. die Datenleitung, aber viele UNIX L8 Server schließen die Datebnleitung im Schritt 4.2.
Die richtige Vorgehensweise wäre die des Microsoft
FTP Servers, die falsche ist eigenlich die des UNIX L8 Servers. Die Implementation im
Indy FTP wird also im Schritt 4.2. die besagte
Exception auslösen, aber eben NICHT als Fehler sondern als Ausnahmebedinung als Signal das alle Daten übertragen wurden. Denn im
FTP protokoll gibt es sogut wie keine Möglichkeit schon im vornhinein zu erkennen wieviele Daten tatsächlich zu empfangen sind, und ab welchem Moment nun die Daten vollständig übertragen wurde. Also wird einfach die Datenleitung geschlossen, als Signal das alle Daten gesendet wurden. Erst im Schritt 4.4. entscheidet sich nun ob das komplette Kommando sammt Daten wirklich gültig war oder ein Fehler aufgetreten ist.
Somit gibt es mehrere "Fehlerursachen" des Problems:
1.)
FTP ist wohl das scheißigste Protokoll das jemals amerikanische Professoren und Doktoren an einer Universität entwickelt haben.
2.)
FTP wird sich durch die verschiedenen Berkeley Socket
API Implementierungen auf Linux/Unix zu Windows anders verhalten, was wiederum zu verschiedenen Verhaltensweisen der darauf entwickelten
FTP Server führt
3.) die
FTP Client Software Blibliotheken bauen meistens ganz exakt den
RFC Standard und deren Beispeielhafter Komunikationsabläufe nach. Das ist im Grunde falsch und zeigt inwieweit der Programmiere des
FTP Clients eigentlich Ahnung von der Sache hatte. D.h. der
INDY FTP Client ist nicht der beste seiner Art.
ABER ! Fehler kann man keinem dieser Entwickler unterstellen, der einzigste Fehler war es aus der Not heraus ein experimentelles Universitäten Protokoll das eigentlich NUR ein besseres Messangerprotokoll zwischen Menschen war, als
FTP = File Transfer Protokoll zu vergewaltigen.
Gruß Hagen