Kurzbeschreibung
Parameter Funktionsweise
Ein/Ausgänge Limitierungen
Querverweise Beispiele
 | Kurzbeschreibung
Das Modul TFTPServer implementiert
das TFTP-Protokoll und kann damit zum Lesen und Schreiben von Dateien verwendet werden. |
 | Parameter
 | Parameter: Parameterquelle
intern, extern oder Datenbank. |
 | Startpfad: Das Verzeichnis, von
dem Dateien gelesen, bzw. in das Dateien geschrieben werden. |
 | Zugriff nur auf Startpfad und
Unterverzeichnisse: Es kann auf kein übergeordnetes Verzeichnis (durch '..' oder
absoluten Pfad) zugegriffen werden. |
 | Timeout: Nach dieser Zeit werden
Antworten wiederholt. |
 | Versuche: Es wird maximal so oft
wiederholt, dann Fehler. |
 | Überschreiben erlaubt: Dateien die
mit dem PUT-Kommando geschrieben werden sollen, können alte Dateien gleichen Namens
überschreiben. |
 | Verzeichnisse erstellen: Wird beim
PUT-Kommando ein Dateiname mit einem noch nicht existenten Pfad angegeben, so wird dieser
angelegt (auch für mehrere Unterverzeichnisstufen). |
|
 | Funktionsweise
Das Modul wartet auf eine Anforderung
von einem TFTP-Client. Diese wird am Eingang RemoteInfo und Data eingelesen. Aus der
IP-Adresse und dem Port des Clients (RemoteInfo-Eingang) wird der Ausgang Host-Param
gefüllt (Mode ist Server, Address ist der Name des Clients und Port ist der TCP/IP Port
des Clients). Die Anforderung wird bearbeitet und das erste Antwortpaket an den Ausgang
Data geschickt. Der Client empfängt die Antwort auf dem Port, auf dem er auch die
Anforderung gestellt hat. Sein Acknowledge (auf jedes Paket wird ein Antwortpaket
geschickt, somit weiß der gegenüber, daß es angekommen ist) schickt er dann auf den
Port, von dem er das Datenpaket erhalten hat. Das Acknowledge-Paket wird dem TFTPServer an
dem zweiten RemoteInfo- und Data-Eingängen geschickt. Damit weiß er, daß er das
nächste Paket schicken soll. Auf das letzte Paket (Datenlänge < 500 Bytes) wird kein
Acknowledge geschickt.
Kommt ein Datenpaket oder Acknowledgepaket zu lange nicht an (Timeout), so wird das letzte
Paket wiederholt, bis die Anzahl der Versuche erreicht sind.
Tritt ein Fehler auf, wird der Signalgraph gestoppt und eine Fehlermeldung ausgegeben.
|
 | Ein-/Ausgänge
Eingänge
|
EXT, DB |
UBYTE[]{root_path},
SWORD{only_subdirs}, SWORD{timeout}, SWORD{retries}, SWORD{overwrite}, SWORD{create_dir} |
Parametrierung des Moduls
über externe Quellen wie ParamConv oder DBLoad |
RemoteInfo |
TYPEINFO{TypeInfo}
UBYTE[]{Text} |
IP-Adresse und Port des
Clients |
Data |
TYPEINFO{TypeInfo}
UBYTE[]{Text} |
Datenstring |
RemoteInfo |
TYPEINFO{TypeInfo}
UBYTE[]{Text} |
IP-Adresse und Port des
Clients |
Data |
TYPEINFO{TypeInfo}
UBYTE[]{Text} |
Datenstring |
Ausgänge |
Host-Param |
SWORD{mode},
UBYTE[]{address}, SWORD{port} |
EXT-Parameter für UDP-Modul |
Data |
TYPEINFO{TypeInfo}
UBYTE[]{Text} |
Datenstring |
|
 | Limitierungen
- |
 | Querverweise
UDP, tftp-Befehl (Windows NT) |
 | Beispiele
Das Modul UDP1 wartet (als Client) auf eine Anforderung auf Port 53 (TFTP). Diese
wird an den TFTPServer weitergegeben. Der bearbeitet die Anforderung und sendet die
Antwort über das Modul UDP2 an den Client zurück (auf den Port, von dem die Anforderung
kam). Der Client schickt das nächste Paket diesmal nicht mehr an den Port 53,
sondern an den Port, von dem die erste Antwort gekommen ist. Das ist das Modul UDP2, das
somit alle weiteren Pakete für diese Verbindung empfängt und an dem TFTPServer
weiterleitet. Der bearbeitet diese und sendet das nächste Paket. Somit ist eine
Rückkopplung entstanden, die nach dem letzten Paket endet. Der TFTPServer kann auch
gleichzeitig mehrere Verbindungen bearbeiten, da das Modul UDP1 inzwischen schon
wieder auf weitere Anforderungen wartet und die Kommunikation am Server immer über Port
und Adresse des Clients definiert ist.
|
|