Wer heute im engeren oder weiteren Sinne mit Datenfernverarbeitung zu tun hat, stößt immer wieder auf den Begriff "Protokolle". Was sind eigentlich Protokolle, von denen man zuweilen weiß, daß sie irgendetwas mit Computerkommunikation zu tun haben? Bernward Jopen, Geschäftsführer der Münchner Telenet GmbH, zeigt in seinem Artikel am Beispiel Bildschirmtext einige Besonderheiten der Softwaresparte auf, die sich mit Protokollentwicklungen befaßt, und versucht eine Erklärung dafür zu geben, warum diese im Vergleich zu anderen Entwicklungen oft sehr viel aufwendiger sind.

Datenfernverarbeitungs-Protokolle sind, ähnlich wie früher Protokolle bei Hofe, Verhaltensvorschriften und zwar zwischen Datenverarbeitungskomponenten, die untereinander Informationen austauschen wollen. Je nach Art des Protokolls gehören hierzu

- Vereinbarungen über die Berechtigung, eine Kommunikation aufzubauen,

- Vorschriften, wie eine Nachfrage zu formulieren ist, mit der ein entfernter Rechner feststellen kann, ob der Partner Daten abrufbereit hält oder auch

- Regeln für die Durchsetzung der etwas massiven Aufforderung, ab sofort keine weiteren Daten mehr zu senden und die Verbindung abzubauen. Auf den menschlichen Bereich bezogen heißt das: Abbruch der diplomatischen Beziehungen!

Protokoll-Hierarchie

So wie es bei Hofe für jede Ebene innerhalb der Hierarchie ein bestimmtes Protokoll gab, so gibt es in der Computerkommunikation definierte Ebenen, die sich über bestimmte Protokolle miteinander verständigen. Aufgabe dieser hierarchisch strukturierten Protokolle ist es, einen Datenaustausch zwischen Kommunikationssystemen nach einem einheitlichen Standard zu ermöglichen, ohne daß die verschiedenen DV-Hersteller in einem solchen Kommunikationssystem individuelle Absprachen treffen müssen. Das seit rund vier Jahren zu diesem Zweck festgelegte Protokollkonzept, das ISO-Architekturmodell, enthält sieben Ebenen.

In Tabelle 1 sind die Aufgaben dieser Ebenen einmal Kommunikationsmöglichkeiten aus unserer menschlichen Sphäre gegenübergestellt. Die Protokolle für den Btx-Rechnerverbund in der Bundesrepublik Deutschland orientieren sich an diesem Architekturmodell.

Die Bildschirmtext-Protokolle

Um einige Problemkreise besser zu verdeutlichen, die bei der Realisierung von Kommunikationsprotokollen entstehen können, sind im folgenden Abschnitt die Erfahrungen aus einem Btx-Rechnerverbundprojekt einmal den Erfahrungen aus der Entwicklung von Batch-Programmen gegenübergestellt.

Zunächst ein paar einleitende Bemerkungen zu den im Bildschirmtext-Rechnerverbund verwendeten Protokollen EHKP4 und EHKP6: Die vom Bundesministerium herausgegebene EHKP4-Spezifikation (zur Einordnung von EHKP4 siehe Tabelle 1) enthielt eine Reihe von Interpretationsspielräumen, die zwischen der Deutschen Bundespost, der IBM Deutschland - dem Lieferanten der Bildschirmtext-Vermittlungsstellen - und den Firmen, die Software für den Anschluß externer Rechner entwickeln, bis Anfang des Jahres 1983 geklärt werden mußten.

Für einen Außenstehenden ist es oft nicht erklärlich , wieso Spezifikationen, die quasi Normungscharakter haben, noch Freiräume für Interpretationen enthalten. Zum einen hängt dies damit zusammen, daß sich die für, Normung zuständigen Gremien ungern "in die Niederungen von Implementierungsfragen" begeben und zum anderen, daß einige Fragen erst in einem konkreten Projekt offenbar werden. Als stabilisierend für die EHKP4-Entwicklung erwies sich, daß ein Vorläufer von EHKP4 bereits seit längerer Zeit in einem großen Rechnerverbundnetz des Landesamtes für Datenverarbeitung und Statistik Nordrhein-Westfalen eingesetzt war.

Anders bei EKKP6, das erstmalig im Btx-Rechnerverbund Verwendung fand. Hier waren die Interpretationsspielräume wesentlich größer. Während das Btx-Projekt bereits auf vollen Touren lief, wurde noch an der endgültigen Spezifikation gearbeitet. Dieser Umstand hat die Entwicklungsarbeit nicht gerade gefördert. Erst gegen Mitte des Jahres , 1983 konnte hier eine - nicht für alle Beteiligten zufriedenstellende Lösung gefunden werden.

Was macht die Entwicklung dieser Kommunikationssoftware im Vergleich zu Batch-Programmen schwierig? Zunächst ist festzustellen, daß die Komplexität der Ablauflogik dazu geführt hat, daß man bessere Implementierungsverfahren ersonnen hat: Man codiert die Protokoll-Logik nicht mehr mit Hilfe von Vergleichs- und Verzweigungsbefehlen, sondern definiert Tabellen, die das gesamte Protokoll in komprimierter Form enthält.

Diese Tabellen können dann maschinell abgearbeitet werden. Die jeweils notwendigen Verarbeitungsschritte werden von meist nur kurzen Aktionsroutinen abgearbeitet. Hier läßt sich schon ein wesentlicher Unterschied zu Batch-Programmen erkennen: Kommunikationssoftware besteht aus komplexen Logik und kurzen Programmteilen, Batch-Programme dagegen enthalten in der Regel einfachere, sequentielle Logik verbunden mit längeren Programmen. Protokollimplementierungen werden außerdem dadurch komplex, daß sie eine Vielzahl von Kommunikationsbeziehungen gleichzeitig kontrollieren und dabei Zeitbedingungen einhalten müssen.

Ein weiterer wichtiger Unterschied zu Batch-Programmen ist der Code, der "im Geradeaus-Fall" durchlaufen wird, im Vergleich zur Codemenge, die nur in Fehler- oder Ausnahmefällen angesprochen wird. Aktuelle Implementierungen bei Telenet zeigen, daß dieses Verhältnis bei einer ausgereiften Protokollimplementierung 1:9 beträgt, das heißt, nur zehn Prozent des Gesamtcodes wird im Geradeaus-Fall durchlaufen. Bei durchschnittlich verarbeitungsintensiven Batch-Programmen ist eher ein umgekehrtes Verhältnis zu erwarten. Bild 1 zeigt ein einfaches Diagramm zur Beschreibung von Kommunikationsprotokollen, in dem der Geradeaus-Weg gut zu erkennen ist.

Stabilität bei Fehlersituationen

Der Grund für ein derartiges "Mißverständnis" bei Kommunikationssoftware: Kommunikationssoftware muß in vielen Fällen gleichzeitig mehrere Benutzerprogramme und Datenverarbeitungsverbindungen unterstützen, und das häufig unter widrigen Umweltbedingungen. Oberstes Ziel muß zunächst sein, den Betrieb aufrechtzuerhalten und allenfalls Störfaktoren zu isolieren. Stärungen, die auf einer Kommunikationsverbindung erkannt werden, dürfen die Stabilität der anderen Verbindungen keinesfalls beeinträchtigen.

Wegen des hohen Codeanteils für Fehler- und Ausnahmebedingungen ist dem Test von Kommunikationsprotokollen besondere Bedeutung beizumessen. Hinzu kommt, das Fehler- und Ausnahmebedingungen mit Hilfe von Simulations- und Testprogrammen im allgemeinen schwer zu erzeugen sind. Dies führt dazu, daß dieser Punkt auch bei der Systemabnahme häufig vernachlässigt wird und der eigentliche Test erst in der rauhen Wirklichkeit beim Anwender erfolgt. Infolgedessen sind Akzeptanzprobleme beim Anwender, aber auch ein hoher Fehlerbeseitigungsaufwand beim Ersteller fast zwangsläufig.

Dies kann sich zusätzlich durch eine aufwendige Fehlereinkreisung in komplexen Systemen erhöhen. Ständige Nachbesserungen von Systemen, die man " vom Anwender hat austesten lassen", sind im übrigen meist teurer als ein auf den ersten Blick kostspieligerer Entwurf einer soliden Implementierung, bei dem die Abwicklung ausgefeilter Tests bereits eingeplant ist.

Die Randbedingungen bei der Entwicklung von Kommunikationssoftware sind offenbar komplex. Dies gilt insbesondere dann, wenn sich bei der Entwicklung eines Kommunikationssystems von der Dimension des Btx-Projekts die Bundespost, IBM und die am Rechnerverbund beteiligten Hersteller unter großem Zeitdruck über Spezifikationsfragen einigen müssen.

Ebene 1

Vereinbarungen über elektrische Eigenschaften (Signalpegel) und Steckerbelegungen, zum Beispiel V24, X21

... bezogen auf menschliche Kommunikation:

Festlegung, wie man miteinander Informationen austauscht: Brief, Telefon, etc.

Ebene 2

Ebene der sogenannten Leistungsprozeduren für eine abschnittsweise gesicherte Datenübertragung: BSC, MVS, SDLC, HDLC. Enthält Basisvereinbarungen für einen Datenaustausch: zum Beispiel Aufforderung, Daten oder eine Quittung zu senden

... bezogen auf menschliche Kommunikation: Kopfnicken, Bestätigung

Ebene 3

Die bekannteste Netzwerkebene ist die Paketvermittlungsebene: in der Bundesrepublik Deutschland das DATEX-P Netz. Das DATEX-P Netz ermöglicht seinen Benutzern, Datenpakete zu Versenden - zur Verfügung, Datenpakete dem richtigen Empfänger zuzustellen - vergleichbar mit einem normalen Paketzustelldienst. Da bei einigen Fehlerfällen auf der Netzwerkebene allerdings auf einmal Datenpakete verloren gehen können, ist die Ebene 4 erforderlich.

... bezogen auf menschliche Kommunikation: Austausch von Informationen in gebündelter Form: Brief, Paket

Ebene 4

Eine im nationalen Rahmen bekannte Transportebene wird durch die im Btx-Rechnerverbund verwendeten Einheitlichen Höheren Kommunikationsprotokolle der Ebene 4 (EKKP4) realisiert. Generelle Aufgabe dieser Ebene ist es, einen auf der Paketvermittlungsebene möglichen Datenverlust durch geeignete Maßnahmen zu kompensieren und seinen Nutzern eine komfortable Schnittstelle zum Transportmedium zur Verfügung zu stellen.

... bezogen auf menschliche Kommunikation: Einschreiben mit Rockschein

Ebene 5

Die Aufgaben der Sitzungsebene werden manchmal - wie im Btx-Rechnerverbund - von höheren Ebenen wahrgenommen: Aufbau, Verwaltung und Abbau von logischen Verbindungen zwischen Programmen in verschiedenen Rechnern, einschließlich Synchronisations- und Restartmöglichkeiten. Ein derzeit nur auf dem Papier definierter Vertreter dieser Ebene ist EHKP5.

... bezogen auf menschliche Kommunikation: abgeschlossener Briefwechsel zu einem bestimmten Thema

Ebene 6

Die Präsentationsebene ermöglicht eine einheitliche Datendarstellung sowie eine Strukturierung der Information. Bekannt durch den Bildschirmtext-Rechnerverbund sind die Einheitlichen Höheren Kommunikationsprotokolle der Ebene 6 (EHKP6).

... bezogen auf menschliche Kommunikation: Einigung auf eine bestimmte Sprache, in der am miteinander korrespondieren will

Ebene 7

Auf der Anwendungsebene sind schließlich die Anwendungs-Steuerungsfunktionen und die eigentlichen Anwendungsprogramme angesiedet. Es ist nicht auszuschließen, daß sich die unteren 6 Ebenen aus der Sicht der Anwendungsprogramme als gewaltiger Wasserkopf präsentieren (!).

... bezogen auf menschliche Kommunikation: Inhalt des Briefes (na endlich!)