Rechnernetze: Entwurf und Realisierung 9783110854176, 9783110089516

Citation preview

de Gruyter Lehrbuch Schnupp • Rechnernetze

Peter Schnupp

Rechnernetze Entwurf und Realisierung 2., gründlich überarbeitete Auflage

W DE G_ Walter de Gruyter • Berlin • New York 1982

Dr. rer. nat. Peter Schnupp, Mitinhaber der Firma InterFace GmbH in München, Lehrbeauftragter für Systemprogrammierung an der Universität Linz

Das Buch enthält 107 Abbildungen und 9 Tabellen

CIP-Kurztitelaufnahme der Deutschen Bibliothek Schnupp, Peter: Rechnernetze : Entwurf u. Realisierung / Peter Schnupp. - 2., gründl. Überarb. Aufl. - Berlin ; New York : de Gruyter, 1982. (De-Gruyter-Lehrbuch) ISBN 3-11-008951-3

© Copyright 1982 by Walter de Gruyter & Co., vormals G. J. Göschen'sche Verlagshandlung, J. Guttentag, Verlagsbuchhandlung Georg Reimer, Karl J. Trübner, Veit & Comp., Berlin 30. Alle Rechte, insbesondere das Recht der Vervielfältigung und Verbreitung sowie der Übersetzung, vorbehalten. Kein Teil des Werkes darf in irgendeiner Form (durch Photokopie, Mikrofilm oder ein anderes Verfahren) ohne schriftliche Genehmigung des Verlages reproduziert oder unter Verwendung elektronischer Systeme verarbeitet, vervielfältigt oder verbreitet werden. Printed in Germany. Satz und Druck: G. Wagner, Nördlingen. Bindearbeiten: Lüderitz & Bauer Buchgewerbe GmbH, Berlin.

Vorwort zur ersten Auflage

Dieses Buch entstand aus einem selbst empfundenen Mangel: dem unerfüllten Wunsch nach einer Einführung in das Gebiet der Rechnernetze und der Datenverbundsysteme, welche auf die Bedürfnisse und Vorkenntnisse des SoftwareEntwicklers abgestimmt ist. Er ist es gewohnt, ein EDV-System „top down", ausgehend von der Benutzerschnittstelle, zu verstehen und zu planen. Die Mehrzahl der vorliegenden Publikationen beginnt die Darstellung jedoch mit der Hardware und den sie verbindenden Leitungen - ein Ansatz, welcher dem Nachrichtentechniker weit mehr liegt als dem Informatiker. Im Rahmen einer Reihe von Seminaren wurde deshalb die Struktur einiger typischer Rechnernetze „von oben nach unten" analysiert. Das Ziel war, eine ähnlich geschlossene Vorstellung über den Aufbau und die wesentlichsten Entwurfsprinzipien eines Netzes zu erarbeiten, wie sie ein erfahrener Software-Planer auch für einen Compiler oder ein Betriebssystem hat. Ausgangspunkt hierfür waren einerseits die wichtigsten Veröffentlichungen, zum anderen aber auch die Erfahrungen, welche bei der Bearbeitung einiger größerer Netzprojekte gewonnen worden waren. Aus der Aufbereitung des so erhaltenen Materials entstand das vorliegende Buch. Es ist vo wiegend für den praktisch arbeitenden Informatiker bestimmt und bemüht sich, die notwendigen theoretischen Grundlagen soweit anzudiskutieren, daß eine Vertiefung an Hand der Literatur keine allzugroßen Schwierigkeiten mehr bieten sollte. Das Buch wendet sich also vor allem an Software-Spezialisten, erfahrene Programmierer und fortgeschrittene Studenten der Informatik. Auch als Lehrbuch für eine Einführungsvorlesung in dieses Gebiet sollte es nützlich sein. Wenn es darüber hinaus Nachrichtentechnikern und Hardware-Entwicklern hilft, die Probleme und Denkweise der Software-Planer besser zu verstehen, und damit einen Beitrag zur Verbesserung des unbedingt nötigen Dialogs zwischen diesen beiden Partnern einer Netzentwicklung leistet, würde der Verfasser sich freuen. München, im November 1977

Peter Schnupp

Vorwort zur 2. Auflage

Wie in einem jungen, schnell wachsenden und für die Praxis wichtigen Fachgebiet nicht anders zu erwarten, wuchs das relevante Material, welches eine Einführung in das Feld der Rechnernetze bringen sollte, im Verlauf von nur zwei Jahren so stark an, daß für die Neuauflage eine gründliche Überarbeitung nötig erschien. Zwar verloren die in der ersten Auflage dargestellten Fakten nicht ihre Gültigkeit, und auch der Ansatz, sie dem Leser „top down", von der Benutzerschnittstelle zur physikalischen Realisierung, nahezubringen, scheint gelungen zu sein und wurde für die neue Fassung beibehalten. Anderseits stellte sich aber schon bei einem Seminar, das der Verfasser im Spätherbst 1979 abhielt, heraus, daß etwa die Hälfte des dort behandelten Stoffs in dem doch gerade erst etwas über ein Jahr alten Lehrbuch noch nicht enthalten war! Die Neuauflage wurde deshalb zum Anlaß genommen, das Buch wesentlich zu ergänzen. Neben kleineren Korrekturen und Zusätzen in fast jedem Abschnitt wurden umfangreiche Erweiterungen vor allem dort vorgenommen, wo die Forschung und Entwicklung der letzten zwei Jahre die meisten neuen Begriffsbildungen und Einsichten brachte: - in den Spezifikations- und Entwurfsmethoden (Kap. 12) und - der internationale Normungs- und Standardisierungsarbeit und insbesondere dem allgemeinen Konzept des „offenen Systems", welches dem „ISO-Architekturmodell" zu Grunde liegt (Kap. 9). Mit der Aufnahme dieser Ergänzungen hofft der Verfasser, mit der neuen Auflage wieder dem Leser all das Material über Rechnernetze zur Verfügung zu stellen, was er für einen Überblick über den derzeitigen Stand dieses Gebiets und als Grundlage für das Verständnis der speziellen Fachliteratur braucht. München, im Juni 1982

Inhalt

Einführung 1. Grundbegriffe und Grundstrukturen 1.1 Kommunikation zwischen Rechnern 1.2 Aufgaben und Aufbau typischer Rechnernetze 1.3 Physische und logische Struktur von Rechnernetzen 1.4 Benutzeranforderungen 1.5 Realisierungsprobleme

10 12 12 17 24 30 34

2. Die Benutzerschnittstellen 2.1 Die nichtlokalisierte Maschine 2.2 Bedienungssprache und Terminals 2.3 Die verteilte Datenbasis 2.4 Zugriffsverfahren 2.5 Das Netz-Betriebssystem

37 37 39 44 48 55

3. Das verteilte System 3.1 Betriebsmittel- und Prozeßverwaltung 3.2 Betriebsmitteladressierung im Netz 3.3 Adressierung in der SNA 3.4 Ports

59 59 62 64 66

4. Netzwerkmaschinen und Netzzustände 4.1 Nachrichten und Netzwerkmaschinen 4.2 Steuerinformationen und Zustandsübergänge 4.3 Untersysteme und ihre Zustände 4.4 Grundforderungen an Protokolle im Netz

74 74 78 81 84

5. Protokolle 5.1 Die Protokollhierarchie im ARPA-Netz 5.2 Die Protokolle des Datenübertragungs-Netzes 5.3 Höhere Protokollebenen 5.4 Grundregeln für die Protokollplanung 5.5 Die Realisierung eines Protokolls

87 87 87 91 95 96

6. Die Netzschnittstelle und die Flußsteuerung 6.1 Das Netz-Kommunikationsprogramm 6.2 Netzüberlastung und Betriebsmittelverwaltungs-Strategien 6.3 Grundverfahren der Flußsteuerung

. . .

99 99 103 106

8

Inhalt

6.4 Globale Flußsteuerungen auf Verbindungsbasis 6.5 Globale Flußsteuerungen auf Nachrichten- oder Paketbasis . . .

107 110

7. Netzstrukturen und Laufwege 7.1 Netz-Topologien 7.2 Durchschaltungen, virtuelle Verbindungen und Datagramme . . 7.3 Pakete 7.4 Wegwahl 7.5 Der „kürzeste Weg" als Laufwegbestimmungs-Strategie . . . . 7.6 Blockierungen im Netz

113 113 117 119 124 130 133

8. Leitungen und Knotenrechner 8.1 Struktur der IMP-Software 8.2 Übertragungsleitungen 8.3 Modulation und Leitungssteuerung 8.4 Ökonomie der Leitungsauslastung 8.5 Lokale Belastungen und globale Übertragungseigenschaften 8.6 Kanalbelastungs-Begrenzung

137 137 141 144 146 148 150

. .

9. Das ISO-Architekturmodell 9.1 Standards und Normen 9.2 Schichten, Instanzen und Dienste 9.3 Die Transportschichten 9.4 Die Anwendungsschichten

153 153 154 158 160

10. Auslegung und Optimierung eines Netzes 10.1 Der Verwaltungsaufwand in den Protokollebenen 10.2 Optimierungsgesichtspunkte 10.3 Prioritäten für Nachrichten und Pakete 10.4 Fehlerbehandlung und Flußsteuerung 10.5 Sende- und Empfangsfenster 10.6 Resynchronisierung durch „Attention and Mark"

164 164 169 173 174 178 180

11. Realisierung und Betrieb eines Rechnernetzes 11.1 Spezifikation 11.2 Planung 11.3 Implementierung und Weiterentwicklung 11.4 Betriebsüberwachung und Netzsteuerung 11.5 Der Verbund von Netzen

183 183 185 188 191 194

12. Entwurfs- und Programmiermethoden in einer Netzumgebung . . . . 12.1 „Lokalisierte" und „verteilte" Anwendungsprogrammierung . . 12.2 Zum Datenmodell: Kommunikationsvariable 12.3 Zum Ablaufmodell: Zustandsdiagramme

202 202 202 204

Inhalt 12.4 Zum Kommunikationsmodell: Interaktionsdiagramme 12.5 Zum Modularisierungsmodell: Spezifikationsmittel 12.6 Zur Auftrags- und Betriebsmittel-Steuerung: Auftragsvariablen Anhang: Datennetz-Terminologie Literatur Sachregister

9 210 215 219 221 245 258

Einführung

Spezifikation, Planung und Implementierung von Rechnerverbundnetzen werden noch weitgehend „Bottom Up" betrieben, von der physikalischen Realisierung der Übertragungsleitungen und der Netzknoten über den Anschluß der Terminals und Teilnehmerrechner (Hosts) bis zur Benutzerschnittstelle. Dies ist verständlich. Schließlich ist der Grund für den Aufbau eines Netzes die räumliche Verteilung der Benutzer und der Betriebsmittel, der Rechner und Datenbestände, und damit die notwendige Datenübertragung. Trotzdem - die Neue Softwaretechnologie bevorzugt die Top Down-Entwicklung. Auch für eine Netzplanung ist dies ein sinnvoller Ansatz, wenn auch die Berücksichtigung der übertragungstechnischen, physischen Gegebenheiten und Einschränkungen hier bei jedem Entwicklungsschritt von noch größerer Bedeutung sein wird als auf fast allen anderen Gebieten der Datenverarbeitung. Deshalb verfolgt dieses Buch die innere Logik und die sachlichen Alternativen eines Netzentwurfs von „oben", den Benutzern, nach „unten", den physischen Komponenten. Wichtig für das Verständnis eines Netzentwurfs ist die Trennung der logischen Konzepte von ihrer physischen Realisierung. In den Abbildungen dieses Buches soll dem Leser hierbei eine grundsätzliche Unterscheidung helfen: - logische Einheiten (z. B. die abstrakte „Netzwerkmaschine") werden als runde oder ovale Symbole, - physische Einheiten (z. B. ein Host- oder IMP-Rechner) als eckige Symbole dargestellt. Im übrigen versuchte der Autor weitgehend auf Formeln, Algorithmen und Formalismen zu verzichten - über die Literaturzitate kann der Leser sie leicht im Direktzugriff erreichen. Das Ziel, möglichst viel Information in deutscher Prosa zu vermitteln, drohte an einer unvorhergesehenen Schwierigkeit zu scheitern. Für eine Reihe von Begriffen (z. B. „Gateway") kennt der Verfasser kein deutsches Wort, für andere (z. B. „Netz-Kommunikationsprogramm") mehr als eines. Deshalb wurde in diesen Fällen willkürlich ein Ausdruck ausgewählt und vor Anglismen nicht zurückgeschreckt - die im Anhang gegebene „Datennetz-Terminologie" hilft vielleicht, den in diesem jungen Zweig der Datenverarbeitung leider vorhandenen Begriffswirrwarr zu entflechten.

1. Grundbegriffe und Grundstrukturen

1.1 Kommunikation zwischen Rechnern Voneinander unabhängige Rechner können auf die verschiedensten Weisen gekoppelt werden. Abb. 1.1-1 skizziert die hierfür am häufigsten eingesetzten Methoden. Das Hauptthema dieses Buches ist die in Abb. 1.1-1 d gezeigte Kommunikation über Datenübertragungsleitungen - nicht nur zwischen zwei, sondern auch zwischen grundsätzlich unbeschränkt vielen, weitgehend voneinander unabhängigen EDV-Anlagen, einem Rechnerverbund oder Rechnernetz. Der Grund für das Zwischenschalten einer Telex-, Datex-, Telefon- oder sonstigen Übertragungsleitung ist hierbei meist eine räumliche Entfernung von mehr als einigen 100 m zwischen den einzelnen teilnehmenden Rechnern, welche die übrigen in Abb. 1.1-1 dargestellten Kopplungsmöglichkeiten aus technischen Gründen ausschließt: - einen gemeinschaftlich benutzten Arbeitsspeicher, in welchem ein oder mehrere Kommunikationsbereiche von den beteiligten Rechnern zur Ablage und zum Empfang von Nachrichten verwendet werden, - eine Kopplung der E/A-Kanäle der Rechner, wobei jeder Rechner den anderen als „Externspeicher" ansieht, - einen gemeinsamen Externspeicher, der über einen Mehrkanalschalter rechnergesteuert mal der einen, mal der anderen Anlage zugeordnet wird. Viele der Probleme einer Rechnerkopplung sind jedoch unabhängig von ihrer technischen Realisierung. Dies gilt vor allem für die softwaretechnischen Fragen der Kommunikation zwischen den in den einzelnen Rechnern ablaufenden Prozesse und der Protokolle zur Verbindungsaufnahme, zur Sicherung des Nachrichtenverkehrs und zur Fehlererkennung und -behebung bei einem derartigen Dialog zwischen Rechnern. Welches Verfahren gewählt wird, bestimmen technische, ökonomische und einsatzorientierte Erwägungen. Hierbei ist die - unvermeidliche oder gewünschte - räumliche Trennung zwischen den beteiligten Rechnern sowie den gegebenenfalls zu ihrer Benutzung dienenden Terminals nur eines der Kriterien, freilich oft auch das ausschlaggebende. Der Wunsch, EDV-Anlagen miteinander kommunizieren zu lassen, hat meist einen oder mehrere der folgenden Gründe: Eine Spezialisierung für bestimmte Dienstleistungen läßt es oft sinnvoll erscheinen, für unterschiedliche Arbeiten auch unterschiedliche Rechner einzusetzen. Erst ihr Zusammenwirken bietet dem Benutzer das volle Leistungsspektrum. So können

1.1 Kommunikation zwischen Rechnern

13

(b) Kanalkopplung

Exteinspeicherkopplung

Q f ) Kopplung über eine Datenübertragungsleitung Abb. 1.1-1 Kopplung zwischen unabhängigen Rechnern

für Meß- und Steuerungsaufgaben in einem Produktionsbetrieb oder einem Krankenhaus Prozeßrechner die zweckmäßige Hardware sein, während für die langfristige Haltung und Auswertung der umfangreichen Datenbestände kommerzielle Großrechner eingesetzt werden [RAIM 76].

14

1. Grundbegriffe und Grundstrukturen

In einem weitverzweigten Filialunternehmen oder einer öffentlichen Verwaltung werden für die Erfassung, Prüfung und Bearbeitung lokal relevanter Daten kleine Erfassungsrechner gebraucht, für die globale Auswertung der Datenbestände jedoch größere Anlagen in den Zentralen. Eine EDV-Installation für wissenschaftlich-technische Forschungsaufgaben verwendet für die „normale" Datenhaltung und -Verarbeitung auch „normale" Großrechenanlagen, für besondere Aufgaben wie die schnelle Durchführung von Matrixoperationen benötigt sie jedoch vielleicht mit ihnen zusammenarbeitende Spezialmaschienen wie Feld- und „Pipeline"-Rechner. Eine der frühesten Spezialisierungen schließlich war die hardwaremäßige Trennung von Ein-/Ausgabe und Verarbeitungsvorgängen: die Architektur der CDC 6600- und 7600-Systeme beruhte auf der Aufteilung des EDV-Systems in einen Zentralrechner zur effizienten Bearbeitung numerischer Probleme und zehn mit ihm gekoppelten, kleineren Peripheren Prozessoren zur Bedienung der Peripherie und zur Steuerung der Gesamtanlage. Die Erhöhung der Zuverlässigkeit und der Verfügbarkeit ist das zweite Motiv zum Verbund von Rechnern. Für kritische Steuerungs- und Kommunikationsaufgaben, vor allem im militärischen und industriellen Bereich, wurden bereits früh mehrere Rechner gekoppelt: entweder mit einer parallelen Bearbeitung identischer Daten und Aufgaben durch zwei bis drei grundsätzlich unabhängige Anlagen (hot standby) oder mit der Bereitstellung von Zweit- und Drittrechnern, auf die automatisch oder manuell bei Ausfall der primären Anlage umgeschaltet werden konnte (cold stand-by). Auch die räumlich getrennte Führung identischer Datenbestände wird aus Sicherheitsgründen zuweilen verlangt - zum Schutz wichtiger Daten gegen Zerstörung durch Krieg, Terrorismus, Unfälle oder Naturkatastrophen. Eine Verringerung der mittleren Wartezeiten kann durch den Verbund mehrerer identischer Hardware-Systeme erreicht werden, die über den Arbeitsspeicher, über eine gemeinsame Plattendatei für das SPOOL-System oder auch über Datenübertragungsleitungen gekoppelt sind. Wie stark die durchschnittlichen Wartezeiten bei hohen Auslastungen durch einen Lastausgleich zwischen mehreren Prozessoren gesenkt werden können, zeigt eine Abschätzung für die beiden in Abb. 1.1-2 dargestellten Modellsituationen. Im Single Server-Fall © treffen für m gleiche Prozessoren PI bis Pm in statistischer Folge Aufträge ein. Sie werden jeweils in der Warteschlange ihres Prozessors zwischengepuffert. Die mittlere Auslastung jedes Prozessors durch die Aufträge sei A, die mittlere Ausführungszeit (Service-Zeit) für einen Auftrag sei Ts. Im Multiserver-Fall ® werden hingegen alle eintreffenden Aufträge in eine einzige Warteschlange zusammengeführt, aus der einem freiwerdenden Prozessor jeweils der nächste Auftrag zugeteilt wird. Im Unterschied gegenüber Fall © ist sichergestellt, daß jeder der m Prozessoren arbeitet, solange überhaupt noch Aufträge warten.

15

1.1 Kommunikation zwischen Rechnern

— \ I I I I I — W

^

n

P2

^

I I I I I

—

H « \

M

^

I I I 1

Pm)—

( a ) m „Single Server" gleicher Kapazität mit getrennten Warteschlangen

'

,

P2

^

M

'

p m

( b ) m „Multiserver" mit gemeinsamer Warteschlange

Abb. 1.1-2 Single Server- und Multiserver-System

Nach der Warteschlangentheorie ([KLEI76b], S. 280ff.) gilt bei exponentieller Verteilung der statistischen Größen für die mittlere Wartezeit T von der Anmeldung eines Auftrags bis zur Fertigmeldung T

=

Z

(1 +

Pm (A) m n(1-A)

Pm (A) ist die Wahrscheinlichkeit, daß das Gesamtsystem m oder mehr Aufträge bearbeiten muß, d. h. daß alle Prozessoren ausgelastet sind; sie ist gegeben durch Pm (A) = (1 +

(1-A)m • ml

m 7

(mA)™

k=Q

~ 2

(mA)k , —)'' k!

Für m = 1 ist sie gleich der Auslastung A. Für das Single Server-System folgt als mittlere Wartezeit T = Ts • (1 + — ) . 1-A Bei einer Auslastung von 80% hat sie mit A = 0,8 den Wert T = 5 • Ts - sie ist also fünfmal länger als die reine Ausführungszeit eines Auftrags. Arbeiten jedoch im Multiserver-Fall m = 5 Prozessoren auf die gleiche Warteschlange, so ergibt sich Ps (0,8) = 0,7885 und T = 1,7885 • Ts. Gegenüber dem Single Server-Fall ist die mittlere Wartezeit also auf fast ein Drittel reduziert! Noch ausgeprägter ist die Senkung der durchschnittlichen Wartezeiten, wenn die im Verbund zusammenarbeitenden Prozessoren durch die lokalen Anforderungen ohnehin nicht gleichmäßig ausgelastet wären und schwach belastete Systeme den überlasteten Arbeit abnehmen können. Dies ist auf Grund der geographischen Ausdehnung der USA bei den unter dem TENEX-System laufenden PDP10-

16

1. Grundbegriffe und Grundstrukturen

Installationen des ARPA-Netzes der Fall, welches mehrere Zeitzonen überdeckt. Der Trend zur Online-Datenverarbeitung über dialogfähige Bildschirm- oder Fernschreib-Terminals ist ein weiteres Motiv zum Aufbau von Rechnernetzen. Abb. 1.1-3 zeigt die Zunahme der Anzahl installierter Terminals in Europa, Abb. 1.1-4 die Entwicklung der relativen Kostenanteile für Terminals, Rechner und Millionen

Abb. 1.1-3 Erwarteter Anstieg der Zahl der in Europa eingesetzten Terminals

1970

1980

Abb. 1.1-4 Kostenverteilung einer typischen Datenübertragungs-Anwendung

1.1 Kommunikation zwischen Rechnern

17

Leitungsmieten bei einer typischen Datenübertragungsanwendung [INF077]. Sobald die Leitungskosten den überwiegenden Kostenfaktor darstellen, wird es wirtschaftlich sinnvoll, durch Verteilung der Rechnerkapazität und Datenhaltung einen möglichst großen Teil der Datenverarbeitung an die Aufstellungsorte der Terminals, also etwa in die einzelnen Filialen eines Handelsunternehmens selbst zu verlagern, und über den Verbund dieser Rechner nur diejenigen Daten und Informationen zwischen ihnen auszutauschen, die wirklich überregional benötigt werden. Die Erweiterung des Dienstleistungsangebots und der verfügbaren Betriebsmittel schließlich ist der wohl häufigste Grund zum Verbund mehrerer Rechner. Nur auf einzelnen Rechnern verfügbare Programmiersprachen, Betriebs-, Datenbank- und Informationssysteme oder besonders leistungsfähige Hardware können durch Eingliederung in ein Rechnernetz auch Benutzern anderer Anlagen zur Verfügung gestellt werden. Für das ARPA-Netz wurden im März 1973 die Einsparungen ermittelt, welche 20 Teilnehmer-Installationen hierdurch erzielten [ROBE74]. Umgerechnet auf das volle Jahr mußten sie statt etwa 6 Mio $ bei Eigenbeschaffung der benötigten Betriebsmittel nur ca. 2 Mio $ an Kostenbeteiligungen und Gebühren für Rechenzeiten bezahlen. Den so ersparten 4 Mio $ standen Kosten für den Betrieb des Netzes mit 3,5 Mio $ gegenüber. In Anbetracht der Tatsache, daß damals das ARPA-Netz zu nur etwa 20% ausgelastet war, dürfte die Bilanz inzwischen noch wesentlich günstiger sein. Je nachdem, ob ein Rechnerverbund auf eine Vervielfachung oder gleichmäßigere Verteilung der Rechnerleistung, auf die Verfügbarkeit von Betriebsmitteln eines EDV-Systems auch für andere Rechner oder auf eine Integration aller systemweit gehaltenen Einzel-Datenbestände abzielt, spricht man von einem Lastverbund, Betriebsmittelverbund oder Datenverbund. Wird schließlich eine Leistungserhöhung des Gesamtsystems dadurch erreicht, daß verschiedene Prozesse in den gekoppelten Einzelsystemen jeweils einen logisch abgetrennten Teilbeitrag zum Erreichen des Gesamtziels erbringen, so bezeichnet man dies als Intelligenzverbund.

1.2 Aufgaben und Aufbau typischer Rechnernetze Die verschiedenen Motivationen zur Kopplung mehrerer EDV-Systeme zu einem Rechnernetz führen zu Systemlösungen, die sich vor allem in der Hardwarestruktur und der Topologie der physischen Leitungsführung unterscheiden. Diese Unterschiede beeinflussen die Hardwareauswahl, die Wahl der Datenübertragungsmedien, -verfahren und -techniken, die „niederen" Ebenen der Datenübertragungssoftware, Leistungs- und Kostenoptimisierungen und - natürlich - die zu realisierenden Benutzerschnittstellen. Sie verdecken damit aber auch häufig die in

18

1. Grundbegriffe und Grundstrukturen

allen Netzen wiederzufindenden Gemeinsamkeiten der Grobstruktur und der Basisbausteine der Rechnernetz-Software. Trotzdem empfiehlt es sich, vor der Idealisierung einer abstrakten Netzarchitektur als konkrete Beispiele einige realisierte Rechnernetze vorzustellen. Letztlich ist der Grund für die Planung eines Netzes immer „physisch": eine aufgabenspezifisch vorgegebene Verteilung der Rechnerdienstleistungen, welche die einfachere und ökonomischere Lokalisierung der EDV-Installation ausschließt. zu anderen europäischen Bahn-Netzen

f^

ra

| : Terminals

zentraler Knoten

: Konzentratoren : DV-Zentrum der ÖBB

Abb. 1.2-1 (Sub-)Netz der Österreichischen Bundesbahn

Die räumliche Verteilung der Benutzer ist das Hauptmotiv für den Aufbau vieler Datenerfassungs- und Informationsnetze von Großfirmen, Behörden, öffentlichen Dienstleistungsunternehmen und ähnlichen Institutionen. Ein Beispiel ist das in Abb. 1.2-1 gezeigte Netz der Österreichischen Bundesbahn, welches zugleich Subnetz in einem Verbund der europäischen Bahnverwaltungen ist. Seine Hauptaufgaben sind

1.2 Aufgaben und Aufbau typischer Rechnernetze

19

- Datenerfassung am Ort der einzelnen Bahnhöfe und Dienststellen, - Auskunftserteilung über die 70 000 Bediensteten der ÖBB, - Voranmeldung der Güterzüge an jedem Bahnhof und Lenkung des Güterverkehrs durch Steuerung der Zugzusammenstellung, - Speichervermittlung von Fernschreiben, - Platzbuchung in Zusammenarbeit mit dem automatischen Buchungssystem der Deutschen Bundesbahn. Für jeden Bezirk gibt es ein Bezirksnetz mit einem Konzentrator und angeschlossenen Terminals unterschiedlicher Intelligenz. Die Aufgaben der Konzentratoren sind - Plausibilitätsprüfungen der Terminaleingaben, - Laufwegermittlung und Weiterleitung der Nachrichten an den oder von dem zentralen Knoten in Wien. Die Konzentratoren sind mit dem zentralen Knoten über ein mehrfach vermaschtes Netz von 1200 baud-Leitungen verbunden. Der zentrale Knoten - übernimmt die Nachrichtenvermittlung zwischen Konzentratoren, DV-Zentrum in Wien und anderen europäischen Bahn-Netzen, - überprüft die Terminalberechtigung bei Dienstleistungswünschen und Anfragen, wie etwa einer Personalauskunfts-Anforderung, - überwacht das Gesamtnetz, - führt Statistiken über den Betrieb des Netzes. Die räumliche Verteilung von angebotenen Dienstleistungen und Betriebsmitteln gab Anlaß zur Entwicklung von Rechnernetzen, die im wesentlichen die Datenbestände, Programme und Betriebsmittel verschiedener lokaler Dienstleistungsrechenzentren für wissenschaftlich-technische oder kommerzielle Anwendungen miteinander verbinden und damit jedem Benutzer bei Bedarf die Leistungen aller beteiligten Rechnerinstallationen verfügbar machen sollen. Beispiele sind das amerikanische ARPA-Netz [LOGI74] oder das französische CYCLADES-Netz [POUZ73], welches in Abb. 1.2-2 skizziert ist. CYCLADES verbindet 16 Teilnehmerrechner (Hosts) von 6 verschiedenen Typen unter 8 verschiedenen Betriebssystemen und stellt auf ihnen den Netzbenutzern sowohl Timesharing- als auch Stapelverarbeitungs-Dienstleistungen zur Verfügung. Das ARPA-Netz, an welches neben Rechenzentren in der gesamten USA auch noch einige europäische EDV-Installationen über Satelliten angeschlossen sind, umfaßt mehrere Zeitzonen und dient damit auch dem Ausgleich der räumlichen Verteilung der zeitlichen Anforderungsschwerpunkte.

20

1. Grundbegriffe und Grundstrukturen

48 kb-Leitung 4,8 kb-Leitung

••

Knotenrechner Teilnehmerrechner („Hosts", 6 verschiedene Typen) Hosts können mit mehreren Knotenrechnern verbunden sein

Abb. 1.2-2 Das CYCLADES-Netz

Der Wunsch nach Nutzung aller verfügbaren Betriebsmittel - vor allem von Peripheriegeräten - für verschiedene, vorhandene Rechner führt zur Idee des Resource Sharing-Netzes. Ein Vertreter dieses Typs ist das Octopus-System der Lawrence Livermore Laboratories [WATS80], welches Abb. 1.2-3 skizziert. Hier wurde für jede Betriebsmittel-Klasse ein eigenes Netz aufgebaut, an welches einerseits die entsprechenden Peripheriegeräte und andererseits sämtliche bedienten Rechenanlagen angeschlossen sind.

1.2 Aufgaben und Aufbau typischer Rechnernetze

21

Die Octopus-Konfiguration hat den Vorteil, daß jedes der spezialisierten Netze auf die Eigenschaften des zugeordneten Betriebsmittels abgestimmt werden kann. Dafür müssen die beteiligten Rechner neben ihrer eigentlichen Arbeit jedoch aufwendige Durchschaltfunktionen zwischen den einzelnen Teilnetzen übernehmen: sie arbeiten als Gateways, auf deren Probleme in Abschn. 11.5 näher eingegangen wird. Dies kann leicht zu ihrer Überlastung führen, da ein normaler Großrechner für derartige Aufgaben technisch nicht ausgelegt ist - so wird in [WATS80] berichtet, daß zuweilen ein C D C 7600-Rechner ausschließlich mit der Übertragung einer Datei beschäftigt ist!

Abb. 1.2-3 „Resource Sharing"-Netz

22

1. Grundbegriffe und Grundstrukturen

Deshalb wurde für das Nachfolgersystem von Octopus ein anderes Konzept gewählt, bei dem sämtliche Peripheriegeräte und Verarbeitungsrechner an einem gemeinsamen „Broadcast-Trunk"-Vermittlungssystem hängen. Diese Konfiguration entspricht dann weitgehend einer „Architektur offener Systeme", aufweiche die derzeitige Standardisierungsarbeit hinzielt und auf die in Kapitel 9 ausführlich eingegangen werden wird. Bei der Diskussion von DV-Netzen werden schließlich die im Rahmen von öffentlichen oder privaten Datenübertragungsnetzen zusammenarbeitenden Rechner häufig vergessen. Auch sie bilden oft sehr komplexe Rechnernetze, wobei die beteiligten EDV-Anlagen jedoch nicht die Bearbeitung von Benutzeraufgaben sondern den Nachrichtenverkehr über das Netz selbst sowie ggf. Dienstleistungen übernehmen, welche mit diesem Nachrichtenverkehr zusammenhängen ( z . B . Abrechnung, Statistik, Speichervermittlung). Neben dem Vermittlungsdienst bietet die Bundespost durch eigene Systeme auch noch netzbezogene Dienstleistungen, wie etwa die Automatische Telexauskunft, die auf Anfrage selbsttätig Auskunft über Telexnummern oder Teilnehmeranschriften erteilt. Abb. 1.2—4 skizziert schematisch das Fernschreibnetz der Deutschen Bundespost. Die Vermittlung von Verbindungen zwischen Fernschreibteilnehmern wird über zentrale Vermittlungsrechner (EDS = Electronic Data Switch) durchgeführt, welche auch für die Gebührenberechnung und ähnliche Aufgaben zuständig sind. Neben dem Direktanschluß von Fernschreibern an die EDS-Zentralen ist der Anschluß von Nebenstellen-Anlagen oder Sondernetzen möglich, die über eigene, kleinere Vermittlungsrechner verfügen. Diese Nebenstellenrechner erfüllen ihrerseits weitere Dienste, wie etwa die interne Gebührenüberwachung, Speichervermittlung, externe und interne Rundschreiben, automatische Generierung von Standardtexten, Textspeicherung und -editierung. In einigen Ländern wie den USA (TYMNET [SCHW76]), stehen derartige öffentliche Netze bereits auch ausschließlich für den Datenverkehr zwischen Rechnern zur Verfügung. Wegen der Ergänzung der Vermittlungsfunktion durch zusätzliche Dienstleistungen - vor allem der gemeinsamen Benutzung einer physischen Leitung durch mehrere Teilnehmer - und der damit verbundenen „Werterhöhung" jeder Einzelleitung werden sie oft als Value Added Networks (VAN) bezeichnet. In der Praxis wird ein konkretes Netz freilich oft mehr als einer Aufgabe dienen, und es ist nicht leicht vorauszusagen, wo später die tatsächlichen Schwerpunkte seines Einsatzes liegen werden. Laut McQuillan [MCQU80] war das ARPA-Netz ursprünglich zwar als Resource-Sharing-Netz konzipiert worden, wurde dann aber von seinen Benutzern primär als schnelles und bequemes Nachrichten-Medium („Elektronische Post") eingesetzt.

1.2 Aufgaben und Aufbau typischer Rechnernetze

23

private Nebenstellenanlage, ggf. privates Netz (Großfirma, Behörde o. ä.)

\ \ \

Einzelleitungen ^ B H H H

Leitungsbündel (Trunk Lines)

Abb. 1.2-4 Das Fernschreibnetz der DBP

/ / /

mehrere Einzelleitungen

24

1. Grundbegriffe und Grundstrukturen

1.3 Physische und logische Struktur von Rechnernetzen Die Vielfalt der Gründe, die zum Aufbau eines Rechnernetzes führen können, bedingt eine Vielfalt der Entwurfsvorgaben, der bei der Realisierung gegeneinander abzuwägenden Zuverlässigkeits- und Effektivitätsgesichtspunkte, der sinnvollen Leitungsführung und -auslegung, der Anordnung der verschiedenen Rechner und sonstigen Betriebsmittel sowie der Aufgabenteilung zwischen ihnen. U m überhaupt eine einheitliche Entwicklungsmethode für DV-Netze erarbeiten zu können, welche jeweils einer bestimmten Aufgabe angepaßt und - wenn nötig modifiziert werden kann, muß man von einer Netz-Grobstruktur ausgehen, die als Idealisierung der unterschiedlichen konkreten Realisierungen angesehen werden kann. Bei jedem DV-System lassen sich zwei wesentliche Strukturen unterscheiden: - die physische Struktur, d. h. die einzelnen eingesetzten Rechner, Terminals und sonstigen Betriebsmittel, die technischen Übertragungselemente wifc Leitungen und Modems, sowie ihre gegenseitige (konkrete) Anordnung und Zusammenschaltung, und - die logische Struktur von Daten und Prozessen sowie deren Wechselwirkungen systemintern oder -extern in Kommunikation mit der Umgebung (Benutzern an Terminals, Meß- und Steuereinrichtungen u. ä.). Die Aufgabe jeder Software ist die Abbildung der logischen Struktur auf die physische, der Benutzermaschine auf die Hardware und auf die als Teil von ihr aufzufassende, bereits vorhandene Basissoftware wie Sprachübersetzer, Hersteller-Betriebssysteme und -Dienstleistungsprogramme. Die in Abb. 1.3-1 und 1.3-2 gezeigten physischen und logischen Grundstrukturen eines Netzes charakterisieren damit zugleich die wesentlichen Teilaufgaben eines Netzentwurfs: - die konkrete Auswahl und Anordnung der Hardware-Strukturelemente, - die für die jeweilige Anwendung optimale Realisierung der gewünschten logischen Struktur sowie - die Zuordnung von logischen und physischen Strukturelementen. Die physische Struktur skizziert Abb. 1.3-1: verschiedene Arten von HardwareElementen werden durch Datenübertragungsleitungen zu einem Netz verbunden. Die im Netz zusammengeschlossenen Hardware-Einheiten können jeweils als an einem Ort lokalisiert angesehen und damit durch eine Adresse identifiziert werden.

1.3 Physische und logische Struktur von Rechnernetzen

25

Abb. 1.3-1 Physische Struktur eines Rechnerverbundnetzes

Diese Adresse ist eine Bit- oder Zeichenfolge, welche eine mnemonische Bedeutung haben kann, aber nicht muß. Nach ihrer Funktion im Netz unterscheiden wir vier Grundtypen dieser HardwareElemente. Terminals (Datenendplätze, Datenstationen) sind die Ein-/Ausgabegeräte, über welche die Außenwelt, in der Regel der menschliche Benutzer, mit dem Netz kommuniziert. Es gibt dialogfähige und nicht dialogfähige Terminals. Dialogfähige Terminals sind Fernschreibgeräte, Schreibmaschinen, Datensichtgeräte und graphische Terminals. Nicht dialogfähige Terminals sind Kartenleser, Schnelldrucker, Anzeigelampen, Ausweisleser und die übliche Prozeßperipherie wie Meßfühler und Steuereinrichtungen. Hosts (Wirtsrechner, Gastrechner, Verarbeitungsrechner, Teilnehmer-Rechner, Endrechner) sind Rechner (bzw. EDV-Installationen), die für das Netz Quellen

26

1. Grundbegriffe und Grundstrukturen Terminal-Subsystem(e)

Host-Subsystem(e)

Kommunikations-Subsystem Abb. 1.3-2 Logische Struktur eines Rechnerverbundnetzes

und Senken von Informationen sind. In ihnen entstehen Nachrichten, welche dem Netz zur Übermittlung an andere Hosts oder Terminals übergeben werden, und an sie gelangen über das Netz Nachrichten von anderen Hosts oder Terminals zur Verarbeitung. IMPs (Interface Message Processors, Knotenrechner, Kommunikationsprozessoren, Store and Forward Nodes, Vermittlungsrechner) sind Rechner, welche Nachrichten von Hosts zur Weiterleitung an eine bestimmte Zieladresse (anderer Host oder Terminal) übernehmen. Sie trennen diese Nachrichten ggf. in kleinere Einheiten (Pakete) auf und übermitteln sie dem Adressaten entweder unmittelbar oder unter Zwischenschaltung anderer IMPs.

1.3 Physische und logische Struktur von Rechnernetzen

27

TIPs (Terminal Interface Processors, Terminal-Knotenrechner) sind IMPs, welche nicht nur Hosts bedienen sondern auch den Nachrichtenverkehr mit Terminals abwickeln können. Die IMPs und TIPs bilden das „eigentliche" Datenübertragungsnetz, Hosts und Terminals zur Kommunikation benutzen.

welches

Im Rahmen des groben Strukturmodells von Abb. 1.3-1 sind Hosts, IMPs und TIPs nichts weiter als lokalisierte, adressierbare „Behälter" für bestimmte zur Verfügung stehende Betriebsmittel und ablaufende Aktivitäten (Prozesse). Über ihren Aufbau, Ausstattung, Größe u. ä. werden keinerlei Angaben gemacht. Nimmt man an, daß alle Hosts einerseits und alle IMPs und TIPs andererseits vom gleichen Rechnertyp sind und sich allenfalls unwesentlich in ihrem Arbeitsspeicherausbau, ihrer Zentraleinheit und der angeschlossenen Peripherie unterscheiden, so spricht man von einem homogenen Netz - ein Sonderfall, der in der Regel die Planung und Realisierung der Netzsoftware wesentlich erleichtert. Der technische Fortschritt oder steigende Anforderungen zwingen allerdings immer irgendwann zur Eingliederung neuer Hardwaremodelle und Datenübertragungsverfahren oder zum Anschluß an andere Netze, wodurch ein bestehendes Netz zwangsläufig inhomogen wird. Wird dies nicht bereits während der ersten Planung und Realisierung bedacht, so betragen die höheren Wartungs- und Weiterentwicklungskosten leicht ein vielfaches der durch die angenommene Homogenität des Netzes erreichten Einsparungen. In der logischen Struktur eines Rechnernetzes, die Abb. 1.3-2 darstellt, kann man auf oberster Ebene - Host-Subsysteme, - Terminal-Subsysteme, und -

Kommunikations-Subsysteme

unterscheiden. Ein Netz enthält im allgemeinen mehrere Subsysteme jeder Art, die jeweils identisch sein (z. B. gleiche Hosts mit identischer Software) oder sich voneinander unterscheiden können. Häufig gibt es nur ein einziges Kommunikations-Subsystem - das Datenübertragungsnetz mit seiner Software. Das zunehmende Kommunikationsbedürfnis in der Datenverarbeitung führt aber immer mehr dazu, daß Hosts und/oder Terminals in mehrere Netze eingegliedert werden, wodurch ein Gesamtnetz mit mehreren Kommunikations-Subsystemen entsteht. Ein Host-Subsystem enthält ein Netz-Kommunikationsprogramm, mit dessen Hilfe Verarbeitungsprozesse einen Nachrichtenverkehr über das Kommunikations-Subsystem abwickeln können. Diese Subsystem-Komponente wird in fast jedem Netz mit einem anderen Namen bezeichnet. Im ARPA-Netz heißt sie Network Control

28

1. Grundbegriffe und Grundstrukturen

Program (NCP), im CYCLADES-Netz Transportstation (TS), in der SNA Halfsession. Die Verarbeitungsprozesse können Benutzerprozesse, aber auch Dienstleistungsprozesse für Benutzerprozesse im gleichen oder einem fremden Host oder für einen Terminalbenutzer sein (z. B. ein Dateiverwaltungs-Prozeß). Sie können aber auch für den Benutzer „unsichtbar" irgendwelche für den Betrieb des HostRechners oder des Gesamtnetzes notwendige Funktionen ausüben, wie etwa die Systemabrechnung (Accounting); derartige Prozesse werden zuweilen Dämonen genannt. Ein Terminal-Subsystem enthält die Terminalprozesse selbst, welche ein bestimmtes Terminal und den auf ihm ggf. ablaufenden Dialog mit dem jeweiligen Anwender überwachen und betreuen, sowie die Terminalbedienung, welche entsprechend dem Netz-Kommunikationsprogramm eines Host-Subsystems den Nachrichtenverkehr mit dem Kommunikations-Subsystem wahrnimmt, und für die es ebenfalls noch keine einheitliche Bezeichnung gibt. Das Kommunikations-Subsystem schließlich besteht aus einzelnen NachrichtenVermittlungs-Systemen, die untereinander sowie mit den Netz-KommunikationsProgrammen und den Terminalbedienungen Nachrichten und Steuerinformationen austauschen. Die Zuordnung der einzelnen logischen Subsysteme von Abb. 1.3-2 auf die Hardwarekomponenten der physischen Systemstruktur ist im groben selbstverständlich. Bei detaillierterer Betrachtungsweise können jedoch Überlappungen auftreten, die Abb. 1.3-3 zeigt. Vor allem in die Aufgaben des Netz-Kommunikationsprologische Komponenten Terminal-Subsystem: Terminal-Prozesse Terminal-Bedienung

physikalische Komponenten

Terminal TIP

Kommunikations-Subsystem Nachrichten-Vermittlung

IMP

Host-Subsystem Netz-Kommunikationsprogramm

Host

Verarbeitungsprozesse

Abb. 1.3-3 Zuordnung der logischen zu den physischen Komponenten eines Netzes

29

1.3 Physische und logische Struktur von Rechnernetzen

gramms teilen sich in vielen Systemen Hosts und IMPs oder TIPs. Größere Hosts besitzen oft.auch einen eigenen Vorrechner zur Abwicklung der Netzkommunikationsaufgaben. Neuere Standards (z. B. X.25) unterscheiden nicht mehr zwischen Terminals und H o s t s u n d b e z e i c h n e n b e i d e s als Datenstation

(Data Terminal

Equipment,

DTE).

Dies ist vermutlich auch sinnvoll, da immer mehr Terminals durch eigene Mikroprozessoren und Arbeitsspeicher über soviel „Intelligenz" verfügen, daß die Trennungslinie zum „echten" Host immer unschärfer wird. Der weitgehenden Äquivalenz zwischen Verarbeitungs- und Terminalprozeß sollte sich der Programmierer in einer Netzumgebung immer bewußt sein - sie führt dazu, daß menschlicher Benutzer und Programm sich oft gegenseitig ersetzen können, ohne daß der Entwickler dessen gewahr wird. Zu welchen Problemen dies führen kann, belegen zwei Vorfälle aus der Geschichte des ARPA-Netzes [ANON8O]: Im Rahmen der automatischen Überwachungsroutinen wurde ein Programm eingeführt, welches sämtliche TIPs periodisch anwählen und ihr ordnungsgemäßes Arbeiten prüfen sollte. Da einige TIPs über normale Telefon-Wählleitungen angeschlossen und deshalb zuweilen nicht erreichbar waren, wiederholte die Prüfroutine bei Unzugänglichkeit oder falschem Antwortverhalten eines „entfernten" TIPs den Anruf in größeren Abständen und gab erst nach längerer Ausfallzeit eine Nachricht an die Netzadministration. Auch diese nahm derartige Meldungen nicht sehr ernst. Nach einigen Wochen kam ein Techniker schließlich auf die Idee, mit einem parallel geschalteten Telefon den Prüfanruf „mitzuhören". Die Routine wählte den TIP an, der Anruf wurde angenommen und das Prüfprogramm sandte seine Signale. Plötzlich hörte der Techniker die Antwort: „Martha, da ist schon wieder der verdammte Idiot, der uns anruft und dann nur pfeift!" Die Telefongesellschaft hatte die Nummern geändert und den alten Anschluß inzwischen neu vergeben. Ein andermal wurde für das automatische Nachrichtenvermittlungs-System des Netzes ein Dienst installiert, dem jeder Teilnehmer mitteilen konnte, wann er in Urlaub ging. Dieser Urlaubsvertretungs-Dienst sandte dann bei Empfang einer Nachricht dem Absender eine entsprechende Meldung zu. Die Einrichtung funktionierte problemlos, bis jemand eine letzte Mitteilung abschickte, dann in Urlaub ging - und der Adressat ebenfalls im Urlaub war. Dessen Auftragsdienst übermittelte seinerseits eine Urlaubsmeldung an den „Urlaubsvertreter" des ursprünglichen Absenders. Der sandte wiederum eine Urlaubsmeldung . . . Kurz vor Überlauf sämtlicher Platten konnten die beiden Urlaubsvertreter-Prozesse noch abgestoppt werden. In der neueren Normungsarbeit (vgl. z. B. [BURK81a]) werden die Datenstationen auch als Endsysteme bezeichnet. Diejenigen Rechnersysteme, welche das Kommunikationssubsystem bilden und ausschließlich Vermittlungsaufgaben wahrnehmen, heißen dort Transitsysteme.

30

1. Grundbegriffe und Grundstrukturen

M a n beachte jedoch, daß diese Bezeichnungen nicht eine Abstraktion des logischen Netzes sondern des physischen bezeichnen. End- und Transitsysteme sind nicht Prozesse oder Mengen von Prozessen - Instanzen (Entities) in der Normungsterminologie - sondern deren „ B e h ä l t e r " .

1.4 Benutzeranforderungen D a die Motive f ü r den A u f b a u eines Rechnernetzes letztlich immer physischer und technologischer Natur sind - die räumlichen Entfernungen zwischen den Rechnerinstallationen und Terminals sowie die zwischen ihnen vorhandenen oder zu schaffenden Übertragungsmedien - wird bei der Netzplanung das von der modernen Softwaretechnologie empfohlene Top Down-Vorgehen von den Benutzeranforderungen zur technischen Realisierung noch seltener befolgt als in anderen Bereichen der E D V . Die Bevorzugung der Bottom Up-Planung gerade bei Datennetzen wird meist so begründet, daß ihre wesentlichen Leistungsmerkmale wie Durchsatz, Antwortzeiten und Zuverlässigkeit, hauptsächlich von der Konstruktion des Kommunikations-Subsystems abhingen. Dessen G ü t e werde wieder maßgeblich durch seine physischen Bauelemente und die „niedrigen" Softwareschichten wie Unterbrechungsbehandlung, Warteschlangenführung, Pufferverwaltung und dergleichen bestimmt. Also müsse man mit ihrer optimalen Auslegung beginnen und sich dann im Netzentwurf zu den höheren E b e n e n der Software und schließlich zu den angebotenen Benutzerdienstleistungen hocharbeiten. Ein Beispiel aus d e m A R P A - N e t z [WOOD75] zeigt aber, daß eine nicht von den Benutzeranforderungen ausgehende Planung durch unzweckmäßige Auslegung der oberen Softwareebenen ebenso hohe Leistungseinbußen bringen kann wie Fehler in „ t i e f e n " Netzschichten: Im Gegensatz zum Dialogbetrieb sollte bei dem Dateitransfer, der Übertragung großer, zusammenhängender D a t e n m e n g e n zwischen Hosts, die Übertragungsrate von der Länge des Übertragungswegs (gemessen in Teilstrecken zwischen IMPs) zumindest in erster Näherung unabhängig sein. Die Zahl der zu überwindenden Teilstrecken ist ja nur zu Beginn und E n d e der Übertragung von Bedeutung; im eingeschwungenen Zustand kann sich ein kontinuierlicher Strom von D a t e n mit im Mittel gleichförmiger Geschwindigkeit über alle Teilstrecken zwischen Sender und E m p f ä n g e r bewegen. A b b . 1.4-1 zeigt jedoch, daß im A R P A - N e t z die Übertragungsrate mit steigender Zahl der Teilstrecken auch für den Dateitransfer drastisch abnimmt. D e r Grund ist, daß bei der Netzplanung offenbar der Benutzerwunsch nach Übertragung langer Datenströme schlicht vergessen wurde. Die Regelung des Nachrichtenaustauschs zwischen Host-Rechnern (das Host-Host-Protokoll) und nicht etwa das Kommunikations-Subsystem verlangt nämlich, daß zwischen Hosts je-

1.4 Benutzeranforderungen

31

Übertragungsrate

Zahl der Teilstrecken

Abb. 1.4-1 Durchschnittliche Übertragungsraten für den Dateitransfer im ARPA-Netz [nach WOOD75]

weils maximal eine etwa 8000 bit lange Nachricht unterwegs sein darf, und daß die nächste erst abgesendet werden kann, wenn der Empfänger die vorhergehende bestätigte. Damit begrenzt die Dialogverkehr-Antwortzeit von etwa 1 sec bei langen Übertragungswegen völlig unnötigerweise auch die Übertragungsraten beim Dateitransfer auf Werte in der Größenordnung von 8000 bit/sec. Wie für jedes EDV-System sollte deshalb auch der Entwurf eines Netzes mit der Definition eines Benutzermodells beginnen. Dies ist eine Studie, welche die folgenden Fragen beantwortet: - Wer sind die Benutzer des Netzes? - Welche Dienstleistungen wollen sie vom Netz erhalten? - Welche dieser Dienstleistungen sind bereits auf irgendwelchen Hosts des künftigen Netzes realisiert? - Welche Kompromisse und Einschränkungen (z. B. Wartezeiten, verminderten Funktionsumfang) kann der Netzbenutzer bei diesen bereits existierenden Dienstleistungen hinnehmen? - Welche Dienstleistungen werden erst im Rahmen der Netzentwicklung neu geschaffen?

32

1. Grundbegriffe und Grundstrukturen

- Kann man den Benutzern die als Folge des breiteren Dienstleistungsangebots entstehende große Vielfalt unterschiedlicher Bedienungsanweisungen zumuten (z. B. unterschiedliche Auftragssteuersprachen der einzelnen Host-Betriebssysteme oder voneinander abweichende Auskunfts- und Buchungssysteme verschiedener zusammengeschlossener Reiseunternehmen), oder muß eine vereinheitlichte Benutzerschnittstelle definiert und realisiert werden? - Wie wird der Benutzer von Ganz- oder Teilausfällen des Systems informiert, und wie sieht der Wiederanlauf und die Unterstützung des Benutzers bei der Diagnose und Behebung von Ausfällen und Fehlern aus? - Wie erlernen die Benutzer die Bedienung des Netzes, welche Dokumentation und Hilfen hierfür (z. B. Schulungsprogramme) sind erforderlich, und wie werden sie über wichtige Neuigkeiten des Netzbetriebs (z. B. neue Dienstleistungen) informiert? Soweit bekannt oder abschätzbar kommen hierzu noch Mengengerüste und Vorgaben: Angaben über die Menge und zeitliche Verteilung der einzugebenden, auszugebenden und zwischen den einzelnen Hosts zu übertragenden Informationen, die Menge und Organisation der in den einzelnen Hosts zu haltenden Datenbestände, maximale Antwort- und Wartezeiten, zulässige Fehlerraten und Ausfallzeiten und ähnliches. Neben der exakten Definition der Benutzerschnittstellen, wie Bedienungssprachen, Bildschirmdialog-Formate und Makroaufrufe für Netzdienstleistungen, läßt sich aus dem Benutzermodell ableiten, welche Grundtypen der Netzwerkbenutzung unterstützt werden müssen: - der interaktive Dialog, wobei sich wieder die Dialogprogrammierung von Timesharing-Systemen, die transaktionsorientierte Benutzung von Auskunfts-, Buchungs-, Datenerfassungs- und ähnlichen Systemen sowie der vom Rechnernetz lediglich vermittelte Dialog zwischen mehreren Benutzern an Terminals unterscheiden läßt, - die Fern-Stapelverarbeitung (Remote Job Entry, RJE), - die Kommunikation mit Kleinrechnern, wobei entweder der Kleinrechner die Benutzerschnittstelle der Netzdienstleistungen durch Prozeduranpassungen, Vor- und Nachbearbeitungen, Textaufbereitungen u. ä. verbessert, oder aber im Netz vorhandene Großrechner Aufgaben wie die Haltung großer Datenbestände oder Übersetzungen aus höheren Programmiersprachen übernehmen, welche die Leistungsfähigkeit oder Speicherkapazität der Kleinrechner übersteigen, - der Datenaustausch zwischen Rechnern, wobei der Austausch kurzer Nachrichten und die Übertragung großer Informationsmengen (der Dateitransfer) unterschieden werden müssen.

1.4 Benutzeranforderungen

33

Jede dieser Grundformen stellt andere Anforderungen an die Protokolle, die Regeln zur Abwicklung des Datenverkehrs auf jeder Ebene der Netzsoftware. Tabelle 1.4-2 zeigt die großen Unterschiede in den Kriterien und Leistungsanforderungen bei den wichtigsten Dienstleistungen eines Rechnernetzes. In einem größeren Netz müssen meist mehrere Betriebsweisen unterstützt werden. Ein Top Down-Verfahren bei der Netzentwicklung legt auf jeder Stufe einen für die Anforderungsprofile und relativen Häufigkeiten der einzelnen Betriebsweisen optimalen Kompromiß nahe. Ein Bottom Up-Entwurf hingegen überläßt dies weitgehend dem Zufall und führt damit leicht zu krassen Benachteiligungen einzelner Betriebsweisen, wie sie das oben erwähnte Beispiel aus dem ARPA-Netz zeigte. Tab. 1.4-2 Charakteristiken verschiedener Rechner-Anwendungen Eingabe

Datenv olumen Ausgabe

maximale Antwortzeit

Fehlererkennung/ -behebung

Interaktiver Dialog

gering (~ 100 bytes)

gering ( ~ 100 bytes)

kurz (~ 1 sec)

relativ unkritisch, (Korrektur durch Benutzer)

Datenerfassung

groß

gering (Meldungen)

sehr kurz ( ~ 0,1 sec)

kritisch (Datenintegrität!)

Datenübermittlung (Datei transfer)

groß

gering

lang (Minuten bis Stunden)

kritisch

Auskunft, Information

gering (~ 100 bytes)

mittel bis groß (Texte, Reports)

kurz bis mittel (sec- bis minBereich)

unterschiedlich kritisch

Fern-Stapelverarbeitung

gering bis mittel (wenn QuellProgramm oder Daten mitgegeben werden)

groß (Listen)

lang (Minuten bis Stunden)

relativ unkritisch (Wiederholungsmöglichkeit!)

Realzeit (ProzeßAnwendung)

gering (Signale, Meßdaten)

gering (Steuerdaten, Meldungen)

sehr kurz (msec- bis secBereich)

oft sehr kritisch

34

1. Grundbegriffe und Grundstrukturen

1.5 Realisierungsprobleme Bei den Kompromissen, die beim Entwurf sowohl des Gesamtnetzes als auch seiner Einzelkomponenten eingegangen werden müssen, befindet sich der Planer in einem Konflikt, den Abb. 1.5-1 darstellt. Die Forderungen nach - geringen Antwortzeiten (wichtig vor allem für interaktiven Dialog und Nachrichtenaustausch zwischen Rechnern), - hohem Durchsatz (besonders wichtig für die Fern-Stapelverarbeitung und den Dateitransfer), - geringen Kosten und - hoher Zuverlässigkeit widersprechen sich jeweils und verlangen ein gegenseitiges Abwägen der Planungsgesichtspunkte .

Abb. 1.5-1 Anforderungen und Kompromisse bei dem Entwurf eines Rechnernetzes

1.5 Realisierungsprobleme

©

35

Geringe Kosten und hohe Zuverlässigkeit sind immer schwer vereinbar. Je hochwertiger die Hardware und Software, umso teurer sind sie auch. Die Fehlerbehandlung verlangt einen beträchtlichen Softwareaufwand - bei einem größeren Realzeitsystem diente 70% des gesamten Programmcodes diesen Aufgaben [MART00]. Der zur Fehlererkennung nötige Zusatzaufwand und das Wiederholen falsch übertragener Nachrichten bringt eine höhere Belastung der Übertragungsleitungen. Und wird gar die Forderung einer weitgehend ungestörten Systemverfügbarkeit auch im Fehlerfall gestellt, so erfordert dies eine Verdoppelung vieler Hardwarekomponenten.

©

Geringe Antwortzeiten bei der Nachrichtenübermittlung und -bestätigung lassen sich durch Verringerung der Zahl der Teilstrecken zwischen Sender und Empfänger erreichen. Eine Leitungsführung, die jeden Knoten mit jedem anderen verbindet, erhöht jedoch die Zahl der Leitungen beträchtfich. Auch eine Verringerung der Wartezeiten in jedem IMP durch schnellere Hardware und Leitungen erhöht die Kosten.

© Eine Erhöhung des Durchsatzes erfordert schnellere oder mehrere gleichzeitig benutzte Leitungen sowie eine Minimierung der Übertragungsfehler und der durch sie verursachten Nachrichten Wiederholungen. Höhere Leitungsqualität bedeutet aber auch höhere Leitungsmieten. @ Hohe Zuverlässigkeit verlangt aufwendigere Fehlererkennungs- und Bestätigungsmechanismen, möglichst auf mehreren Ebenen der Netzhierarchie. Die hierfür nötigen Bearbeitungs- und Wartezeiten verzögern die Nachrichtenübermittlung. © Hohe Zuverlässigkeit erfordert aber auch ein Aufbewahren der gesendeten Informationen bis zur Bestätigung ihres korrekten Empfangs. Der hierfür in den einzelnen IMPs und Hosts längerfristig belegte Pufferplatz fehlt für andere zu übermittelnde Daten und begrenzt damit den gesamten zu erzielenden Durchsatz. © Schließlich stehen auch die Forderungen nach hohem Durchsatz und nach geringen Antwortzeiten miteinander in Konflikt. Eine Erhöhung des Durchsatzes läßt sich durch Vergrößerung der als Einheit zu übertragenden Datenblöcke erreichen, da so der Aufwand für die mitzusendende Steuerinformation sowie die für ihre Verarbeitung in den IMPs und Hosts benötigte Verwaltungsarbeit minimiert wird. Große Datenblöcke werden aber wiederum von kurzen Nachrichten schlecht ausgenutzt, und sie belegen IMPs und Leitungen relativ lange Zeit. Sie verlängern damit die Antwortzeiten für alle Nutz- und Steuerdaten. Diese Probleme und Konflikte werden dadurch verstärkt, daß bei der Planung jeder Datenfernverarbeitungsanwendung unterschiedliche, aber von einander abhängige Entwurfsziele erreicht werden müssen. Für jedes dieser Ziele gibt es an-

36

1. Grundbegriffe und Grundstrukturen

dere technische Mittel, welche der Planer beherrschen, entsprechend den in Abb. 1.5-1 gezeigten Kriterien bewerten, aufeinander abstimmen und optimal realisieren muß. Tabelle 1.5-2 stellt die wichtigsten dieser Ziele und Mittel zusammen - als ersten Überblick über die Gebiete, welche im folgenden ausführlich diskutiert werden müssen. Die folgenden Kapitel sollen den Planer auf seinem Weg von den Benutzerschnittstellen zum physischen Netz begleiten und einige der Denkansätze und Methoden zeigen, welche ihm zur Überwindung der Probleme zur Verfügung stehen.

Tab. 1.5-2 Ziele und Mittel bei der Planung von Datenfernverarbeitungs-Anwendungen (nach [GREE 79]) ZIEL

MITTEL

Herstellung eines Übermittlungswegs.

Öffentliche (lokal auch private) Leitungen.

Übertragung von Bits (statt Analogsignalen).

Modems.

Übertragung vollständiger Nachrichten.

Leitungsprotokolle (BSC, HDLC).

Anpassung an verfügbare Betriebsmittel und Übertragungsraten.

Pufferung, Flußsteuerung.

Anpassung an Puffergrößen, Vermeidung der Wiederholung langer verlorener Nachrichten.

Pakete (Fragmentierung und Reassemblierung).

Ökonomie der zeitweiligen Nutzung.

Wahl, Multidrop, Multiplex, Paketund/oder Leitungsvermittlung.

Übermittlung an gewünschten Knoten oder Prozeß, Umwege bei Ausfällen.

Adressierung, Laufwegermittlung (Routing).

Anpassung an Kommunikationswünsche des Benutzers.

Datagramm- oder Verbindungsmanagement.

Anpassung an Benutzerformate, -codes und -spräche.

Höhere Protokolle.

2. Die Benutzerschnittstellen

2.1 Die nichtlokalisierte Maschine Benutzer eines Rechnernetzes können entsprechend ihrem Zugriff auf seine Dienstleistungen in zwei Gruppen eingeteilt werden: - Terminal-Benutzer, welche unmittelbar über das Kommunikations-Subsystem oder durch Vermittlung ihres lokalen Hosts mit Verarbeitungsprogrammen (Prozessen) in entfernten Hosts kommunizieren, und - Anwendungsprogrammierer, welche Programme für einen der Hosts schreiben und dafür Zugriffe auf Daten oder sonstige Betriebsmittel anderer Hosts benötigen. Der Terminal-Benutzer sieht das Netz wie in Abb. 2.1-1 dargestellt. Die Terminals übernehmen den „lokalen Vertrieb" von EDV-Dienstleistungen, die irgendwo anders in Hosts erzeugt werden. Das eigentliche Netz, das Kommunikations-Subsystem, wird - ähnlich wie der Großhandel im Warenverkehr - bestenfalls als notwendiges Übel zur überregionalen Verteilung empfunden; eine Veränderung der gelieferten „Ware" und eine Verzögerung der Belieferung sollte möglichst unterbleiben. Ein konkretes Beispiel für ein diesem Benutzerbild genau entsprechendes Rechnernetz zeigt Abb. 2.1-2: das START-Netz, welches von Siemens für die deutschen Reisebüros und mehrere große Anbieter im Touristikgewerbe entwickelt wurde. Es ermöglicht dem Reisebüro-Angestellten, über „Reisebüroterminals" die Auskunfts- und Buchungsdienste der Deutschen Bundesbahn, der Lufthansa und großer Reiseveranstalter sowie spezifische START-Dienstleistungen im Dialog abzurufen, ohne sich darum kümmern zu müssen, in welchen Systemen die jeweils benötigten Dienste realisiert sind. Auch für den Anwendungsprogrammierer ist es im Grunde uninteressant, ob von ihm benötigte Dienstleistungsfunktionen oder Datenzugriffe von einem lokalen oder einem räumlich entfernten Rechner erbracht werden. Für beide Anwendergruppen ist also die Basissoftware eines Rechnernetzes - von Sonderfällen wie ausgesprochenen Kommunikationsnetzen einmal abgesehen nichts anderes als das Betriebssystem einer nichtlokalisierten Maschine. Die Unterschiede und die gegenseitigen Entfernungen der Einzelinstallationen sind für die Benutzer nur ein technisches Detail. Die Software soll sie dagegen ebenso

38

2. Die Benutzerschnittstellen

Terminals verschiedener Art

CD

CD

Kommunikations-Subsystem

lokaler Vertrieb

überregionale Verteilung

Herstellung

Hosts von EDV-Dienstleitungen A b b . 2 . 1 - 1 Das Rechnernetz aus der Sicht des Terminal-Benutzers

abschirmen wie etwa gegenüber Zahl, Anordnung und Typ der Plattengeräte in ihrem gewohnten, lokalisierten Rechenzentrum. Dieses Ideal ist in der Praxis kaum zu erreichen. Einige Ansätze zu seiner Verwirklichung und die auftretenden Probleme sollen im folgenden besprochen werden. Wie bei üblichen Betriebssystemen müssen hierbei entsprechend den oben genannten beiden Benutzergruppen zwei Benutzerschnittstellen unterschieden werden: - die Bedienung über ein Dialogterminal und - die Betriebssystem-Auf rufe (Supervisor Calls, Makros), die der Anwendungsprogrammierer zur Anforderung von Dienstleistungen benutzt.

2.2 Bedienungssprache und Terminals

39

Abb. 2.1-2 START-Netz (schematisch) DB LH TUI START

: : : :

Deutsche Bundesbahn Lufthansa Touristik Union International START-Hauptrechner

LTVR NVR

: Leistungsträger-Vorrechner : Netz-Vorrechner

NKR

: Netz-Knotenrechner

RBT

: Reisebüro-Terminals

Hosts" " i j

JMp

" „TIPs" (intelligent)

2.2 Bedienungssprache und Terminals Die Benutzer am Dialogterminal unterscheiden sich ihrerseits wieder in den gewünschten Dienstleistungen: - sie sind entweder Programmierer, die über das Dialogterminal im wesentlichen das gleiche Time-Sharing System oder die normale Stapelverarbeitung (Remote Job Entry, RJE) verwenden wollen, die sie auch bei lokalen Rechnern benutzen würden, - oder sie sind Sachbearbeiter oder Manager wie Schalterbeamte, Bodenstewardessen, Kaufleute, Planer, die über ihr Terminal den Verarbeitungsprogrammen Daten übermitteln oder Informationen von ihnen abrufen. Die erste Benutzergruppe wird in der Regel einen bestimmten Host oder einen bestimmten Betriebssystem-Typ - z. B. ein TENEX-System einer beliebigen

40

2. Die Benutzerschnittstellen

PDP10 im ARPA-Netz - anwählen. Hierfür muß die Dialog- oder Stapelverarbeitungs-Schnittstelle des angewählten Systems über das Kommunikations-Subsystem auf das Terminal verlagert werden. Schwierigkeiten treten dann auf, wenn die unterschiedlichen Steuersprachen verschiedener beteiligter Systeme durch eine einheitliche, netzweite Netz-Job Control Language (NJCL) [RAYM74] ersetzt werden sollen. Wichtiger für anwendungsorientierte Verbundsysteme und damit für die überwiegende Mehrzahl der öffentlichen und privaten Rechnernetze ist die zweite Gruppe der Terminalbenutzer. Ein häufiges praktisches Problem sind deshalb die Unterschiede zwischen den verschiedenen Terminals, die in einem größeren, inhomogenen Netz von den Verarbeitungsprogrammen bedient werden müssen - sie reichen vom einfachen Fernschreiber bis zum intelligenten Video-Terminal mit HardcopyEinrichtung, eigenem Speicher, verschiedenen Schrifttypen, freier Cursorbewegung über Tasten oder Steuerhebel („Joystick") und zahlreichen Funktionstasten. Diese Vielfalt wird noch dadurch erhöht, daß gleiche oder ähnliche Funktionen bei Terminals verschiedener Hersteller in ihrer Schnittstelle zur Hardware oft ganz unterschiedlich realisiert sind, und daß andererseits die Terminalbedienung durch die Hersteller-Betriebssysteme oder Task-Monitore freier Software-Produzenten ebenfalls keineswegs standardisiert ist. Eine ungefähre Vorstellung von dem Aufwand und den Kosten, welche diese Terminalvielfalt bei einer Netzentwicklung verursacht, vermittelt die Tatsache, daß von den 28k Arbeitsspeicher-Worten eines ARPA-TIPs die Software und Tabellen zur Codewandlung für nicht-ASCII-Terminals allein lk Worte benötigen [PYKE73], Um Anwendungsprogramme und Netzsoftware einigermaßen unabhängig von den physischen Eigenschaften des jeweils eingesetzten lokalen Terminals entwikkeln zu können, wird innerhalb eines Netzes meist ein Standard definiert, der als virtuelles („scheinbares") Terminal bezeichnet wird [BARB77, DÜNK77]. Eine der wichtigsten Aufgaben des in Abb. 1.3-2 gezeigten Terminal-Subsystems ist dann die softwaretechnische Abbildung der Eigenschaften eines realen Terminals auf die des vereinbarten, virtuellen. Abb. 2.2-1 zeigt die hierfür nötigen Komponenten eines Terminal-Subsystems [WOOD75a], die am besten jeweils über Kontrollblöcke parametrisiert und gesteuert werden: - die terminalseitige Leitungssteuerung bedient die verschiedenen (realen) Leitungsarten zum Anschluß der Terminals und puffert die ein- und auszugebenden Zeichen oder Zeilen, - die Terminal-Steuerung verwaltet die verschiedenen realen Terminals, - die virtuelle Terminal-Simulation übersetzt die physischen Eigenschaften der realen Terminals in die des virtuellen Standards,

2.2 Bedienungssprache und Terminals multidrop

abgesetzt

(reale) Terminals

Abb. 2.2-1 Terminal-Subsystem

42

2. Die Benutzerschnittstellen

- das Verbindungsmanagement kümmert sich um Auf- und Abbau der Verbindungen (Sign On und Sign Off) sowie die in die zu übertragenden Daten einzuschiebende Steuerinformation, - die netzseitige Leitungssteuerung übernimmt die Pufferung, Wegwahl und Ein/Ausgabe der zu übertragenden Nachrichten. Wie Abb. 2.2-2 zeigt, können je nach der „Intelligenz" der benutzten konkreten Terminals diese Funktionen teilweise auch in ihnen durch Software oder Mikroprogramme realisiert werden - in diesen Fällen simuliert das Terminal selbst den virtuellen Netz-Standard.

Abb. 2.2-2 Das virtuelle Terminal GS: Geräte-Steuerung (Terminal- und Leitungssteuerung) VT: Virtuelles Terminal (Simulation) VM/LS: Verbindungs-Management und Leitungssteuerung

Diese Simulation verlangt in der Regel eine Abstraktion der realen Terminalfunktionen. Einige von ihnen kann das virtuelle Terminal vielleicht überhaupt nicht erbringen - dies gilt etwa für die freie Bewegung des Cursors, wenn auch Fernschreiber verwendet werden sollen. Andere Eigenschaften müssen je nach eingesetztem Terminal sehr unterschiedlich abgebildet werden - so ist die virtuelle

2.2 Bedienungssprache und Terminals

43

Funktion des Hervorhebens von Zeichen oder Texten (Contrasting) eine Abstraktion so unterschiedlicher konkreter Darstellungsmittel wie Unterstreichen, Rotdruck, Blinken, Negativschrift oder höhere Leuchtintensität. Eine zu starke Einschränkung der Möglichkeiten des virtuellen Terminals durch die Forderung nach Realisierung auch auf einfachsten Fernschreibern wird meist dadurch umgangen, daß bestimmte Eigenschaften, wie etwa die freie Beweglichkeit des Cursors oder die maximale Zeilenlänge, als freie Parameter angesehen werden. Sie können bei Verbindungsaufnahme zwischen den Verarbeitungsprogrammen und der Terminalbedienung „ausgehandelt" werden. Für den praktischen Einsatz dieses Konzepts ist es jedoch wichtig, daß die Zahl der auszuhandelnden Parameter möglichst klein gehalten wird. Andernfalls wird das eigentliche Ziel der Virtualisierung - die Unabhängigkeit vom realen Terminal und seinen Eigenschaften - hintertrieben (vgl. [SCHI78]). Ein sehr anpassungsfähiges Konzept für die Anordnung verschiedener Informationen auf einem konkreten Bildschirm oder auch als sequentielle Fernschreiberausgabe ist die Aufteilung des virtuellen Bildschirms in Zonen [BARB77a, LUCA75], Je nach dem Format und den sonstigen Eigenschaften des benutzten Terminals werden diese Zonen - auf dem realen Bildschirm verteilt, - als getrennte Bildschirminhalte gezeigt, - sequentiell jeweils mit einer Identifikation der Zone ausgedruckt - oder auch völlig unterdrückt. Die einfachste Realisierung einer virtuellen Terminal-Schnittstelle, wie sie etwa im CYCLADES-Netz eingesetzt wird, sind Nachrichten variabler Länge zwischen Terminalsimulation und Anwenderprogramm [SCHI76, SCHI77, SCHI78]. Das erste Byte ist hierbei ein Code, welcher entweder - eine Operation wie etwa Zeilenvorschub, Wagenrücklauf oder Cursorbewegung angibt oder - die folgenden Bytes als sequentiell eingegebenen oder auszugebenden Text identifiziert. Die folgenden Bytes enthalten, wenn vorhanden, - einen Operanden für die Operation, z. B. die neue Position des Cursors oder - den Text selbst. Diese Nachrichten können dann als „Befehle" für die Ausgabe auf das reale Terminal oder für die Ablage eingegebener Texte in die Puffer des Verarbeitungsprogramms interpretiert werden.

2. Die Benutzerschnittstellen

44

Dieses einfache Grundkonzept darf jedoch nicht über die großen praktischen Realisierungsschwierigkeiten hinwegtäuschen. Sie sind in den sehr uneinheitlichen physischen Eigenschaften der meisten Datenendgeräte begründet. Beispiele für die Vielfalt derartiger Probleme bei einem typischen, konkreten Gerät sind [BART73]: - Ein als Abschluß der übertragenen Daten gesendetes ETX-Zeichen ist auf dem Terminal sichtbar und löscht den Rest des Bildschirms, so daß eine freie Änderung in Formularen nicht möglich ist (Problem für den Anwendungsprogrammierer). - Der Benutzer kann Bildschirmteile löschen, ohne daß die Informationen auch gleichzeitig aus dem terminalinternen Gerätepuffer entfernt werden. Eine anschließende Übertragung zum Rechner sendet Daten mit, von deren Existenz der Benutzer nichts ahnt (Problem für den Terminalbenutzer). - Als Positionierungssymbol (Cursor) und als Textanfangszeichen für die Übertragung (STX) wird das gleiche Zeichen verwendet. Damit vernichtet jede Datenübertragung den aktuellen Cursorstand, weil sie hinter den zuletzt übertragenen Text positioniert (Problem für den Anwendungsprogrammierer und den Benutzer). In diesen und vielen anderen Fällen (z. B. keine Klein-/Großschreibung auf einfacheren Terminals) ist es außerordentlich schwer, die Definition des virtuellen Terminals vom (kumulierten!) Einfluß aller Besonderheiten der zu unterstützenden Geräte frei zu halten, ohne die Möglichkeiten für den Benutzer auf ein nicht mehr vertretbares Minimum - etwa eine fernschreiberartige Zeilenschnittstelle auch für komfortable Bildschirmgeräte - zu reduzieren.

2.3 Die verteilte Datenbasis Ebenso wie bei einem lokalisierten System sind für den Anwendungsprogrammierer auch in einer Netz-Umgebung neben der Ein-/Ausgabe zu Terminals die Zugriffe zu Datenbeständen die häufigsten Systemaufrufe. Dabei kann es sich um Dateien in einem File-System oder um eine Datenbank handeln, oder aber auch um Ein-/Ausgabegeräte wie Kartenleser und Drucker, die in üblichen Betriebssystemen wie Dateien angesprochen werden und in der Regel auch über ein SPOOLSystem als solche realisiert sind [SCHN75]. D i e R e a l i s i e r u n g u n d B e h a n d l u n g verteilter

Datenbasen

(Distributed

Data

Bases)

ist deshalb eines der wichtigsten Untergebiete sowohl der theoretischen als auch der praktischen Beschäftigung mit Rechnernetzen [BOOT76, CHAM77, CHAN76, INF077, LEVI74, LOWE76, MORG76]. Auch vom wirtschaftlichen Standpunkt aus ist dies meist eines der stärksten Argumente für den Aufbau von Rechnernetzen. Fry und Sibley [FRYJ76] berichten, daß ein größeres Unterneh-

2.3 Die verteilte Datenbasis

45

men durch den Verbund seiner Teil-Datenbasen in die Lage versetzt wurde, jeden Freitag eine exakte Bilanz seiner laufenden Guthaben und Kassenbestände aufzustellen und die Mittel über das Wochenende als kurzfristige Darlehen auszuleihen. Überraschenderweise deckten allein die Zinsen hieraus die gesamten Kosten des Datennetzes. Das Bedürfnis, eine verteilte Datenbasis zu realisieren, d. h. entweder einen früher zentral gehaltenen Datenbestand nunmehr auf verschiedene Hosts zu verteilen, oder die Datenbestände mehrerer Host logisch zusammenzufassen, entsteht in der Regel in einer der folgenden Situationen [CHAM77]: (1) Lokal werden große Datenmengen erzeugt, die schnell abgefragt und geändert werden müssen. Die meisten dieser Anforderungen fallen lokal an, jedoch wird zuweilen zu den Datenbeständen auch von entfernten Stellen zugegriffen. Ein Beispiel ist das internationale Buchungssystem der Fluggesellschaften (SITA-Netz). (2) Lokal fallen große Datenbestände an. Einige dieser Daten sowie Ergebnisse ihrer lokalen Verarbeitung (Summen, Mittelwerte o. ä.) werden in einer Zentrale zur Weiterverarbeitung benötigt. Ein Beispiel hierfür ist die Filialkette eines Handelsunternehmens, welches täglich die Kassen- und Lagerbestände in die Zentralverwaltung übermittelt haben will. (3) Zentral fallen große Datenmengen an. Lokal werden ein rascher Zugriff auf Teile dieser Daten sowie ihre Verarbeitung und Korrelation mit lokalen Daten gebraucht. Ein Beispiel ist die Produktionssteuerung eines Industriebetriebes, wenn Aufträge der Zentrale in räumlich verteilten Produktionsstätten als Grundlage zur Stücklisten- und Fertigungsplanerstellung sowie zur Lager- und Vorratshaltung dienen. Welche dieser drei Situationen bei den geplanten Anwendungen vorliegt, ist Ausgangspunkt für die Spezifikation und Planung einer verteilten Datenbasis. Hiervon hängt nämlich ab, welcher der beiden möglichen Grundtypen sinnvoll ist: - Bei der aufgeteilten Datenhaltung (Partitioned Data Base) ist der Gesamtdatenbestand, wie Abb. 2.3-1 zeigt, auf die lokalen Datenbasen der einzelnen Hosts verteilt; ein bestimmtes Datum ist immer nur auf einem der Hosts zu finden. Dies ist die Standard-Konfiguration für die erste der obigen Anwendungs-Situationen. - bei der mehrfachen Datenhaltung (Replicated Data Base) enthalten entsprechend Abbildung 2.3-2 die lokalen Datenbasen der einzelnen Hosts Unter- oder Übermengen der Datenbasen anderer; ein bestimmtes Datum ist deshalb unter Umständen auf mehreren der Hosts gespeichert. Die obigen Anwendungsfälle (2) und (3) sind von dieser Art. Da in der Regel eine verteilte Datenbasis nicht nur einer einzigen Anwendung dienen soll, überlappen sich oft die verschiedenen Ausgangssituationen. Es ist

46

2. Die Benutzerschnittstellen

(logische) GesamtDatenbasis

lokale Datenbasen

Hosts

Abb. 2.3-1 Aufgeteilte Datenhaltung (Partitioned Database)

dann die Aufgabe des Systemplaners, die optimale Verteilung der Datenbestände als Mischform der beiden Grundtypen zu ermitteln. Diese Datenanalyse ist dann eine der Grundlagen für die logische Planung des Gesamtnetzes - ähnlich wie die Struktur der zu verarbeitenden Daten einer der besten Ausgangspunkte für die Entwicklung eines üblichen Anwendungsprogramms ist [JACK75]. Tabelle 2.3-3 stellt den Einfluß der wichtigsten Parameter auf die Wahl der optimalen Verteilungsstrategie zusammen. Es sind dies - die Größe des Datenbestands, - die Änderungshäufigkeit (die als groß anzusehen ist, wenn mehr als etwa 10% der Transaktionen eine Änderung verlangen) und - die bei Aufteilung zu erwartende Fehlrate, d. h. der Anteil der Zugriffswünsche, welche nicht mit dem lokalen Datenbestand befriedigt werden können (hier dürfte etwa 30% die Grenze zwischen „klein" und „groß" markieren). Bei der Anwendung dieser Tabelle ist zu beachten, daß die Kriterien für den Datenbestand und seine Verwaltungsinformationen wie Verzeichnisse (Directories), Indextabellen u. ä. getrennt untersucht werden sollten. Es ist durchaus mög-

47

2.3 Die verteilte Datenbasis

(logische) GesamtDatenbasis

lokale Datenbasis

Hosts

Abb. 2.3-2 Mehrfache Datenhaltung (Replicated Database) lieh, daß für die D a t e n selbst eine andere Organisation sinnvoll ist als für ihre Verwaltung. Selbstverständlich spielen bei der Festlegung der Verteilung n o c h zahlreiche andere G e s i c h t s p u n k t e w i e die verfügbare Hardware und Basissoftware o d e r die Sicherheit u n d Integrität d e s D a t e n b e s t a n d e s e i n e o f t e n t s c h e i d e n d e R o l l e , für die k a u m allgemeingültige B e w e r t u n g s m a ß s t ä b e a n g e g e b e n w e r d e n k ö n n e n .

Tab. 2.3-3 Einflußparameter auf die Wahl der Datenhaltung Datenbestand

ÄnderungsHäufigkeit

erwartete Fehlrate bei Aufteilung

vermutlich günstigste Organisation

klein klein klein klein groß groß groß groß

klein klein groß groß klein klein groß groß

klein groß klein groß klein groß klein groß

mehrfach mehrfach aufgeteilt zentralisiert aufgeteilt aufgeteilt aufgeteilt zentralisiert

48 Als Beispiel [INF077],

2. Die Benutzerschnittstellen

zeigt

Abb. 2.3-4

das Netz einer

französischen

Großbank

Das Netz ist dreistufig: - die oberste Ebene sind zwei gekoppelte Großrechner in Paris und Aix, - die nächste Ebene sind 200 lokale Rechner mit eigener Datenhaltung und - als unterste Ebene dienen Konzentratoren in 2000 Filialen, die jeweils bis zu 5 Videoterminals und einen Drucker bedienen. Auf der obersten Ebene ist die vollständige Kunden-Datenbasis aufgeteilt, wobei in Paris 70% und in Aix 30% der Konten gehalten werden. Zwischen den zentralen und den lokalen Rechnern ist eine mehrfache Datenhaltung eingerichtet. Die lokalen Rechner erhalten am Anfang des Tages die aktuellen Kontenstände der von ihren Filialen betreuten Kunden übermittelt. Während des Tages werden von ihnen die aktuellen Transaktionen abgewickelt und nachts die neuen Kontenstände an den zentralen Rechner zurückgesendet. In den relativ seltenen Fällen, daß Kunden in fremden Filialen Abhebungen vornehmen wollen, müssen die beteiligten lokalen Rechner über das Gesamtnetz korrespondieren. In der Regel kann jedoch der lokale Rechner alle Realzeit-Aufgaben selbständig abwickeln, während die zentralen Rechner lediglich Stapelverarbeitungsaufgaben wie monatliche Kontoabrechnungen übernehmen. Einen Sonderfall der verteilten Datenbasis stellt der zentrale DatenverwaltungsÄechner dar [CANA74, MARI75]. Er dient, wie Abb. 2.3-5 zeigt, als allgemein zugängliches Netzbetriebsmittel zur Haltung einer zentralen Datenbank, auf welche alle Verarbeitungsprozesse und alle Terminals im Netz mit Hilfe einer eigenen Datenbank-Sprache zugreifen. Dadurch können teuere Massenspeicher-Systeme wie der IBM 3850-Großspeicher oder der AMPEX-TERABIT-Speicher ökonomisch genutzt und über ein einheitliches, ihnen angepaßtes Datenbank-System verwaltet werden, wobei allerdings relativ hohe Zugriffszeiten in Kauf genommen werden müssen.

2.4 Zugriffsverfahren Nachdem die Aufteilung der Datenbestände in eine über das Netz verteilte Datenbasis festgelegt ist, muß der Zugriff der Anwendungsprogramme auf diese Daten geplant werden. Dies ist zwar primär die Aufgabe der Anwendungsprogrammierer, die Netz-Software muß ihnen jedoch Primitivfunktionen dazu bereitstellen. Je mehr sie dabei die physische Speicherung und ihre Lokalisierung vor den Benutzern verbirgt, umso besser wird diesen das „Netz-Betriebssystem" erscheinen; allerdings bedarf es dazu eines beträchtlichen Aufwands. Ein Beispiel für ein derartiges System ist das RSEXEC des ARPA-Netzes [THOM75],

2.3 Die verteilte Datenbasis

49

M •O C < «u Q

m M

B cd

X)

ca o Ui Ü

a u Z

X)

•O
0 beschreibt einen synchronen Automaten, welcher die Annahme der Eingaben und seine Zustandsübergänge entsprechend seiner eigenen Taktfrequenz steuert. Informationsverarbeitende und -speichernde Elemente von Rechnernetzen - sowohl die Zentraleinheiten als auch Arbeits- und Externspeicher - sind in der Regel synchrone Automaten. Arbeiten mehrere von ihnen zusammen, wie dies in Netzwerkmaschinen der Fall ist, so müssen sie sich synchronisieren, das heißt sowohl der Zeittakt p als auch der absolute Referenzzeitpunkt t0 müssen hinreichend gut übereinstimmen. Die Synchronisation und Resynchronisation der Netzwerkmaschinen auf jeder Ebene ist eines der schwierigsten technischen Probleme bei der Realisierung von Datenübertragungsanwendungen und Rechnernetzen. Zu jedem Zeitpunkt ist der vollständige Zustand der Netzwerkmaschine die Menge der aktuellen Zustände jeder einzelnen Verbindung, und die Zahl der insgesamt möglichen Zustände der Netzwerkmaschine ist das cartesische Produkt der Zustände der Einzelverbindungen. Diese Zustandsmenge ist zwar groß aber endlich: auch die gesamte Netzwerkmaschine ist ein endlicher Automat. Unter den obigen, idealisierenden Annahmen wären die einzelnen Verbindungen und damit deren Zustandsdiagramme unabhängig voneinander. Dies hätte zur Folge, daß das Zustandsdiagramm der gesamten Netzwerkmaschine durch die unabhängigen Zustandsdiagramme der Einzelverbindungen dargestellt werden könnte. In der Praxis ist diese Unabhängigkeit jedoch nicht gegeben. Das Zustandsdiagramm der Netzwerkmaschine wird dadurch so komplex, daß eine Planung selbst eines kleinen Netzes als endlicher Automat nie möglich ist. Das Modell kann deshalb nur als konzeptuelles Hilfsmittel zur Darstellung struktureller Eigenschaften von Netzen dienen.

81

4.3 Untersysteme und ihre Zustände

Diese Einschränkung ist natürlich keine Besonderheit von Datenübertragungsnetzen. Sie gilt genauso für eine übliche lokale EDV-Installation. Auch deren Zustände und die möglichen Übergänge zwischen ihnen können nie tatsächlich aufgelistet werden. Sowohl die Analyse als auch die Synthese von DV-Systemen besteht deshalb immer in der Abstraktion kleiner Untersysteme, die weitgehend unabhängig voneinander sind und deshalb losgelöst von gleichzeitig ablaufenden anderen Untersystemen untersucht und realisiert werden können.

4.3 Untersysteme und ihre Zustände Für die Analyse und den Entwurf eines Netzes auf der logischen Ebene der Netzwerkmaschinen sind die naheliegenden Untersysteme Paare von Prozessen, dem Sender und dem Empfänger, welche mittels einer Netzwerkmaschine über Ports miteinander kommunizieren. Jeder der Prozesse verfügt über einen Eingabe- und einen Ausgabeport. Der Sender gibt die zu sendenden Nachrichten mittels seines Ausgabeports in die Netzwerkmaschine und erwartet die zugehörigen Quittungen (ACK) auf seinem Eingabeport. Der Empfänger nimmt Nachrichten von seinem Eingabeport entgegen und gibt Quittungen über seinen Ausgabeport in die Netzwerkmaschine zurück. Vernachlässigt man Verbindungsaufbau und -abbau, so sollten für die beiden Prozesse die in Abb. 4.3-1 gezeigten Zustandsdiagramme gelten: Der Sender befindet sich anfänglich in einem Zustand 1 (Nachrichtenaufbereitung), sendet seine Nachricht aus, kommt dadurch in den Zustand 2 (Quittungserwartung) und wird durch den Empfang der Quittung (ACK) in den Zustand 1 zurückversetzt.

örA H Sender

ö Empfanger \

rA

ACK

senden

ACK

\

/

\

empfangen

)

rri

Abb. 4.3-1 Zustände zweier über eine Netzwerkmaschine kommunizierender Prozesse (idealisiert)

82

4. Netzwerkmaschinen und Netzzustände

Auch der Empfänger befindet sich anfänglich in einem Zustand 1 (Empfangsbereitschaft), wird durch den Empfang der Nachricht in den Zustand 2 (Quittieren) überführt, und geht nach Aussenden der Quittung wieder in 1 über. Was geschieht jedoch, wenn die zwischen Sender und Empfänger liegende Netzwerkmaschine unzuverlässig arbeitet und entweder die Nachricht oder die Quittung nicht korrekt überträgt? In diesem Fall verharrt der Sender im Zustand 2 und der Empfänger befindet sich entweder noch oder bereits wieder im Zustand 1. Damit der Sender überhaupt wieder aus der Quittungserwartung befreit wird, muß im Zustand 2 eine Zeitüberwachung (Time Out) eingeführt werden: nach festgeEmpfanget

Sender

ACK

ACK

senden

Time O u t /

empfangen

senden wiederholen

Wiederholungszähler > n (Verbindung gestört)

Seiteneffekte senden:

Nachricht speichern;

empfangen:

if

Nachricht nicht früher bereits empfangen

Time O u t : Wiederholungszähler : = Wiederholungszähler +1;

t h e n bearbeiten

ACK:

eise nicht beachten;

Nachricht löschen, Wiederholungszähler :=0;

A b b . 4.3-2 Zustandsdiagramme einer einfachen Nachrichtenübertragung mit Zeitüberwachung durch den Sender

4.3 Untersysteme und ihre Zustände

83

legten Wartezeiten (z. B. 100 ms) wird die Nachricht n mal wiederholt. Bei Ausbleiben aller Quittungen wird die Verbindung als gestört angenommen und der Sender-Prozeß trifft eine geeignete Maßnahme, wie etwa Meldung an einen Systembediener und Abbruch. Abb. 4.3-2 zeigt die erweiterten Zustandsdiagramme zusammen mit den nötigen Seiteneffekten während der Übergabe zwischen den Prozeßzuständen - so muß der Empfänger bei Empfang einer Nachricht prüfen, ob

Abb. 4.3-3 Restunsicherheit nach mehrmaliger Quittierung einer Nachricht

84

4. Netzwerkmaschinen und Netzzustände

er bereits eine frühere Kopie der gleichen Nachricht besitzt, da er nicht weiß, in welchem Zustand der Sender gerade ist. Er kann deshalb bei längerem Verweilen im Zustand 1 auch nicht wissen, ob der Sender zur Zeit keine Nachrichten zu übermitteln hat (Zustand 1), oder ob er gerade Nachrichten wiederholt (Zustand 4) und nur die Netzwerkmaschine gestört ist - ob er also warten oder auch seinerseits einen Fehlerzustand annehmen soll. Diese gegenseitige Unsicherheit über den jeweiligen Zustand zweier Partner ist unvermeidlich, wenn der einzige Kommunikationsweg zwischen ihnen ein unter Umständen gestörter Kanal ist. Daß sie sich auch durch beliebig viele gegenseitige Quittungen nie voll beseitigen läßt, zeigt Abb. 4.3-3 an einem Beispiel: Zwei Bankräubergruppen sind darauf angewiesen, daß Gruppe B exakt zu dem Zeitpunkt in den Tresor eindringt, zu dem Gruppe A die Alarmanlage stillegt. Führt eine der Gruppen ihre Teilaufgabe nicht aus, so darf auch die andere nichts unternehmen. Der einzige Kommunikationsweg zwischen ihnen seien unzuverlässige Boten. Auch eine mehrfache gegenseitige Bestätigung kann aber nicht beiden Partnern gleichzeitig volle Sicherheit über den Zustand des anderen geben - der Leser ist eingeladen, sich hiervon durch Ergänzung von Abb. 4.3-3 durch einige weitere Quittungsübermittlungen zu überzeugen. Das Dilemma der Bankräuber - und das entsprechende Dilemma eines gewissenhaften Protokollentwerfers - ist übrigens ein allgemeines und grundlegendes Problem: kein nicht ganz triviales System kann seine eigene Korrektheit vollständig absichern. 1931 mußten sich sogar die Mathematiker davon überzeugen lassen [GÖDE31]. Und eines der besten Bücher hierüber ([HOFS79], S. 192) bringt denn auch einen vor allem für den Protokollverfasser passenden Vergleich: ,,. . . wenn Sie ein Ei irgendwohin verschicken wollen, verlassen Sie sich nicht auf seine Schale. Sie packen das Ei in einen Behälter, den Sie danach aussuchen, wie rauh der Transport des Eies vermutlich sein wird. Um besonders sorgfältig zu sein, können Sie das Ei in mehrere ineinandergeschachtelte Kästen verpacken. Aber gleichgültig, in wieviele Lagen von Packmaterial Sie das Ei stecken, Sie können sich eine Katastrophe vorstellen, welche es zerbrechen könnte. Das heißt jedoch nicht, daß sie es nie riskieren sollten, ein Ei zu transportieren . . . "

4.4 Grundforderungen an Protokolle im Netz Diese Unsicherheit ist charakteristisch für den Unterschied zwischen lokalisierten und räumlich verteilten EDV-Systemen, zwischen herkömmlichen virtuellen Maschinen und Netzwerkmaschinen, zwischen einer lokalisierten Rechnerinstallation und einem Rechnernetz. Zwar besitzt die Netzwerkmaschine zu jedem Zeitpunkt einen definierten Zustand, dieser ist jedoch an keiner Stelle innerhalb oder außerhalb des Netzes vollständig und exakt bekannt. Wie bereits in Abb. 4.1-3 skizziert, besteht eine Netzwerkmaschine im allgemeinen aus einem Netz tieferer Netzwerk-

4.4 Grundforderungen an Protokolle im Netz

85

maschinen, die ausschließlich über interne Nachrichtenströme miteinander kommunizieren. Informationen über Zustandsänderungen in einer dieser Netzwerkmaschinen können anderen Netzwerkmaschinen also bestenfalls mit der - endlichen - Geschwindigkeit der Nachrichtenübertragung im Netz bekannt werden. Damit kann jede der tieferen Netzwerkmaschinen allenfalls ihren eigenen aktuellen Zustand genau und vollständig kennen - und auch das nur, wenn sie selbst lokalisiert ist und nicht ihrerseits wieder aus noch tieferen Netzwerkmaschinen besteht. Über den momentanen Zustand aller anderen Netzteile kann sie allenfalls Vermutungen anstellen, die sich auf Informationen über vergangene Zustände gründen, jedoch nie sicher sind. Aus dieser unvermeidlichen Unkenntnis des genauen Zustands des Gesamtnetzes ergeben sich Forderungen für die Informations- und Steuerflußstruktur im Netz, die in konventionellen, lokalisierten Systemen nicht auftreten: - Das Zusammenarbeiten der einzelnen Netzwerkmaschinen wird umso besser sein, je schneller jede von ihnen über Zustandsänderungen in den anderen informiert wird. Die netzinternen Nachrichtenströme müssen deshalb - entweder als Beipack (Piggy Back) der zum Datentransport durch das Netz dienenden Nachrichten oder als spezielle Steuernachrichten - laufend möglichst viel Informationen über Zustand und Zustandsänderungen der einzelnen Netzteile vermitteln. - Keine Netzwerkmaschine kann sicher sein, daß eine andere eine von ihr übermittelte Nachricht auch erhält, versteht und bearbeitet. Deshalb muß eine Netzwerkmaschine jede korrekt empfangene Nachricht durch eine Quittung (Acknowledgement, ACK) bestätigen, entweder als Beipack zu einer in der Gegenrichtung laufenden Nachricht oder mit einer speziellen Quittungsnachricht. Bevor der Absender diese Quittung nicht erhalten hat, darf er die ursprüngliche Nachricht nicht vergessen, da er sie unter Umständen wiederholen oder auf einem anderen Weg weiterleiten muß. - An Hand dieser Quittungen müssen die korrespondierenden Netzwerkmaschinen die Synchronisation zwischen sich entsprechenden Zuständen aufrechterhalten. - Zwischen Netzwerkmaschinen muß immer auch ein Wiederaufsetz-Verfahren (Recovery Scheme) vereinbart werden. Dieses legt fest, auf welche Weise sich zwei Netzwerkmaschinen durch Rücksetzen auf einen früheren, beiden bekannten, gemeinsamen Zustand resynchronisieren können, wenn sich herausstellt, daß nicht behebbare Differenzen zwischen den tatsächlichen und den jeweils vermuteten aktuellen Zuständen aufgetreten sind. Die Absicherung eines zuverlässigen Nachrichtenverkehrs trotz der Unkenntnis des vollständigen aktuellen Zustands der Netzwerkmaschine erfordert also Verwaltungsaufwand: neben den eigentlich zu übertragenden Daten müssen zusätzli-

86

4. Netzwerkmaschinen und Netzzustände

che Zustandsinformationen auf den Leitungen übermittelt und in den einzelnen Rechnern des Netzes ausgewertet und verarbeitet werden. Die Minimierung dieses Zusatzaufwands bei gleichzeitiger Maximierung der Übertragungssicherheit und Übertragungsleistung für die Nutzdaten ist der wesentliche Gesichtspunkt bei dem Entwurf oder der Auswahl der Protokolle, der Regeln für den Nachrichtenverkehr zwischen zwei Partnern auf jeder Ebene der Netzwerkmaschinen-Hierarchie. Bei der Spezifikation von Protokollen sollte versucht werden, ihre Korrektheit möglichst weitgehend formal zu verifizieren. Dies ist bei verteilten Systemen noch wichtiger als für Programme in lokalisierten Rechnerinstallationen, weil der Test und die Behebung evtl. erkannter Fehler noch wesentlich aufwendiger sind. Eine grundsätzlich mögliche, allerdings bei komplexen Protokollen wohl auch keineswegs leicht durchzuführende Methode hierfür erläutern v. Bochmann und Gecsei [BOCH77] am Beispiel einer einfachen Erweiterung der in Abschnitt 4.3 dargestellten Nachrichtenübertragung mit Zeitüberwachung. Die Probleme und Ergebnisse der bisherigen Techniken zur formalen Spezifikation und Verifikation von Protokollen stellt Sunshine zusammen [SUNS79].

5. Protokolle

5.1 Die Protokollhierarchie im ARPA-Netz Die Hierarchie abstrakter Netzwerkmaschinen und der in ihnen zwischen Sendeund Empfangsports fließenden Nachrichten konkretisiert Abb. 5.1-1 am Beispiel des ARPA-Netzes [KLEI76], Auf jeder Ebene wird der Informationsaustausch zwischen den Ports nach einem Satz von Regeln, dem Protokoll abgewickelt. Ein Protokoll besteht aus Vereinbarungen über - Übertragungsformate für die Informationseinheiten, - Wertebereiche und Interpretationsregeln für die Verwaltungs- und Prüfinformationen, - Ablauf des Informationsaustauschs im Normalfall, - Sicherung und Fehlererkennung sowie den weiteren Nachrichtenverkehr nach Feststellen eines Fehlers (Abbruch, Wiederholung o. ä.), - Resynchronisierung und Wiederaufsetzverfahren bei Erkennen von Inkonsistenzen im Systemzustand, - Steuernachrichten für die Quittungsermittlung, die Aktualisierung und Abfrage von Zustandsinformationen, Anforderung spezieller Funktionen u. ä. Ein wesentlicher Teil jedes Protokolls ist die Formatierung der Nachrichten in den zu übertragenden Text und die Steuer-, Verwaltungs- und Prüfinformationen, die in dem aus Kopf und ggf. Abschluß bestehenden Nachrichtenrahmen übermittelt werden. Der Text wird auf der jeweiligen Protokollebene grundsätzlich weder interpretiert noch verändert; für die nächst höhere Ebene zerfällt er jedoch seinerseits wieder in einen Nachrichtenrahmen zur Steuerung der höheren Netzwerkmaschine und den auf dieser Ebene zu vermittelnden Nutztext. Abb. 5.1-2 zeigt dies an den untersten Protokollebenen des ARPA-Netzes: je tiefer die Ebene, umso weiter außen liegen der zugehörige Kopf und - falls vorhanden - der Abschluß.

5.2 Die Protokolle des Datenübertragungs-Netzes Im ARPA-Netz wird die unterste Netzwerkmaschine durch das Datenübertragungs-Netz, die IMPs und deren Software realisiert. Nach dem IMP-IMP-Protokoll werden zwischen ihnen Pakete mit einer maximalen Länge von 1192 bit über-

88

5. Protokolle

Netzhierarchieund ProtokollEbene

o

(und höher)

© ©

© =•

: Protokoll

Abb. 5.1-1 Hierarchie- und Protokoll-Ebenen im ARPA-Netz

tragen. Wie Abb. 5.1-2 zeigte, enthält der äußerste, dieser Ebene 1 zugeordnete Rahmen die hierfür nötigen Steuer- und Prüfinformationen. Von diesen 104 bit werden 72 bit bereits durch die Hardware erzeugt und ausgewertet. Auf diesem IMP-IMP-Protokoll baut als Ebene 2 das Ende-Ende-Protokoll zwischen Quell- und Ziel-IMP auf, welchem die Informationen im 80 Zeichen langen Paketkopf zugeordnet sind.

CO

>
W O o o ¿1 c u •a

x> U1

00 a 3 C •O i-i O 3 N

< Oh 06 < Ui

O 3 •o tS .8 1

, -au ää KS "L

03

H

X

Q

J

w

X tu

o u.

x> X)
0 L.

Abb. 5.2-1 Das Host-Host-Protokoll-Format des ARPA-Netzes

(72 bit)

5.3 Höhere Protokollebenen

91

Ein wesentlicher Gesichtspunkt für den Entwurf des Host-Host-Protokolls des ARPA-Netzes war die Inhomogenität des Netzes: die Hosts sind Rechner völlig unterschiedlicher Struktur und Wortlänge. Abb. 5.2-1 zeigt, wie hierauf Rücksicht genommen wurde. Jeder Nachricht ist ein Nachrichtenkopf von 72 bit vorangestellt - 72 bit deshalb, weil diese Länge sowohl üblichen 6 bit- oder 8 bitzeichenorientierten Maschinen als auch Maschinen mit 12-, 24- oder 36-bit Wortlänge angepaßt ist. Der Nachrichtenkopf im Host-Host-Protokoll enthält - die ,,byte"-Größe (b) in Bit, wobei unter byte die vom sendenden Host benutzte Zeichen- oder Wortlänge verstanden wird, sowie - die ,,byte"-Anzahl (a) im Nachrichtentext. Der Ziel-Host kann daraus sowohl die Länge (a * b bit) des folgenden Textes als auch, wenn für Code-Wandlungen notwendig, seine Strukturierung entnehmen. Sofern eine Nachricht nicht mehr durch ein einzelnes Paket übermittelt werden kann, ist es Aufgabe des Quell-IMPs, sie in Pakete zu fragmentieren. Der Ziel-IMP übernimmt es, sie vor Übergabe an seinen Host wieder zu reassemblieren. Der Abwicklung des Host-Host-Protokolls dienen die Netzkommunikations-Programme, welche im ARPA-Netz als Network Control Program (NCP) bezeichnet werden. Auf sie wird in Abschnitt 6.1 näher eingegangen.

5.3 Höhere Protokollebenen Das Host-Host-Protokoll ist die Grundlage der höheren Protokolle auf Ebene 4 für die Abwicklung der Interprozeß-Kommunikation. Diese Protokolle bilden im ARPA-Netz entsprechend Abb. 5.3-1 selbst wieder eine aufgabenorientierte Hierarchie. Sie werden ständig weiter ausgebaut und ergänzt: so gibt es ein Graphics-Protokoll, ein „Data Reconfiguration Services"-Protokoll zur Anpassung von Datenformaten an unterschiedliche Rechner und Aufgabenstellungen und ein „Mail"-Protokoll zur Übermittlung von Texten zwischen Benutzern. Wie man auf der Basis eines höheren Protokolls ein weiteres aufbauen kann, zeigt Abb. 5.3-2 an Hand einer einfachen Erweiterung des ARPA-TELNET-Protokolls für die Übertragung sequentieller Text-Dateien [CROC72]. Sie besteht aus zwei zusätzlichen TELNET-Kommandos, deren Funktion im Grunde das „Umlegen eines Schalters" von dem Benutzer-Terminal zu einer lokalen Datei ist: - SCRIPT lenkt einen ankommenden Zeichenstrom in die Datei und

92

5. Protokolle

BenutzerText-Datei

BenutzerTerminal Abb. 5.3-2 Einfacher Textdatei-Tranfer mit Hilfe des erweiterten ARPA-TELNET-Protokolls

- SENDFILE sendet einen Dateiinhalt zeichenweise, als würde er gerade vom Terminal aus eingegeben. Für den abgesetzten Dienstleistungsprozeß, welcher eine korrespondierende Datei verwaltet, erscheint somit die Datei des Benutzers als „virtuelles ARPA-Terminal". Damit übernimmt das TELNET-Protokoll gegebenenfalls auch die aufwen-

93

5.3 Höhere Protokollebenen

dige Codewandlung zwischen Rechnern mit unterschiedlicher Zeichendarstellung. Inzwischen ist diese TELNET-Erweiterung zwar längst durch das wesentlich effizientere FTP ersetzt, entsprechende Lösungen werden aber immer wieder in Netzentwicklungen sinnvoll sein, wenn es gilt, möglichst rasch brauchbare Übergangsverfahren bereitzustellen. Die höheren ARPA-Protokolle bestehen aus einer Folge von Kommandos und Rückmeldungen, die Zeichenketten mit standardisierter Syntax sind [WHIT77]: Kommando-Name ( Z R ) Parameter (WRZV) Rückmeldungs-Nr. ( Z R ) Text (WRZV) ( ( Z R ) = Zwischenraum, (WRZV) = Wagenrücklauf und Zeilenvorschub). Da ein Kommando nur einen Parameter haben kann, müssen MultiparameterOperationen als Kommando-Ketten abgesetzt werden. So verlangt die Umbenennung einer Datei im FTP den folgenden Dialog: RNFR ( Z R ) Alter Name

200

(ZR) Next Parameter (WRZV)

253

(ZR) File Renamed

(WRZV)

RNTO ( Z R ) Neuer Name (WRZV)

(WRZV)

Dieser Entwurfsmangel bringt höhere Netzbelastungen und Wartezeiten sowie die unerwünschte Folge, daß sich jeder Anwendungsprogrammierer aus den bereitgestellten Primitivfunktionen sein eigenes, nichtstandardisiertes, aber benutzerfreundliches Laufzeitpaket mit höheren Operationen implementiert. Abb. 5.3-3 zeigt die Struktur der höheren Protokolle im europäischen EIN-Netz. Die baumartige Hierarchie schafft klarere Abhängigkeiten als im ARPA-Netz und dürfte - wegen der Trennung in Dialog und Massendaten-Übertragung auf der ersten Hierarchiestufe - auch effizienter zu realisieren sein. Von Barber [BARB79] stammt der Vorschlag, Protokolle für virtuelle Terminals und den Transfer nahezu beliebig strukturierter Dateien so zu realisieren, daß - der zu übermittelnde Informationsstrom grundsätzlich als Zeichenkette in einem Standard-Code übertragen wird und - die Steuer-, Formatierungs- und Aufbereitungsinformationen als „Klartext" zwischen standardisierten Begrenzern (z. B. ,,()'" und ,,'()") codiert werden. Eine zu übertragende Zeichenfolge hätte dann etwa das folgende Aussehen: 0 ' FORM FEED '() Überschrift ()' 2 LINE FEED '() erste Textzeile ()' LINE FEED '() ()' TAB 20 '() Spalten-Überschrift . . . Ein bestimmter Grundvorrat an Steuerinformations-Einheiten kann vordefiniert werden, und für besondere Wünsche oder Anforderungen können jederzeit neue

94

5. P r o t o k o l l e

Terminal-Dialog (Virtual Terminal)

Dialogprotokoll (Line Oriented Protocol) (

FernstapelVerarbeitung

Dateitransfer

Datenbasiszugriff

(Remote Job Entry)

(File Transfer Protocol)

(Remote Data Base Access)

LOP

Massendaten-Protokoll (Bulk Transfer Protocol)

Kommunikation zwischen „Transportstationen" (=NCPs) A b b . 5 . 3 - 3 H ö h e r e P r o t o k o l l e im E I N - N e t z

festgelegt und mit nicht zu großem Aufwand und wenig Gefahr für Mißverständnisse implementiert werden. Zwar bringt diese Idee eine nicht vernachlässigbare Durchsatzeinbuße wegen des relativ hohen Anteils an Steuerinformation im Gesamttext, ist aber trotzdem wegen ihrer einfachen Realisierung, hohen Verständlichkeit und „Selbstdokumentation" der höheren Protokolle vor allem in wachsenden Netzen sehr attraktiv. Für den Benutzer und den Entwickler von Anwendungsprogrammen definieren diese höheren Protokolle die vom Netz realisierte „verteilte Maschine" und die von ihr bereitgestellten Dienstleistungen. Alle tieferen Ebenen dienen ausschließlich der Realisierung dieser an verschiedenen Orten implementierten funktionalen Ebene und sollten für jeden, der nicht als Systemprogrammierer unmittelbar an der Implementierung der Netzsoftware arbeitet, unsichtbar („transparent") sein. Die Verständlichkeit, Handhabbarkeit, Vollständigkeit und Sicherheit der höheren, anwendungsorientierten Protokolle ist entscheidend für den Einsatzwert und für die Leistungsfähigkeit eines Netzes: auch die effizientesten „tieferen" Protokolle sind schlecht, wenn sie nicht auf die Bedürfnisse der höheren abgestimmt sind. Sie lassen dann nur unzweckmäßige Realisierungen zu und zwingen Benutzer und Anwendungsprogrammierer auf Grund von Mißverständnissen oder mangelhaften Möglichkeiten zu ungünstigen Lösungen ihrer Kommunikationsprobleme.

5.4 Grundregeln für die Protokollplanung

95

5.4 Grundregeln für die Protokollplanung Die Planung eines Netzes sollte deshalb mit einer zumindest groben Spezifikation der anwendungsorientierten Protokolle beginnen. Das bereitzustellende Angebot umfaßt Protokolle zum - Vermitteln zwischen Prozessen und Verbindungsauf nehmen zwischen Ports zum Senden, Empfangen und Unterbrechen zu übertragender Nachrichten (ARPA: Initial Connection Protocol), - Benutzerdialog mit dem Netz und seinen Dienstleistungen (ARPA: Protocol, Remote Job Entry),

TELNET

- Übermitteln von Datenbeständen innerhalb des Netzes (ARPA: File Transfer Protocol, Data Reconfiguration Services), - Anfordern spezieller Netzdienstleistungen (ARPA: Graphics Protocol, Mail Protocol und experimentelle Protokolle für Sprachübertragung, Message Switching und Sonderwünsche spezieller Benutzergruppen). Die Forderung der Transparenz der tieferen Protokollebenen hat für den Entwurf der höheren eine wesentliche Konsequenz: der Benutzer oder Anwendungsprogrammierer sollte sich nicht Rechenschaft darüber geben müssen, ob sein Kommunikationspartner ein Prozeß auf dem gleichen oder einem fremden Host ist. Die Primitivoperationen sollten also denen einer normalen Interprozeß-Kommunikation oder Dienstleistungsanforderung in einem lokalisierten System entsprechen, also etwa aus einem OPEN, CLOSE, READ, WRITE, WAIT und ggf. noch einigen Steuer- und sonstigen Sonderfunktionen bestehen. Insbesondere muß aber bei höheren Protokollen das Vertrauensprinzip in die Rückmeldung gelten: erhält ein Prozeß eine positive Quittung aus dem zuständigen Port, so soll er sich darauf verlassen können, daß keine Diskrepanzen zwischen dem eigenen Zustand und dem seiner Partners vorliegen, und daß er keine weiteren Kontrollen mehr vorzunehmen braucht. Dies ist der entscheidende Unterschied zwischen den höheren und tieferen Protokollebenen. Für das Host-Host-Protokoll und darunter liegende Ebenen bedeutet nämlich der Empfang einer Quittung in der Regel noch nicht, daß eine vollständige Synchronisation der Zustände aller bei der Übertragung mitwirkenden Systemkomponenten vorliegt, und daß die Gesamtübertragung bis zu diesem Zeitpunkt völlig fehlerfrei verlief. Auf den tieferen Ebenen können Nachrichten trotz korrekter Einzelquittung ausfallen, doppelt auftreten oder in ihrer Reihenfolge vertauscht werden. Es ist eine wesentliche Aufgabe der tieferen Netzwerkmaschinen, die jeweils von ihnen betreuten Ports so gut wie möglich von diesen Fehlern abzuschirmen. Das Protokoll muß durch entsprechende Sicherungen, wie Folgenumerierung und Zeitüberwachung, die Möglichkeit hierzu schaffen.

96

5. Protokolle

5.5 Die Realisierung eines Protokolls Ein Protokoll wird durch Prozeduren realisiert, welche auf den jeweiligen Rechnern als Softwarebausteine (Leitungsprozeduren) oder auch teilweise hardwareunterstützt (Übertragungssteuerung) ablaufen. Die Sendeprozedur übernimmt den zu übertragenden Text. Sie hat die Aufgabe, ihn in den Nachrichtenrahmen (Startzeichen, Kopf, Prüfzeichen u. ä.) einzuschließen. Die Empfangsprozedur muß den Nachrichtenrahmen interpretieren und den übermittelten Text zur Weiterverarbeitung zur Verfügung stellen. Abb. 5.5-1 zeigt als einfaches Beispiel das BSC-Protokoll, welches u. a. im ARPA-Netz als IMP-IMP-Protokoll benutzt wird (vgl. Abb. 5.2-1). Ein zu übertragender Block wird mit SYN-Zeichen zur Synchronisation von Sender und Empfänger eingeleitet. Die Zeichenkombination DLE STX (Data Link Escape und Start of Text) kündigt den Beginn des eigentlichen Textes an. Das Ende des Textes zeigt die Kombination DLE ETX (Data Link Escape und End of Text) an. Anschließend folgt noch die 24 bit lange Prüfsumme. Der Text selbst wird vom Protokoll grundsätzlich als Zeichenkette angenommen, auch wenn er „in Wirklichkeit" eine anders strukturierte Bitkette ist. In dieser könnte jedoch zufällig die Zeichenkombination DLE ETX vorkommen, welche vom Empfänger als Textende mißverstanden würde. Um dies zu vermeiden, setzt die Sendeprozedur grundsätzlich vor jedes zufällig im Text auftretende DLEZeichen ein weites, welches der Empfänger wieder entfernen muß. Protokolle, welche auf diese oder ähnliche Weise (z.B. Einschieben von einzelnen Bits bei der HDLC-Prozedur) eine Übertragung jedes beliebigen Textes ohne Verwechslungsgefahr mit Steuerinformation ermöglichen, werden transparent genannt. Während des Sendens oder Empfangens eines Datenblocks müssen die miteinander kommunizierenden Prozeduren eine Reihe von Zuständen durchlaufen, in welchen jeweils bestimmte Aktionen ausgeführt werden (z. B. Zeichen lesen, Textzeichen abspeichern). Die Abfolge dieser Aktionen wird durch die gemäß dem Protokoll als nächste gesendeten oder in der Nachricht empfangenen Zeichen gesteuert. Abb. 5.5-1 zeigt auch das Zustandsdiagramm für die BSC-Empfangsprozedur. Die Zustandsdiagramme beschreiben das jeweilige Protokoll und sind gleichzeitig Ausgangspunkt für seine programmtechnische Realisierung [SCHN75] - eine fachmännisch implementierte Übertragungsprozedur wird immer als endlicher Automat geplant. Sie wird meist durch eine Tabelle der einzelnen Zustände und der in ihnen auszuführenden Aktionen (Unterprogramme) sowie durch die auszusendenden oder empfangenen Zeichen getrieben. Dabei durchlaufen ihre Zustände das Zustandsdiagramm gemäß Abb. 5.5-1.

5.5 Die Realisierung eines Protokolls

97

SYN

SYN DLE

STX

[ l

Textzeichen abspeichern

sonst

DLE DLE

ETX

Prüf-

Prüfsumme \ konV / trollieren J

richtig

DatenblockEnde

Abb. 5.5-1 BSC-Datenblock und -Zustandsdiagramm

Sind die Protokolle als endliche Automaten beschrieben, so ist die Programmierung der zu ihrer Abwicklung nötigen Prozeduren weitgehend Routine. Die in der Praxis oft beträchtlichen Realisierungsschwierigkeiten entstehen in der Regel ent-

98

5. Protokolle

weder aus Unklarheiten in der Protokolldefinition, vor allem in der Beschreibung der Fehler- und Ausnahmezustände, oder aus Zeitproblemen: häufig sind der empfangende Rechner und die auf ihm laufende Prozedur nicht schnell genug, die ankommende Bit- oder Zeichenkette abzuarbeiten. Das Programm muß dann oft „trickreich" optimiert werden. Darunter leiden wieder die klare Strukturierung, die Fehlerfreiheit und die Anpassungsfähigkeit bei Änderungen oder Erweiterungen der Prozedur. Auch und gerade bei der Entwicklung der Datenübertragungsprozeduren rächt sich jedes Abgehen von der konsequenten Top Down-Planung und -Realisierung. Es führt zu unzuverlässiger Software und teurer Fehlersuche und Wartung. Erst nach exakter und vollständiger Definition der Aufgabenstellung - hier der Protokolle und der sie beschreibende Zustandsdiagramme - darf mit der Realisierung begonnen werden. Eine Optimierung ist erst dann möglich, wenn auf der Grundlage dieser Zustandsdiagramme einwandrei strukturierte, korrekte und übersichtliche Programme für die Prozeduren vorliegen.

6. Die Netzschnittstelle und die Flußsteuerung

6.1 Das Netz-Kommunikationsprogramm Bereits im ersten Kapitel idealisierten wir ein Rechnernetz als eine Menge von Verarbeitungsprozessen auf Hosts und Terminalprozessen mit einem Kommunikations-Subsystem. Dieses ist in der Regel als räumlich verteilte Netzwerkmaschine aus einzelnen Knotenrechnern, den IMPs, realisiert und übernimmt die Nachrichten Vermittlung. Zwischen Verarbeitungs- und Terminalprozessen auf der einen Seite und dem Kommunikations-Subsystem auf der anderen existiert eine Schnittstelle, welche durch ein Softwaresystem überbrückt werden muß. Für die ses überwiegend auf den Hosts, manchmal teilweise auch auf Vorrechnern oder IMPs realisierte Programmsystem gibt es eine Reihe von Bezeichnungen. Die häufigsten sind - Network Control Programm, NCP (ARPA-Netz), - Transportstation, TS (CYCLADES), - Message transmission Controller, MTC (PIX). Die Systems Network Architecture (SNA) der IBM betont die logische Funktion für jeweils einen betreuten Port (eine Network Adressable Unit, vgl. Abschnitt 3.3) und spricht von einer - Half

Session,

da sie mit ihren Komponenten zur Funktionsinterpretation (Function Interpreter for Function Management Data), Datenfluß-Steuerung (Data Flow Control) und Übertragungssteuerung (Transmission Control) die dem Port zugeordnete „ H ä l f t e " einer virtuellen Verbindung (Session) abwickelt. Diese Bezeichnung erscheint jedoch wenig glücklich, da sie kaum die Vorstellung einer räumlich lokalisierten Software-Funktion nahelegt. Wir wollen hier die gebräuchliche Abkürzung NCP übernehmen und sie als NetzKommunikationsprogramm interpretieren. Die Aufgabe des Netz-Kommunikationsprogramms ist es - den Prozessen Schnittstellen (Ports) für die Abwicklung der höheren Protokolle zur Interprozeß-Kommunikation zur Verfügung zu stellen, - diese mit Hilfe des niedrigeren Host-Protokolls möglichst effizient über die Netzschnittstelle zu realisieren, - die höheren Prozesse gegen wechselnde Übertragungscharakteristiken und Übertragungsfehler im Netz abzuschirmen und

100

6. Die Netzschnittstelle und die Flußsteuerung

- Steuer- und Betriebsmittelverwaltungsfunktionen sowohl für die betreuten Prozesse als auch für das Netz wahrzunehmen. Für die Implementierung dieses Netz-Kommunikationsprogramms in einem bereits bestehenden Host-System gibt es die beiden Alternativen, welche Abb. 6.1-1 zeigt. Es kann © entsprechend den Zugriffsmethoden zur lokalen Peripherie in das Betriebssystem eingefügt werden ® als „privilegierter Verarbeitungsprozeß" die empfangenen und auszusendenden Daten mit den eigentlichen, von ihm bedienten Verarbeitungsprozessen über die Interprozeß-Kommunikation des Betriebssystems austauschen. Die Möglichkeit © erfordert Eingriffe in das Hersteller-Betriebssystem des HostRechners und ist daher verhältnismäßig mühsam zu implementieren. Die einfachere Realisierungsmöglichkeit © bringt andererseits durch den zeitaufwendigen Nachrichtenaustausch zwischen NCP und Verarbeitungsprozessen Verzögerungen, die zuweilen die Größenordnung von einer Sekunde erreichen können und deshalb meist nur bei vorläufigen „Experimentierlösungen" tragbar sind. Oft wird ein Kompromiß zwischen beiden Alternativen gewählt, wobei die zeitkritischen Aufgaben als Teile des Betriebssystems, die übrigen jedoch auf der Ebene der Anwendungsprozesse realisiert werden.

©

©

Abb. 6.1-1 Alternative Realisierungsmöglichkeiten eines Netz-Kommunikationsprogramms: © als Teil des Host-Betriebssystems (Zugriffsmethode) © als privilegierter Verarbeitungsprozeß

101

6.1 Das Netz-Kommunikationsprogramm

D i e Struktur einer derartigen Netzschnittstelle zeigt A b b . 6.1-2. Es handelt sich hierbei um den Anschluß von P D P 11-Rechnern unter dem UNIX-Betriebssystem an das A R P A - N e t z [CHES75], Das Netz-Kommunikationsprogramm ist aufgeteilt in einen arbeitsspeicherresidenten Kern und einen nichtresidenten Dämon,

welcher logisch und programm-

technisch auf gleicher Ebene wie die betreuten Verarbeitungsprozesse

steht. Er

übernimmt ohnehin zeitaufwendige oder seltene Steuerungsfunktionen, wie etwa O P E N und C L O S E von Verbindungen oder die Aktualisierung von Tabellen. Man kann ihn als Dienstleistungsprozeß für die Verwaltung der Host-Netz-Schnittstelle betrachten. Der Kern des N C P ist kein Prozeß sondern ein Satz von Routinen zur Unterbrechungsbehandlung

der

angeschlossenen

Datenübertragungshardware.

A b b . 6.1-2 Programmstruktur der UNIX-Netz-Schnittstelle ( N C P = residenter Kern und nichtresidenter Dämon)

Wie

102

6. Die Netzschnittstelle und die Flußsteuerung

Abb. 6.1-3 zeigt, nimmt er von ihr einerseits Einzelzeichen oder Zeichengruppen (z. B. Worte, Pakete) entgegen, um aus ihnen Nachrichten für die Verarbeitungsprozesse aufzubauen; andererseits zerlegt er von den Verarbeitungsprozessen übergebene Ausgabenachrichten in Einzelzeichen oder Zeichengruppen für die Datenübertragung. Dabei ist er auch für Behandlung der nötigen Steuerzeichen und Steuernachrichten zuständig.

Abb. 6.1-3 Funktionen des Kerns des NCP

6.1 Das Netz-Kommunikationsprogramm

103

Je nach den Anforderungen an ein Netz-Kommunikationsprogramm können seine Komplexität und damit die Programmgröße sehr unterschiedlich sein. Vor allem kommt es hierbei darauf an, welcher Aufwand für die Port- und Pufferverwaltung getrieben wird. Tabelle 6.1^1 zeigt dies an einigen realisierten Transportstationen (NCPs) des CYCLADES-Netz. Tabelle 6.1-4 Codeumfang einiger „Transportstationen" (Netz-Kommunikationsprogramme) im CYLADES-Netz (private Mitteilung von L. Pouzin). Hardware

Codeumfang

Leistungsmerkmale

Großrechner: CII IRIS 80 IBM/360

24 k Byte 28 k Byte

dynamische Port- und Pufferverwaltung

Kleinrechner: CII IRIS 50

8 k Byte

feste Ports, keine dynamische Pufferverwaltung

intelligentes Terminal: TVT 6000

1,6 k BYTE

1 Port

6.2 Netzüberlastung und Betriebsmittelverwaltungs-Strategien An der Netzschnittstelle tritt erstmals ein Problem auf, welches die gesamte niedere Netzhierarchie durchzieht und mit welchem sich der Entwickler auf jeder Ebene der Netzplanung erneut auseinandersetzen muß: die Flußsteuerung (Flow Control). Anschaulich handelt es sich um das Vermeiden einer Überlastung des Empfängers oder des Übertragungsmediums, sei es einer Einzelleitung oder des Kommunikations-Subsystems, durch eine zu schnelle Nachrichtenabgabe des Senders. Eine Überlastung (Congestion) ist in einem Netz wesentlich gefährlicher als in einer lokalisierten EDV-Installation; bei ihr führt nämlich eine Erhöhung der Belastung lediglich zu einer etwa proportionalen Verlängerung der mittleren Wartezeiten und wirkt damit selbstregulierend. Im Kommunikations-Subsystem hingegen gehen diejenigen Nachrichten verloren, die von ihrem Empfänger - einem IMP oder dem Ziel-Host - nicht angenommen werden können. Sie müssen nach einiger Zeit wiederholt werden, was die Netzbelastung weiter erhöht und so lawinenartig zu einem überraschenden Zusammenbruch der gesamten Nachrichtenübermittlung führen kann. Von einem allgemeineren EDV-technischen Standpunkt aus betrachtet ist die Flußsteuerung ein Teilproblem der Regelung des Wettbewerbs verschiedener Prozesse um einen beschränkten Vorrat an Betriebsmitteln, und zwar derjenigen, die für die Nachrichtenübertragung benötigt werden. Dies sind Puffer und Rechnerkapazität in IMPs und Hosts sowie die Übertragungsleitungen.

104

6. Die Netzschnittstelle und die Flußsteuerung

Neben der primären Aufgabe jeder Flußsteuerung, der Vermeidung einer wesentlichen Verschlechterung der Übertragungsleistung eines Netzes oder gar seiner völligen Blockierung (Deadlock) durch Überlastungen, sind bei ihrer Planung noch einige sich teils widersprechende Sekundärziele zu beachten und gegeneinander abzuwägen: - die optimale Auslastung der zur Verfügung stehenden Betriebsmittel, - die faire Zuteilung der Übertragungsleistung und -betriebsmittel an die einzelnen Prozesse oder Hosts, ggf. unter Berücksichtigung bestimmter Informationen, wie etwa Rückmeldungen oder Nachrichten zur Netzsteuerung, - maximaler Durchsatz für alle oder ausgewählte Nachrichtenströme im Netz, - minimale Antwortzeiten, besonders für den interaktiven Nachrichtenverkehr. In Kapitel 4 hatten wir das Netz auf jeder Ebene der Top Down-Entwicklung als eine Netzwerkmaschine idealisiert, die aus Ports Nachrichten entgegennimmt und an andere übermittelt. Entsprechend Abb. 6.2-1 sind dabei folgende Betriebsmittel zu verwalten: die Übertragungs- und Verarbeitungskapazität der Netzwerkmaschine und des Empfängers sowie die Puffer von Sender, Empfänger und Netzwerkmaschine. Die Pufferkapazität der Netzwerkmaschine braucht dabei nicht ausschließlich durch physische Puffer in IMPs realisiert zu sein. Auch die zu jedem Zeitpunkt gerade auf Übertragungsmedien transportierten Nachrichten sind in der Netzwerkmaschine gespeichert. Vor allem bei Satellitenübertragungen mit Signallaufzeiten von ca. iU sec ist die Speicherkapazität des Übertragungskanals selbst beträchtlich.

AusgabePorts

EingabePorts

Host

gesamtes Kommunikations-Subsystem

Host

IMP

Unternetz oder Leitung

IMP

Abb. 6.2-1 Sender, Netzwerkmaschine und Empfänger als Betriebsmittel der Nachrichtenübertragung

6.2 Netzüberlastung und Betriebsmittelverwaltungs-Strategien

105

Nach Abb. 6.2-1 gibt es drei an der Flußsteuerung beteiligte Instanzen und damit drei sich in der Verantwortungsverteilung unterscheidende Grundstrategien. Entweder ® müssen Netzwerk(maschine) und Empfänger die Übernahme jeder Nachricht garantieren. oder © der Sender darf nur soviel Nachrichten abgeben, wie Netzwerk(maschine) und Empfänger aufnehmen können oder ® Sender, Netzwerk(maschine) und Empfänger arbeiten jeweils mit ihrer maximalen Geschwindigkeit, und jede Nachricht, welche die Übertragungskapazität überschreitet, geht verloren und muß bei Ausbleiben der Bestätigung vom Sender wiederholt werden. Die Strategie ® ist in der Regel nicht zuverlässig realisierbar. Die Wahl zwischen den beiden anderen sollte durch die gewünschte Übertragungseigenschaften des Netzes bestimmt werden. Die Strategie © , die Steuerung der Sendegeschwindigkeit entsprechend der vorhandenen Übertragungs- und Verarbeitungskapazität, optimiert die Ausnutzung der verfügbaren Betriebsmittel und gibt damit die Möglichkeit, den Gesamtdurchsatz des Rechnernetzes vor allem für längere Nachrichtenströme zu maximieren. Dies erfordert jedoch Anfragen des Senders an Netzwerkmaschine und Empfänger über deren Aufnahmefähigkeiten zu jedem Zeitpunkt. Da diese Anfragen zeitraubend sind, erhöhen sie die Wartezeit für kurze, interaktive Nachrichten. Strategie © , das Senden und Übertragen mit höchstmöglicher Geschwindigkeit, hat diesen Nachteil nicht, zumindest solange Netz und Empfänger nur schwach belastet sind. Für Netze, bei welchen geringe Übertragungs- und Antwortzeiten für kurze Nachrichten das primäre Entwurfsziel sind, wird deshalb diese dritte Flußsteuerungsstrategie bevorzugt. Allerdings muß dann eine schnelle und ausgeprägte Verschlechterung der Übertragungseigenschaften bei Überlastung in Kauf genommen werden. Zuweilen werden auch Mischstrategien benutzt, wobei für die Übertragung von Massendaten, wie etwa den Dateitransfer, eine durchsatzoptimierte, für kurze, interaktive Nachrichten jedoch eine antwortzeitoptimierte Flußsteuerung implementiert wird. Da beide Datenverkehrsarten sich jedoch gegenseitig beeinflussen, wenn sie das gleiche Netz benutzen, ist die Realisierung solcher Kompromißlösungen keineswegs problemlos.

106

6. D i e Netzschnittstelle und die Flußsteuerung

6.3 Grundverfahren der Flußsteuerung Unabhängig von der verwendeten Strategie und der jeweils betrachteten Ebene setzt jede Flußsteuerung Informationen über den momentanen Zustand der Sender, der Empfänger und der Netzwerkmaschine voraus. Je nachdem, wo und wie diese Informationen gesammelt, verwaltet und verteilt werden, unterscheidet man die zentralisierte, die globale und die lokale Flußsteuerung. Bei der zentralisierten Flußsteuerung ist ein zentraler Steuerrechner für die Überwachung des Gesamtnetzes und die Zuteilung der Betriebsmittel verantwortlich. Dieses Verfahren ist nur dann praktikabel, wenn durch die Netzgeometrie bereits ein Rechner als zentraler Netzknoten ausgezeichnet ist. Da über ihn der gesamte Nachrichtenverkehr läuft, kann er damit auch diese Aufgabe auf natürliche Weise übernehmen. In anders strukturierten Netzen scheitert eine zentralisierte Flußsteuerung meist an den aufwendigen Auslastungsberechnungen für das Gesamtnetz, der zu großen Netzbelastung durch die erforderlichen Steuernachrichten zwischen Hosts, Knoten und zentralem Steuerrechner, der durch die Nachrichtenlaufzeit verursachten Trägheit der Anpassung an wechselnde Belastungszustände und den Problemen der Übernahme der Steueraufgabe bei Ausfall des zentralen Steuerrechners. All diese praktischen Schwierigkeiten bei der Realisierung einer zentralisierten Flußsteuerung haben letztlich ihre Ursache darin, daß die in Abb. 6.2-1 gezeigte Netzwerkmaschine nur bei einfachen Sternnetzen ein einziger, lokalisierter Rechner ist. Bei komplizierter strukturierten Netzen ist sie selbst wieder ein Netz hierarchisch tieferer Netzwerkmaschinen, z. B. der einzelnen IMPs. Damit hat sie zwar zu jedem Zeitpunkt einen definierten Zustand, dieser ist aber an keiner Stelle im Netz exakt bekannt. Deshalb gibt es auch keine Stelle im Netz, welche die Funktion einer zentralen Steuerung übernehmen kann, die ja eine vollständige und aktuelle Information über den gesamten Netzzustand voraussetzt. Um diese grundsätzliche Schwierigkeit zu umgehen, kann man zwei Ausgangspunkte wählen: - Man kann die Netzwerkmaschine als „schwarzen Kasten" ansehen und sich auf die Aussagen beschränken, die man global über ihre Aufnahmefähigkeit für Nachrichten und ihr Verhalten an den Netzschnittstellen machen kann, ohne genaue Kenntnisse über ihren aktuellen Zustand zu besitzen. - Man kann aber auch die Netzwerkmaschine in ihre tiefsten Komponenten aufspalten, etwa in die einzelnen IMPs und die Übertragungsleitung zwischen ihnen, und es jedem IMP überlassen, lokal den Nachrichtenfluß zwischen sich und seinem nächsten Nachbarn zu optimieren. Dementsprechend unterscheidet man die beiden anderen Grundverfahren der Flußsteuerung, von denen es jeweils eine Reihe von Varianten gibt.

6.3 Grundverfahren der Flußsteuerung

107

Die globale Flußsteuerung basiert auf der Kenntnis der gesamten Aufnahmefähigkeit des Netzes und versucht, die Zahl der Nachrichten im Netz entsprechend zu beschränken. Da dies zwangsläufig an der Netzschnittstelle der Hosts im Rahmen des Host-Host oder Host-IMP-Protokolls geschehen muß, ist die globale Flußsteuerung primär auch für eine faire Verteilung der Übertragungsleistung des Netzes an die einzelnen Hosts und gegebenenfalls für eine gewollte Bevorzugung bestimmter Nachrichten verantwortlich. Die lokale Flußsteuerung beruht hingegen auf den Informationen, die jeder IMP über den aktuellen Belastungszustand, die gerade ankommenden und abgehenden Nachrichten, den Zustand seiner unmittelbaren Nachbarn und den vermuteten Zustand des Gesamtnetzes hat. Diese Informationen hält er in Tafeln, die er mit Hilfe eines ständigen Austauschs von Steuernachrichten mit seinen Nachbarn periodisch aktualisiert. Die lokale Flußsteuerung ist damit zugleich auch für eine optimale Auslastung der einzelnen Betriebsmittel des Netzes sowie für die Vermeidung lokaler, gegenseitiger Blockierungen von IMPs zuständig. Da globale und lokale Flußsteuerungsverfahren somit verschiedene Ausgangspunkte und Zielrichtungen haben, müssen sie in der Regel kombiniert werden, um ein optimales Netzverhalten zu erzielen. Deshalb kann bei der Top Down-Planung eines Netzes die Flußsteuerung nicht auf einer bestimmten Netzwerkmaschinenoder Protokoll-Ebene abgehandelt werden. Sie muß vielmehr auf jeder Planungsstufe erneut mit jeweils anderen Forderungen und Zielen überdacht und gelöst werden.

6.4 Globale Flußsteuerungen auf Verbindungsbasis Auf der Ebene des Host-Host-Protokolls und der Netzschnittstelle eines Hosts ist lediglich die globale Flußsteuerung von Bedeutung. Sie geht meist entsprechend Abb. 6.2-1 von der durch die Netzwerkmaschine hergestellten realen oder virtuellen Verbindung zwischen zwei miteinander kommunizierenden Hosts aus. Die Ende-Ende-Steuerung (End to End-Control) nimmt an, daß diese Verbindung zu jedem Zeitpunkt einschließlich der im Empfänger noch unverarbeitet zwischengepufferten Informationen nur eine bestimmte Datenmenge fassen kann [HERR76, KAHN72]. Die Steuerung des Datenflusses kann dann auf unterschiedliche Weise erfolgen. Im ARPA-Netz hat der empfangende Host die Führung: entsprechend seiner Pufferkapazität autorisiert er den Sender über Allocation-Nachrichten von Zeit zu Zeit, eine bestimmte Maximalzahl weiterer Nachrichten und Bits zu senden. Der Sender führt für jede Verbindung Zähler für die ihm zugebilligten Nachrichten und Bits. Diese zählt er bei jeder Allocation-Nachricht hoch und bei jeder abgesandten Nachricht wieder herunter. Steht einer der Zähler auf 0, so muß der Sender bis zur nächsten Allocation-Nachricht vom Empfänger aussetzen.

108

6. Die Netzschnittstelle und die Flußsteuerung

Dieser Mechanismus ist zwar sehr plausibel, er hat aber einen wesentlichen Mangel. Gehen Allocation-Nachrichten verloren, so sind Sender und Empfänger in bezug auf die Flußsteuerung nicht mehr synchronisiert, und die Sendegeschwindigkeit wird unnötig herabgesetzt. Im Extremfall kann die Übertragung sogar völlig zum Erliegen kommen: ob der Sender schweigt, weil er zur Zeit keine zu übermittelnden Daten mehr hat, oder weil keine Allocation-Nachrichten bei ihm angekommen sind, kann der Empfänger nicht unterscheiden. Weder Sender noch Empfänger bemerken den Verlust und sehen deshalb auch keinen Grund, sich zu resynchronisieren. Ist ein Protokoll auf diese Weise gegen Übertragungsfehler empfindlich, so spricht man von mangelnder Robustheit. Einen wesentlich robusteren Flußsteuerungsmechanismus ermöglichen Laufnummern (Sequence Numbers) für die Nachrichten sowie Übertragungsfenster (Windows) bei Sender und Empfänger. Hierbei gibt der Sender jeder Nachricht als „Namen" eine sequentiell aufsteigende Laufnummer. Der Empfänger meldet jeweils die höchste Laufnummer zurück, bis zu der er alle Nachrichten vollständig empfangen hat. Dabei wird die Möglichkeit berücksichtigt, daß Nachrichten auf Grund unterschiedlicher Wege durch das Übertragungsnetz beim Empfänger in anderer Reihenfolge eintreffen, als sie ausgesandt wurden. Abb. 6.4-1 skizziert das Verfahren. Dabei ist angenommen, daß im Nachrichtenkopf 4 bits für die Laufnummern vorgesehen sind, so daß für die Nachrichten als Namensraum die Nummern 0 bis 15 zur Verfügung stehen; nach Erreichen der Laufnummer 15 wird mit 0 wieder neu begonnen. Die Beschränkung des Nachrichtenstromes zwischen Sender und Empfänger wird durch ein „Fenster" bestimmt, das Sender und Empfänger über diesen zyklischen Namensraum „weiterschieben". In Abb. 6.4-1 ist die Breite dieses Fensters mit 5 angenommen, so daß zu jedem Zeitpunkt maximal fünf unbestätigte Nachrichten unterwegs sein können. Auf der Abbildung hat der Sender die Nachrichten 3 bis 6 bereits abgesandt und baut 7 zum Senden auf. 3 und 4 hat der Empfänger bereits erhalten und bestätigt sie gerade, 5 und 6 sind (in der Netzwerkmaschine) unterwegs. Der Sender kann die Nachricht 7 noch abschicken, muß dann aber eine Bestätigung abwarten. Sobald die Quittung für die Nachrichten 3 und 4 eingetroffen ist, schiebt der Sender sein Fenster weiter; er kann jetzt auch 8 und 9 aufbauen und absenden. Die bestätigten Nachrichten 3 und 4 braucht er nicht mehr zwischenzupuffern, da ihr Verlust und eine Wiederholungsnotwendigkeit nicht mehr zu befürchten sind. Der Empfänger seinerseits ist verpflichtet, eine der Fensterbreite entsprechende Pufferzahl zur Verfügung zu halten. Die Bestätigung der Nachrichten 3 und 4 bedeutet zugleich, daß er sein Fenster für Nachricht 5 bis 9 geöffnet hat und sie bei ihrem Eintreffen sicher aufnehmen kann.

6.4 Globale Flußsteuerungen auf Verbindungsbasis

109

ACK 3 + 4 Abb. 6.4-1 Laufnummern und Übertragungsfenster

Die Fensterbreite wird entweder für das gesamte Netz oder zwischen den Hosts für die jeweilige Verbindung vereinbart. Es ist auch möglich, daß der Empfänger zusammen mit seinen Quittungen jeweils die gewünschte Fenstergröße vorgibt und somit die Übertragungsrate entsprechend seinem aktuellen Puffervorrat steuert [CERF74]. Das Umlaufen der Fenster bei Sender und Empfänger wird automatisch synchronisiert. Dieser Flußsteuerungsmechanismus ist robust gegen jeden Übertragungsfehler. Geht eine Nachricht verloren, so hält das Sende-Fenster wegen des Ausbleibens der Quittung bei ihr an, und der Sender wiederholt auf Grund der Zeitüberschreitung (Time Out) die unbestätigten Nachrichten. Eine verlorene Quittung stört ebenfalls nicht. Entweder merkt der Sender an einer Bestätigung für eine höhere Laufnummer, im Beispiel von Abb. 6.4-1 etwa an einer Quittung für Laufnummer 5, daß auch die vorhergehenden Nachrichten angekommen sind, oder er wiederholt seine Nachrichten ab der ersten unbestätigten Laufnummer und zwingt damit den Empfänger zu einer neuen Bestätigung. Der Empfänger erhält zwar auf diese Weise unter Umständen mehrmals dieselbe Nachricht. Laufnummer und Fenster sorgen aber dafür, daß Duplikate nicht irrtümlich für neue Nachrichten gehalten werden. Es muß lediglich darauf geachtet werden, daß die Breite des Fensters wesentlich kleiner ist als der gesamte durch die Laufnummern aufgespannte Namensraum - 0 bis 15 im Beispiel von Abb. 6.4-1. Andernfalls könnte es vorkom-

110

6. Die Netzschnittstelle und die Flußsteuerung

men, daß ein Duplikat, welches sich im Netz „verlaufen" hat und mit sehr großer Verspätung beim Empfänger eintrifft, bereits wieder ein offenes Fenster für seine Laufnummer vorfindet und für das erste Exemplar dieser Nummer aus dem nächsten Zyklus gehalten wird. Ist dies bei sehr weitverzweigten Netzen zu befürchten, so kann es zweckmäßig sein, Nachrichten mit einem Zeitstempel oder einem Laufzeitzähler zu versehen und sie nach einer bestimmten maximalen Übertragungszeit zu vernichten.

6.5 Globale Flußsteuerungen auf Nachrichten- oder Paketbasis Flußsteuerungsmechanismen, welche entsprechend Abb. 6.2-1 ausschließlich die in der Netzwerkmaschine aufrechterhaltenen Einzelverbindungen berücksichtigen, können auch nur den Nachrichtenstrom auf diesen einzelnen Verbindungen begrenzen. Einer Überlastung des Netzes durch eine starke allgemeine Zunahme des Verkehrs läßt sich auf diese Weise nicht vorbeugen. Einen einfachen Schutz gegen überraschende Überlastung des Gesamtnetzes ermöglicht hingegen die Nachrichtenvermittlung (Message Switching) [WALD72], die oft auch als Datagramm-Vermittlung bezeichnet wird [POUZ76], Bei ihr wird nicht von einer stehenden virtuellen Verbindung zwischen den Hosts ausgegangen. Vielmehr wird für jede zu übertragende Nachricht vom Netz eine Verbindung aufgebaut. Das Kommunikations-Subsystem garantiert dabei weder die rechtzeitige Abnahme, die korrekte Zustellung oder die Übermittlungsreihenfolge der zu übernehmenden Nachrichten. In diesem Fall ist die Nachricht auch die zweckmäßige Einheit für die Flußsteuerung. Sie wird nur dann vom Netz dem Sender abgenommen und an den Empfänger weitergeleitet, wenn im Netz und im Empfänger die hierzu nötigen Pufferkapazitäten zur Verfügung stehen. Andernfalls muß der Sender sie nach einiger Zeit wiederholen. Eine Nachrichtenvermittlung hat für das Host-Host-Protokoll eine Reihe von Vorteilen. - Für den Aufbau einer Verbindung ist nicht wie im ARPA-Netz ein vordefinierter Port nötig. - Das Gesamtverfahren, die Pufferverwaltung, die Verwaltung der Ports und damit das Netzkommunikationsprogramm in den Hosts ist einfach und damit auch auf kleinen Rechnern mit wenig Aufwand realisierbar. - Das Protokoll ist sehr robust, da keine Synchronisation zwischen Sender und Empfänger nötig ist. Im Fehlerfall wird die Verbindung einfach erneut aufgebaut und die Nachricht wiederholt. - Wegen der kurzlebigen Verbindung ist das Übertragen eines Ports auf einen anderen Host, etwa bei Ausfall einer Dienstleistung oder bei Wechsel des Bearbeiters an ein anderes Terminal, problemlos möglich.

6.5 Globale Flußsteuerungen auf Nachrichten oder -Paketbasis

111

- Der aus Gründen der Ausfallsicherheit wünschenswerte Anschluß jedes Hosts an zwei oder mehr IMPs ist einfacher zu realisieren als bei stehenden Verbindungen. Diesen Vorteilen steht als einziger Nachteil der Aufwand für den Neuaufbau der Verbindung vor jedem Nachrichtenaustausch gegenüber. Bei längerfristig stehenden, nicht nur für die Einzelnachricht durchgeschalteten Verbindungen zwischen Hosts ermöglicht die isarithmetische Flußsteuerung [DAVI72] eine Regelung der Gesamtbelastung des Netzes. Ihr liegt die Vorstellung zugrunde, daß die gesamte Transportkapazität des Netzes durch eine bestimmte Anzahl von „Behältern" für zu befördernde Daten repräsentiert wird. Diese verkehren im Netz ähnlich wie Taxis in einer Stadt. Manche sind mit Nachrichten „besetzt", die sie vom Sender zum Empfänger befördern. Andere warten an „Halteplätzen", den einzelnen IMPs, auf Kundschaft. Dabei kann die normalerweise an einem bestimmten Halteplatz wartende Taxi-Anzahl je nach dem erwarteten Verkehrsaufkommen, etwa entsprechend der Zahl und Aktivität der angeschlossenen Hosts, unterschiedlich sein. Taxis, die am Ziel ihres Nachrichtentransports eine überdurchschnittliche Zahl von bereits wartenden vorfinden, begeben sich leer zu Nachbarstandplätzen, um so einer Massierung freier Transportkapazität an einem Punkt vorzubeugen. Das gleiche tun Taxis, die auf Grund eines geringen Verkehrsaufkommens an ihrem Standort schon lange gewartet haben. Eine Nachricht oder ein Datenpaket kann nur dann vom Sender zum Empfänger befördert werden, wenn die Netzwerkmaschine am Absendeport, also etwa im IMP des sendenden Hosts, über ein freies „Taxi" verfügt. Andernfalls muß sein Eintreffen abgewartet werden. Selbstverständlich sind diese „Taxis" für Nachrichten in der Regel keine physikalisch vorhandenen Leer-Nachrichten. Sie sind vielmehr durch Zähler in den IMPs repräsentierte Anrechte (Capabilities) zum Nachrichtentransport. Zwischen IMPs weitertransportiert werden sie in den Köpfen von Steuer- oder Nutznachrichten. Lediglich in Ringnetzen wird zuweilen ein fester, nach einem geregelten Takt gleichförmig umlaufender Strom von vorformatierten leeren Nachrichtenrahmen aufrechterhalten. Am Sendeort werden sie mit den zu übermittelnden Daten gefüllt und nach Erreichen des Empfängers wieder zur erneuten Benutzung freigegeben. Die isarithmetische Flußsteuerung begrenzt die Zahl der maximal im Netz taufenden Nachrichten auf die der insgesamt vorhandenen Transportanrechte, unabhängig von der Zahl und dem Datenaufkommen der einzelnen Host-Host-Verbindungen. Sie arbeitet allerdings auch rein statistisch: Kommt es zufällig zu einer Konzentrierung des im Netz fließenden Nachrichtenstroms in einem lokalisierten Un-

112

6. Die Netzschnittstelle und die Flußsteuerung

terbereich, dann konzentrieren sich dort auch die Anrechte. So kann eine örtliche Überlastung auftreten, während andere Teile des Netzes wegen Mangel an Transportkapazität nicht ausgelastet werden. Simulationsexperimente [PRIC78] zeigten, daß die isarithmetische Flußsteuerung bei komplexeren Netzen tatsächlich einerseits Überlastungen besser vorbeugt als einfachere, auf Pufferbegrenzung beruhende Verfahren, andererseits aber auch Durchsatz und Antwortzeiten verschlechtert. Ein weiterer Nachteil der isarithmetischen Flußsteuerung ist ihre mangelnde Robustheit. Werden auf Grund eines Fehlers irgendwo im Netz irrtümlich Anrechte erzeugt oder vernichtet, so bricht der Betrieb nach einiger Zeit wegen Überlastung des Kommunikations-Subsystems oder Versiegen der Transportkapazität zusammen. Die Zahl der im Netz verkehrenden „Taxis" muß deshalb auf irgendeine Weise überwacht werden - eine Aufgabe, die wegen der freien Beweglichkeit und mangelnden Identifikation jedes einzelnen Transportanrechts sehr schwer befriedigend lösbar ist.

7. Netzstrukturen und Laufwege

7.1 Netz-Topologien Bis jetzt wurde das Datenübertragungsnetz als intern unstrukturiertes Kommunikations-Subsystem idealisiert, als abstrakte Netzwerkmaschine, welche „irgendwie" Informationen zwischen Hosts über Ausgabe- und Eingabeports vermittelt. Dieses rein logische Konzept muß als physisches Netz aus IMPs (Knotenrechnern) und Leitungen realisiert werden. Je nach der Anordnung der IMPs und der sie verbindenden Leitungen können verschiedene Netz-Topologien gewählt werden, die sich in ihren Vor- und Nachteilen unterscheiden, und aus denen der Planer entsprechend den beim Entwurf der höheren Ebenen aufgetretenen Anforderungen seine Auswahl treffen muß. Tabelle 7.1-1 dient hierbei als Wegweiser: sie zeigt die wichtigsten Grundtypen aus einer Taxonomie der Rechnerkopplungen und -netze [ANDE75], Auf der obersten Ebene dieses Schemas können zwei Übermittlungsstrategien unterschieden werden. Bei der direkten Übermittlung übergibt die Quelle (IMP oder Vorrechner eines Hosts, oder der Host selbst) die Nachricht unmittelbar an das Ziel, bei der indirekten sind im allgemeinen Vermittlungsrechner oder andere IMPs zwischengeschaltet. Das nächste Unterscheidungskriterium zwischen den verschiedenen Netztopologien ist die Laufwegermittlung, d. h. die im Netz zur Feststellung des gewünschten Zielrechners, der Wegwahl, zuständige Instanz. Bei der direkten Übermittlung gibt es hier zwei Möglichkeiten. Entweder wird die Nachricht von der Quelle nur an den gewünschten Zielrechner gesendet - dann ist dieser eindeutig bestimmt - oder sie gelangt über einen Bus, eine gemeinsame Übertragungsleitung, an alle anderen Rechner im Netz - dann ist die Zielrechnerermittlung dezentralisiert, und jeder Rechner muß durch Interpretation der im Nachrichtenkopf stehenden Zieladresse selbst feststellen, ob er der gewünschte Adressat ist. Auch bei der indirekten Übermittlung gibt es eine dezentralisierte Laufwegermittlung: jeder IMP muß selbst anhand der Zieladresse einer ankommenden Nachricht den richtigen Weg für ihre Weiterleitung bestimmen. Die Alternative ist die zentralisierte Laufwegermittlung, bei welcher ein zentraler Vermittlungsrechner für die korrekte Zustellung der Nachrichten verantwortlich ist. Tabelle 7.1-1 zeigt für jede dieser Übermittlungs- und Laufwegermittlungs-Strategien die wesentlichen Topologien mit den für den Netzentwurf wichtigsten Eigenschaften:

7. Netzstrukturen und Laufwege

114 e u g E :0 M 3 e HO« >. o -c e S b, A O 3 u G

"O c 3

73

.b z

-c « £ •s ^ •a


S Ë « â

_> c — o

, tu 00 _ e e 'S » « T3 .SP 6 J S .2 t í : o" S I43H XI

o B hi

00 B 3 -1

3 00 -

¿ Ó 3 Ife- 8« 9B V.I O S op « c ~ 7TI s 3 B M g> U S> u. s on

J

I

•i

i i i 1 11 1 1

^

J3 U 00 5 a

«

3 3S B u B

** §-e-g,g 1 -S o - C 'Ö 3 .5 ! 'SS ä w Ja 3 ün 1 ^

V D •JS t/) ~ Vi

S

K, L •u S - 53 g « 5-g J •S Z

1 -c

< D

3

1 3 1 53

;2

W

. c — « a s 3 a 3 O0J3 i ü

3 g s »

I

00 X « e « - i 2 Ö. c «3 «3 5 u Ofi 3 _, S J S 3 S 00

J2

>

3 ^ 0 -o _] E

>2

I K

g 5

^

^

„Distributed Computer System" der University of Californien, Irvine [FARB72]

mit Koaxialkabel als Bus innerhalb eines Werks ETHERNET (XEROX, Palo Alto) [METC76]

MERIT-System der Michigan University [BECH72]

ALOHA (mit Radio-Übermittlung) [BIND75]

einandergestimmt sein

Bus mit zentralem Vermittler

zentralisiert

START-Netz der DB, Lufthansa und TUI, Bildschirmtext-Netz der DBP

realisieren

oTn

icntliche Wählvcrmittlungsnetze

ÒÒÒÙ

passiver Bus

dezentralisiert

X

Knoten

vollständige Vermaschung

keines

kein realisiertes Netz bekannt

reguläres Netz

ARPA [LOGI74], CYCLADES [POUZ73]

irreguläres Netz

dezentralisiert

indirekt über Vermittler (mit Adreßtransformations- und/oder Laufwegermittlungsfunktionen)

1 55

Beispiel

Topologie

LaufwegermittlungsVerfahren

direkt zwischen Quelle und Ziel (ggf. mit passiver Zwischenspeicherung)

60 e 3 N

Übermittlungsstrategie

116 7. Netzstrukturen und Laufwege

7.2 Durchschaltungen, virtuelle Verbindungen und Datagramme

117

- Die Lokalisierungs-Modularität eines Netzes ist gut, wenn der Anschluß neuer, zusätzlicher Knotenrechner oder das Entfernen bestehender die bisherige Struktur des Netzes nicht wesentlich stört und damit keine nennenswerte Änderung der Netzsoftware notwendig macht. - Die Kosten-Modularität ist gut, wenn der Aufwand an Hardware, z. B. an zusätzlichen Leitungen, für den Anschluß eines neuen Knotens gering ist. - Die logische Komplexität eines Netzes ist gering, wenn jeder Knoten für die Weiterleitung einer Nachricht keine umfangreichen Algorithmen oder Tabellen zu Rate ziehen muß, und wenn die Verfahren und Programme zur Bearbeitung dieser Weiterleitung in allen Knoten des Netzes weitgehend identisch sind. - Engpcisse sind diejenigen physischen Bauelemente des Netzes (Leitungen oder Knotenrechner), deren Leistungsfähigkeit die Transportkapazität des Kommunikations-Subsystems begrenzt. - Das Fehler- und Rekonfigurationsverhalten eines Netzes ist gut, wenn der Ausfall eines Bauelements (Knotenrechner oder Leitung) die Kommunikation der übrigen Knoten möglichst wenig beeinflußt, und wenn die Netzsoftware sich einfach und sicher auf diese Störung einstellt.

7.2 Durchschaltungen, virtuelle Verbindungen und Datagramme Noch eine weitere Grundentscheidung muß der Entwerfer eines Netzes neben der Auswahl der Topologie treffen: Wie wird die logische Verbindung zwischen Quelle und Ziel physisch und softwaretechnisch realisiert? Drei Möglichkeiten stehen zur Wahl: - Die Durchschaltvermittlung (Circuit Switching) ist die „klassische" Methode, die von Telephon und Fernschreiber allgemein bekannt ist. Die Knoten im Netz versuchen, einen freien Leitungsweg zwischen den beiden Partnern zu finden, und belegen diesen dann ausschließlich für die eine Verbindung. - Bei der Nachrichtenvermittlung, der Übermittlung einzelner Datagramme (Datagrams) übergibt hingegen der Quellrechner die zu übermittelnde Nachricht mit Angabe der Empfängeradresse an das Netz, und dieses bemüht sich, sie zuzustellen. Ebenso wie in den Telegramm- oder Briefdiensten der Post wird jedes Datagramm als unabhängig von allen anderen zu übertragende Einheit aufgefaßt. Das Netz garantiert nicht die korrekte Übermittlung aller aufgegebenen Datagramme, und im besonderen gewährleistet es nicht die Beibehaltung ihrer zeitlichen Reihenfolge. Die Überprüfung der korrekten Zustellung und falls nötig - die Wiederherstellung der Absenderreihenfolge ist eine Aufgabe, die Quelle und Ziel selbst übernehmen müssen.

118

7. Netzstrukturen und Laufwege

- Die virtuelle Verbindung (Virtual Call) schließlich ist ein Kompromiß zwischen Durchschalt- und Nachrichtenvermittlung. Vom Standpunkt des Benutzers stellt das Netz eine stehende Verbindung her und liefert die gesendeten Nachrichten beim Ziel-Host vollständig und in der Reihenfolge der Eingabe ab. Intern jedoch transportiert es die Informationen des Senders in datagrammartigen, voneinander unabhängigen Blöcken, die meist Pakete genannt werden. Der wesentliche Nachteil der Durchschaltvermittlung ist die schlechte Ausnutzung der oft teuersten Betriebsmittel eines Netzes - der Leitungen und ihrer Anschlußhardware. Die dadurch schon intuitiv zu vermutende UnWirtschaftlichkeit wurde durch umfangreiche Kosten- und Leistungs-Studien für projektierte Netze (z. B. [ROSN76]) bestätigt. Moderne Datennetzkonzepte beruhen deshalb fast immer auf Datagrammen oder virtuellen Verbindungen, sofern nicht besondere Umstände (z. B. der Wunsch nach gleichzeitig möglicher Sprachübertragung über dasselbe Netz) eine Durchschaltvermittlung trotz der schlechteren Betriebsmittelausnutzung nahelegen. So schlugen etwa die im CCITT zusammengeschlossenen Postverwaltungen verschiedener Länder die X.25-Schnittstelle für öffentliche Datennetze als Norm vor, die vom virtuellen Verbindungs-Typ ist [SARB76]. Auch die meisten existierenden Netze unterstützen virtuelle Verbindungen, wobei die Bezeichnungen für diese Vermittlungsart unterschiedlich sind: - Connection (ARPA), - Liaison (CYCLADES, EIN), - Session (IBM SNA), - Logical Link (DECNET), - Virtual Call (X.25, EPSS Großbritannien), - Circuit Virtuel (TRANSPAC Frankreich), - Virtual Circuit (X.25, TELNET USA). Umstritten ist jedoch, ob ein Netz zusätzlich einen Datagramm-Dienst anbieten soll. ARPA, TRANSPAC und die ursprüngliche X.25-Schnittstelle tun dies nicht. Dagegen unterstützen CYCLADES (in Form des eingebetteten CIGALE-Protokolls), EIN, DECNET, EPSS und TELNET auch Datagramme. Nachträglich wurden auch in den X.25-Standard zwei Vorschläge zur Integration von Datagrammen eingefügt. Einer der stärksten Befürworter dieser Alternative ist Pouzin [POUZ75, POUZ76]. Seine Argumentation ist, daß netzintern zur Nachrichtenvermittlung ohnehin immer Pakete, d. h. Datagramme, benutzt werden. Die Unterstützung einer virtuellen Verbindung verlangt vom Netz zusätzliche Leistungen wie Aufbau und Abbau der Verbindung, Fehlerkontrolle und Folgesicherung. Andererseits

7.2 Durchschaltungen, virtuelle Verbindungen und Datagramme

119

gibt es aber durchaus Anwendungen, bei denen ein Teilnehmer einzelne Nachrichten ohne Rücksicht auf ihre Reihenfolge an einen Adressaten senden will, wie etwa - Übertragung von Sätzen aus einer direkt oder index-sequentiell organisierten Datei, - Übertragung unabhängiger Transaktionen, z. B. Buchungsvorgängen an Bankschaltern, an einen zentralen Prozessor, - Sammlung von Statistiken, - Aussenden kurzer Nachrichten an Terminals oder Benutzer, - Übertragung einer Datei an einen Sortier-Prozessor. In diesen Fällen bedeutet die Herstellung einer virtuellen Verbindung unnötigen Aufwand. Auch die globale Flußsteuerung ist in einem NachrichtenvermittlungsSystem, wie bereits in Abschnitt 6.5 diskutiert, einfacher. Außerdem bedingt die Übernahme der gesamten Fehlerkontrolle und -behebung durch das Netz vom Benutzer unbedingtes Vertrauen in seine Zuverlässigkeit. Wie Pouzin bemerkt, wird dieses angesichts der Tatsache, daß manche Postverwaltungen noch nicht einmal einen zuverlässigen Telefondienst bieten können, vor allem bei öffentlichen Netzen nicht immer vorhanden sein. Benutzer mit hohen Zuverlässigkeitsansprüchen werden deshalb die eigentlich vom Netz übernommenen Fehler- und Folgekontrollen sicherheitshalber ohnehin nochmals im Host-HostProtokoll durchführen.

7.3 Pakete Sowohl bei der virtuellen Verbindung als auch beim Datagramm übergibt der Quell-Host dem Kommunikations-Subsystem Nachrichtenblöcke und erwartet, daß sie unverfälscht einem bestimmten Empfänger zugestellt werden. Ihre Länge kann je nach der zu vermittelnden Informationsmenge und der internen Pufferlänge der Hosts zwischen wenigen und vielen tausend Bits schwanken. Derart stark streuende Anforderungsprofile sind in der Datenverarbeitung immer problematisch. Jeder Entwerfer eines Betriebssystems kennt den Zwiespalt: Benutzer mit kleinen Aufträgen erwarten mit Recht schnelle Bedienung, diejenigen mit umfangreichen nehmen zwar Verzögerungen in Kauf, verlangen aber - ebenfalls mit Recht - , daß ihre Jobs nach angemessener Wartezeit zügig zum Abschluß gebracht und nicht wegen Kurzläufern ständig weiter zurückgestellt werden. Die übliche Lösung dieses Problems ist die Aufteilung der gesamten Prozessorzeit in kurze Zeitscheiben einer vorgegebenen Maximallänge (in Timesharing-Systemen meist 10 bis 100 msec). Kurze Aufträge können in einer einzigen Zeitscheibe vollständig abgearbeitet werden. Längere werden in eine größere Zahl von Ab-

120

7. Netzstrukturen und Laufwege

schnitten aufgeteilt und unterbrochen, um die Kurzläufer nicht zu blockieren, andererseits aber auch nicht wegen ihrer Länge dauernd hinter ihnen zurückgestellt werden. Von Baratt [BARA69] und Davis [DAVI67] stammt die inzwischen allgemein akzeptierte und in den meisten neueren Rechnernetzen (ARPA, CYCLADES, EIN X.25 und vielen anderen) realisierte Idee, das Problem der unterschiedlichen Nachrichtenlängen ähnlich zu lösen: es werden relativ kurze Einheiten für den Informationstransport im Netz definiert, die Pakete genannt werden. Diese sind meist 500 bis 2000 bit lang. Längere Nachrichten (Datagramme) werden, wie Abb. 7.3-1 zeigt, am Eingangsport in das Kommunikations-Subsystem vom QuellIMP in Pakete fragmentiert. Diese werden unabhängig, unter Umständen auf verschiedenen Laufwegen, zum Ziel vermittelt und dort vom Ziel-IMP wieder reassembliert. Tabelle 7.3-2 stellt Durchschaltvermittlung, Nachrichtenvermittlung und Paketvermittlung mit ihren wichtigsten Eigenschaften einander gegenüber. Neben dem primären Ziel, in den Warteschlangen der IMPs kurze Nachrichten nicht durch lange zu blockieren, verringert die Aufteilung in Einzelpakete bei einer über mehrere IMPs hinweg führenden Übertragungsstrecke die Verzögerung einer Nachricht, da der jeweils nächste IMP mit der Weitervermittlung des ersten Pakets schon beginnen kann, bevor er die restlichen empfangen hat. Für eine Nachricht aus p Paketen der Länge l bit ist dann bei einer Übertragungsrate der Leitungen r bit/sec und z Teilstrecken zwischen Quell- und Ziel-IMP die Übertragungszeit für die Gesamtnachricht / t = —-(p

+

z-1).

Die nicht aufgeteilte Nachricht der Gesamtlänge / • p würde hingegen zur Übertragung die Zeit

erfordern. Dies ergibt für z > 1 und p > 1 einen größeren Wert. Freilich bringt eine Aufteilung der Nachrichten in Pakete auch einen Zusatzaufwand sowohl - wegen der Steuer- und Quittungsinformationen - in der Leitungsbelastung als auch - wegen Fragmentierung und Reassemblierung - in der Software. Der maximal erzielbare Durchsatz wird dadurch verringert: wieder ein Beispiel für das Gegenspiel zwischen Antwortzeit- und Durchsatzoptimierung. Dies ist auch der Grund, warum in der Regel eine Paketgröße von 1000 bit nicht unterschritten wird, obwohl Messungen an existierenden Netzen dies auf den ersten Blick nahelegen würden. Für das ARPA-Netz galten nach im August 1973 durchgeführten Messungen von Kleinrock und Naylor [KLEI74] folgende Werte:

121

7.3 Pakete maximale Nachrichtenlänge mittlere Nachrichtenlänge maximale Paketlänge mittlere Paketlänge mittlere Paketzahl/Nachricht

-

8063 bit, 243 bit, 1008 bit, 218 bit, 1,12.

Die weitaus meisten Nachrichten sind also Einzelpaket-Nachrichten von nur etwa einem viertel der maximalen Paketlänge. Kommunikations-Subsystem

Fragmentierung

Reassemblierung

Abb. 7.3-1 Fragmentierung und Reassemblierung von Nachrichten in Pakete Trotzdem kann man daraus nicht schließen, daß im Interesse einer besseren Pufferausnutzung in den IMPs die Wahl einer kleineren Paketlänge - etwa 250 bit, wie zuweilen vorgeschlagen - zu empfehlen ist. Kritisch für den Pufferbedarf in einem

122

7. Netzstrukturen und Laufwege

'GS De CO c £ 2 3 e« < Ö£ •§.s _ c t/5 dû Äu C S

£ C/O

60 5

3 «-wS c CO . 3c :0 M 00 Ü C •ca S J > 'CO 3 (S -C •2f• S 00 "e —"öos N è c3 O C g £M J

Oo ^ cd § .s z c •S3W JSw b s -a O

oo ;s

:cO C/J3 -4 c o V oc •3 N 2i §i- a o x a 1) c * S J3 J