Technische Realisierung von Filetransfers

Soll eine Datei übertragen werden, erhält das Netzwerk-Programm über die Benutzerschnittstelle, das NWP-Menü, folgende Angaben von Seiten des Benutzers:

• den Namen des lokalen NWP-Knotens
• die Benutzerkennung am lokalen Knoten
• Angaben zur Datei (Name, Typ) auf dem lokalen NWP-Knoten und den gewünschten Übertragungsmodus (synchron, asynchron)
• den Namen des NWP-Zielknotens
• die Benutzerkennung am Zielknoten
• das Benutzerpasswort für den Zielknoten
• Angaben zur Datei bezüglich des Zielknotens (Platte, Verzeichnis, Name, Typ)

Nachdem der Benutzer dem NetzWerk-Programm den Auftrag zum Senden einer Datei erteilt hat, erzeugt NWP einen netzweit eindeutigen Transaktionscode, der sich aus dem Namen des Ursprungsknotens sowie einer vierstelligen Dezimalzahl, die noch nicht für bisher an diesem Knoten initiierte Transaktionen verwandt worden ist, zusammensetzt . Zu beachten ist, daß der Knotenname, also eine logische Adresse der OSI-Schicht 7 und nicht etwa eine IP-Adresse verwandt wird, da Schicht-3-Adressen aufgrund der Heterogenität des Verbunds nicht eingesetzt werden können: Einige NWP-Knoten verfügen über keine IP-Adresse.
Eine wichtige Konsequenz daraus ist, daß NWP logisches Routing auf der OSI-Schicht 7 praktiziert, um die Dateien durch das Netz zu transferieren.
Die Wege, über die die zu übertragenden Daten laufen, sind von vornherein festgelegt d.h. das NetzWerk-Programm verwendet statisches Routing. Jeder NWP-Knoten besitzt eine Wegedatei im ASCII-Format mit N Einträgen (wobei N die Gesamtzahl der Knoten des NWP-Verbunds ist), die unter anderem die in Tabelle 4.1 gezeigten Angaben umfaßt.

 

WEGE- URSPRUNGS- ZIEL- NÄCHSTER WEGE-

NUMMER KNOTEN KNOTEN KNOTEN FORMAT INFO

1 zrzvm3 catek malibu V H

3 titan bmwsys rrz1 F I

... ... ... ... ... ...

Die Wegenummer gibt an, welche Knotensequenz eine Datei nimmt; es können bis zu 9 verschiedene Routen von einem Ursprungs- zu einem Zielknoten konfiguriert werden.
Die Angabe ,,Format`` enthält Information, ob der Dateiname auf dem Zielknoten einem fixen (F) Format unterliegt (wie es der Fall bei VM-Rechnern ist), oder ob dieses variabel (V) gewählt werden kann (zum Beispiel bei UNIX-Systemen).

Die Wegeinformation beinhaltet Angaben, in welcher der folgenden Netzarten der Dateitransfer erfolgt:

• Homogenes Netz d.h. es muß keine Konvertierung des Dateiinhaltes erfolgen
• Inhomogenes Netz d.h. es müssen Anpassungen an unterschiedliche Zeichensätze (ASCII, EBCDIC...) und Satzlängen vorgenommen werden
• Streng homogenes Netz d.h. alle Knoten auf dem Weg haben dasselbe Betriebssystem
• Lokales Netz d.h. Ursprungs- und Zielknoten sind identisch und die Menge der Zwischenknoten ist leer; dies mag auf den ersten Blick merkwürdig erscheinen, jedoch kann dies durchaus bei CAD-Systemen vorkommen, die auf die NWP-Programmierschnittstelle [NWP PRO] aufgesetzt sind.

Jedem NWP-Knoten sind also alle anderen Knoten des NWP-Verbunds bekannt, allerdings nicht die vollständige Route zu ihnen, da in der Wegedatei lediglich der benachbarte und der Zielknoten verzeichnet sind.

Nachdem der Transaktionscode erzeugt wurde, wird ihm ein Präfix, das aus zwei Buchstaben besteht, vorangestellt. Die Konkatenation aus Präfix und Transaktionscode ergibt dann einen netzweit eindeutigen Dateinamen, der auch Aufschluß über die Art der in ihm enthaltenen Daten gibt (Abbildung 4.1). Generierung eines netzweit eindeutigen Dateinamenstrcode

Insgesamt existieren fünf verschiedene Präfixe für Dateinamen, die für netzweite Dateiübertragungen relevant sind:

• CS:
  Dieses Präfix haben Sende-Kontrolldateien, die ausschließlich beim Start einer Transaktion angelegt werden.
  Sie kommen nur auf dem NWP-Knoten vor, auf dem eine Transaktion initiiert wurde.
• DA:
  Hiermit sind Benutzerdateien gekennzeichnet, die Nutzdaten enthalten.
  Sie werden für eine Transaktion auf all den NWP-Knoten angelegt, die Teil der Route vom Ursprungs- zum Zielknoten sind.
• CR:
  CR-Dateien sind sogenannte Remote Node Kontrolldateien und bilden das Gegenstück zu den CS-Dateien: Sie beinhalten Kontrollinformation bezüglich der Transaktionen, die nicht am aktuellen Knoten initiiert wurden und kommen daher auf allen Knoten einer Route vor mit Ausnahme des Ursprungsknotens. Jeder Zwischenknoten ergänzt diese Dateien um seine Log-Einträge.
• CA:
  Dateien mit dem Präfix CA sind Administrations- und Kontrolldateien und enthalten Aufträge der Systemverwaltung (zum Beispiel Update der Wegedatei, Herunterfahren eines NWP-Knotens).
• QU:
  Das Präfix QU ist den Quittungsdateien vorbehalten. Sie werden vom Zielknoten nach Eintreffen der CR- und DA-Dateien und der Ausführung der geforderten Aktionen durch den Zielknoten erzeugt und zum Ursprungsknoten über dieselbe Route, allerdings in entgegengesetzter Richtung, transportiert, die die Benutzerdaten genommen haben. QU-Dateien werden wie DA-Dateien behandelt d.h. die Zwischenknoten nehmen an ihnen keine Änderungen vor.

Die Benutzerschnittstelle, das NWP-Menü, übergibt anschließend die zur Übertragung anstehende Datei dem Empfangsserver des Knotens, der sie umbenennt (d.h. ihr neuer Dateiname lautet dann DAKnotennamexxxx) und eine CS-Datei (CS Knotennamexxxx) mit Kontrollinformation erzeugt.
Beide Dateien werden dann auf dem Ursprungsknoten im Eingabebereich des NWP-Control Programs abgelegt. Das Control Program ist der Hauptbestandteil von NWP und wird im folgenden Teilabschnitt detailliert behandelt. Für die Fortführung der Diskussion der Dateiübertragungsmechanismen im NWP-Verbund wird das Control Program vorerst als ,,black box`` angesehen.
Nach Verarbeitung der CS- und DA-Dateien durch das Control Program werden diese anschließend einem von mehreren sogenannten Sendeservern übergeben. Zum Begriff ,,Server`` ist im Zusammenhang mit NWP folgendes anzumerken:
Mit ,,Server`` ist nicht etwa das Gegenstück zu ,,Client`` in einer Client/Server-Beziehung gemeint; ,,Server`` ist hier ein Synonym für ,,Ablauf eines Programms``, was in unterschiedlichen Systemwelten jeweils mit verschiedenen Begriffen umschrieben wird: In der VM-Welt als ,,Task`` und auf UNIX-Systemen als ,,Prozeß``. Um in der heterogenen NWP-Systemwelt konsistente Begriffsdefinitionen zu schaffen, wurde für die genannten Bezeichnungen der Oberbegriff ,,Server`` eingeführt.

Ein Sendeserver hat die Aufgabe, die Dateien mit Hilfe eines systemspezifischen Kommunikationsdienstes (ftp, DECNET copy...) zum benachbarten NWP-Knoten zu übertragen.
Bekanntlich kann man im NWP-Verbund nicht davon ausgehen, daß die Nachbarknoten eines NWP-Knotens alle denselben systemnahen Kommunikationsdienst verwenden. An einem NWP-Knoten müssen daher Sendeserver für alle an den Nachbarknoten verfügbaren Dateitransfer-Protokolle vorgehalten werden.

Nachdem der für die Übertragung ausgewählte Sendeserver die Nutzdaten- und Kontrolldateien dem Nachbarknoten übergeben -genauer: im Eingabebereich des Control Program des Nachbarknotens abgelegt- hat, wartet der NWP-Knoten auf die Quittung, die von diesem Nachbarknoten kommen muß.
Der Nachbarknoten (und alle weiteren NWP-Knoten bis hin zum Zielknoten) vollzieht dieselbe Prozedur (Control Program ausführen, Log-Information in Kontrolldatei schreiben, Sendeserver auswählen und diesem die Dateien übergeben, auf Quittung warten) wie der Ursprungsknoten, allerdings mit einer Ausnahme: Der Kontrolldateiname hat nun das Präfix CR, weil der aktuelle Knoten nicht der Ursprungsknoten ist.

Sind die Dateien am Zielknoten angekommen, werden die Nutzdaten (unter Beachtung der Angaben des Benutzers am Ursprungsknoten) abgespeichert und die Quittungsdatei für die gesamte Übertragung erzeugt.

Nun ist der erste Teil der Übertragung abgeschlossen und der gesamte Vorgang kehrt sich um: Der Zielknoten ist nunmehr Startknoten; die Quittungsdatei durchläuft denselben Weg in umgekehrter Richtung, den die DA-Datei genommen hat; der ehemalige Ursprungsknoten ist jetzt Zielknoten.
Bezüglich der Dateinamen ist bei der Rückübertragung der Quittung folgendes von Bedeutung:

1.

Der Transaktionscode des Dateinamens bleibt unverändert, weil das Senden der Quittung zur selben Transaktion gehört wie der Sendevorgang für die Nutzdaten.

2.

Die Kontrolldatei für die Rückübertragung hat nicht das Präfix CS (obwohl der Knoten jetzt strenggenommen Ursprungsknoten ist), sondern behält das Präfix CR bei.

Die Quittungsdatei wird demnach auf der gesamten Route von einer CR-Kontrolldatei begleitet, die ihrerseits von jedem Knoten auf der Route um Log-Informationen ergänzt wird.

Sind die Quittungs- und Kontrolldateien am Ursprungsknoten eingetroffen, ist die Transaktion beendet. Abbildung 4.2 skizziert die Reihenfolge der Schritte einer Dateiübertragung mit NWP.

Bei Dateiübertragungen praktiziert das NetzWerk-Programm Teilstreckenvermittlung nach dem store-and-forward Prinzip.

Dateiübertragung mit dem NetzWerk-Programmtransfer