Mit diesem CP/M-Programm wird ein KC85 mit D004 vollwertiges Mitglied eines TCPIP-Heimnetzwerkes. Es kombiniert einen TFTP-Server und Client menügesteuert in einem Programm und dient der Datenübertragung im Netzwerk.

Eine Hauptanwendung von Netzwerken ist der sichere und schnelle Austausch von Daten zwischen Netzwerkteilnehmern und das war natürlich auch eines der Kernziele des TCPIP-Projektes.

Also sollte ein Programm zur Datenübertragung geschrieben werden und dafür war es erst einmal notwendig, sich auf ein geeignetes Netzwerkprotokoll festzulegen. Hier bot sich als Einstiegsprojekt das auf den ersten Blick unkomplizierte TFTP-Protokoll an. Mit 5 unterschiedlichen Pakettypen sah das relativ einfach aus und sollte in verhältnissmässig kurzer Zeit zu schaffen sein.

Die prinzipielle Funktion war auch nach wenigen Tagen vorhanden aber dann hat mich irgendwie "der Hafer gestochen". Mit den 4 vorhandenen TCP/IP-Kanälen könnte man ja auch mal ein wenig mehr machen. Der Plan war dann der folgende:

Nach dem Start von TFTP.COM wird ein Socket immer für den Server reserviert, welcher ständig läuft und auf eingehende Schreib- oder Lese-Anforderungen von anderen Netzwerkteilnehmern wartet. Die anderen 3 Sockets werden dynamisch verwendet, um Dateien von Rechner zu Rechner zu übertragen. Das bot sich durch das verwendete Netzwerkprotokoll förmlich so an, da der Serverport eine Verbindung nur beginnt, eine anschliessende Übertragung von Daten erfolgt auf einem anderen Port.

Weiterhin sollte ein KC mit dem TFTP-Programm parallel als Server und Client im Netzwerk auftreten können. Die Serverfunktion bedient andere Netzwerkteilnehmer - die Clientfunktion bedient den Anwender am lokalen Rechner, welcher dann auch bei anderen Servern Lese- bzw. Schreibanforderungen auslösen und dadurch ebenso aktiv Daten übertragen kann. Die Hauptschleife des Programmes muss sich demzufolge gleichzeitig um die folgenden Hauptaufgaben kümmern:

Das funktionierte bereits alles mehr oder weniger zum KC-Treffen 2008, war aber noch nicht optimiert und ziemlich träge. Die Überarbeitung stand natürlich fest im Plan und erfolgte nun in den letzten Wochen - das komplizierteste Programm hebt man sich ja immer bis zuletzt auf.

 

TFTP Server CP/M

 

TFTP CPM SERVER



So sieht das dann unter CP/M aus, wenn man TFTP.COM als Server startet. Anschliessend kann man von beliebigen anderen Netzwerkteilnehmern Daten per TFTP-Protokoll in das lokal einstellbare Verzeichnis schreiben oder von dort lesen. Der KC kann wiederum als Client mit den beiden Funktionen PUT bzw. GET und einem einstellbaren lokalen Clientverzeichnis Daten senden oder empfangen.

Die beiden Verzeichnisse des KC für Server bzw. Client sind vollkommen entkoppelt, man kann sich quer über alle Laufwerke und Userbereiche bewegen. Für beide ist auch eine getrennte Anzeige der lokalen Directory-Inhalte mit Auswahlmaske vorhanden.

Im Bild arbeitet der KC mit 3 parallelen Transfers gerade am Limit, mehr ist durch die Hardwarebeschränkungen der KCNET-Schnittstelle nicht möglich. Es ist aber auch nicht sinnvoll, selbst mit Festplatte oder auch beim Schreiben in die RAM-Floppy geht das CP/M schon merklich in die Knie aber es macht das alles klaglos mit!

Mit diesem Programm kann der D004-KC unter CP/M auch als Datenquelle für andere KC's dienen, wenn diese nicht auf Diskette oder Festplatte zurückgreifen können. Man benötigt dann natürlich auch mindestens 2 Netzwerkmodule. "Zur Not" kann man auch einen PC mit geeigneter Software dafür verwenden, siehe folgender Abschnitt.

 

TFTP Server Windows

Funktionelles Vorbild für das CP/M-Programm war "PumpKIN" von http://www.klever.net/, welches ich seit mehreren Monaten regelmässig für den Datenaustausch mit dem PC benutze. Im ersten Bild sieht man 3 laufende Transfers zum KC85 und im zweiten Bild wurde alles erfolgreich beendet:

 

TFTP Windows PumpKIN

 

TFTP Windows PumpKIN


Es gibt zwar auch noch weitere Programme aber mir hat es bis jetzt am besten gefallen. Man kann beispielsweise auch Dateien per Drag'n'Drop aus einem Explorer-Fenster in das PumpKIN-Fenster ziehen und startet damit die Sendefunktion zum letzten verwendeten Host. Darüber hinaus gestattet es viele individuelle Einstellungen und sollte sich auch mit allen Windows NT-Versionen vertragen, bis hin zu Windows 7 sind bisher bei mir keine Probleme aufgetreten.

Die Standardeinstellungen des Programmes (Options) passen auch ganz gut zum KC-Programm. Unter "Server -> TFTP filesystem root (download path)" kann man das PC-Verzeichnis für alle Transfers festlegen. Wenn man das Häkchen bei "Allow access to subdirectories" setzt, hat der KC-Client auch Zugriff auf existierende Unterverzeichnisse des TFTP Root-Verzeichnisses auf dem PC. Die einzige Veränderung, welche ich empfehle, ist die Erhöhung des Wertes "Network -> Default connection timeout" auf 60s.

Da in beiden Programmen Client und Server kombiniert sind, kann man nun sowohl mit KC oder PC auf dem jeweils anderen Rechner lesen und schreiben. Da es im Protokoll keinen DIR-Befehl für das Remote System gibt, sollten diese allerdings nicht so weit auseinanderstehen :-).

Die Übertragung erfolgt grundsätzlich in binärer Form, dem sog. Octet-Mode, mit dem UDP-Transportprotokoll. Sie ist durch die Prüfsummenkontrollen der tieferliegenden Netzwerkschichten sehr sicher, ich hatte bisher noch nie einen Fehler bei erfolgreich übertragenen Daten.

 

TFTP Client CP/M

 

TFTP CPM CLIENT



Zum schnellen Kopieren von Dateien von/auf andere Rechner per Befehl in der Kommandozeile oder für eine eventuelle Automatisierung per Batch ist ein Menüprogramm nicht geeignet. Deshalb enthält TFTP.COM für die beiden Clientfunktionen PUT und GET noch genau diese zweite Nutzungsmöglichkeit mit Hilfe entsprechender Parameter beim Aufruf von der Kommandozeile. Beim Senden von lokalen Dateien per PUT kann dann auch mit Wildcards gearbeitet werden, siehe Abbildung.

Da man beim Transfer einzelner Dateien sowohl einen lokalen als auch remote Dateinamen angeben kann, ist über diesen Weg auch der Zugriff auf die langen Dateinamen (ohne Leerzeichen!) anderer Betriebssysteme möglich. Der Befehl verwendet diese Namen wie eingegeben, so dass mit dem Transfer auch gleichzeitig das Umbenennnen erfolgt.

In der Kommandozeilenvariante lassen sich aktive Transfers auch jederzeit mit ESC oder CTRL+C abbrechen. Der KC räumt dann auch immer auf und speichert im Dateisystem nur erfolgreich abgeschlossene Transfers. Er überschreibt allerdings auch nie bereits vorhandene Dateien, dass muss man vorher mit einem entsprechenden CP/M Programm erledigen.

 

TFTP Client Windows / Linux / Unix

 

TFTP Windows Client TFTP.EXE



Mit allen Windows NT Versionen und Linux bzw. Unix kann man auch ohne zusätzliche Software sofort auf der Konsole arbeiten, da ein TFTP Client-Programm bereits Bestandteil des Betriebssystems ist.

Die Syntax des TFTP-Clients sieht man, wenn im DOS-Fenster bzw. in der Konsole TFTP und ENTER eingeben werden. Noch mal zur Beachtung - Dateien sind grundsätzlich im binären "Octet-Mode" zum/vom CP/M-Rechner zu übertragen! Wenn man diese Programme benutzen möchte, muss man natürlich vorher auf dem KC den TFTP-Server starten und das gewünschte Server-Verzeichnis  mit dem Befehl 'S' einstellen.

TFTP Nutzung Windows-NT Versionen:


TFTP Ersatz für Windows 98 bzw. ME:

Von der Gesellschaft "Tandem Systems Ltd." gibt es einen TFTP-Client, welcher mit allen Windows-Versionen funktioniert und damit als direkter Befehls-Ersatz für das NT-Programm eingesetzt werden kann. Die Syntax entspricht 1:1 dem Programm von Microsoft, wobei zusätzliche Optionen des TFTP-Protokolls unterstützt werden. Unter www.winagents.de kann man sich diesen kostenlosen TFTP-Client herunterladen.


Die Unix verwandten Betriebssysteme sind beim Zugriff per TFTP auf das eigene Dateisystem sehr restriktiv. Der Befehl PUT geht in der Regel sofort (wenn Public lesen darf), GET (bzw. PUT vom KC aus) aber nie. In der Manpage gibt es dazu die folgenden Angaben:

"Due to the lack of authentication information, tftpd will allow only publicly readable files to be accessed. Files may be written only, if they already exist and are publicly writable."
Man kann also mit der Standardeinstellung überhaupt nur auf Public Dateien lesend zugreifen und (über)schreiben darf man nur bereits vorhandene Dateien, wenn für Public das Schreiben der Datei erlaubt ist.

Man kann zwar den TFTP-Prozess durch die Angabe entsprechender Parameter aushebeln, trägt aber dann auch die dadurch entstehenden Risiken.

 



TFTP.COM Version 1.4

Bis zur Version 1.3 war TFTP.COM auf den Standard UDP-Port 69 für das TFTP-Protokoll beschränkt. Ab Version 1.4 wurde diese Limitierung komplett aufgehoben. Der Server kann nun auf beliebigen UDP-Ports betrieben werden, was bereits in der Kommandozeile angegeben oder direkt im Server-Menü eingestellt werden kann. Auf die beiden Clientfunktionen PUT und GET trifft das konsequenterweise auch zu, man kann auch mit TFTP-Servern kommunizieren, welche nicht auf dem Standard-Port 69 laufen.

Version 1.4 unterstützt auch die benannten Verzeichnisse unter NZCOM. Die Namen können jetzt in allen Eingabefunktion statt DU: verwendet werden und die Anzeige von Client- und Server-Verzeichnis im Menü wurde dahingehend erweitert.

Damit man die Server-Adresse des KC sehen kann, wenn TFTP.COM ausgeführt wird, zeigt das Programm ab Version 1.4 in der Transfer-Überschrift des Server-Menüs  die lokale IP-Adresse des Servers an.


 

Die aktuelle Version von TFTP.COM mit einer kurzen Beschreibung und die CP/M-Quelltexte sind in den KCNET-Paketen enthalten und befinden sich wie immer im Downloadbereich.