Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

22.11.1985 - 

Nicht immer ist der Protokollkonverter die richtige Lösung:

Der Datenstationskonverter als Alternative

Die Bezeichnung Protokollkonverter wird auf Geräte mit unterschiedlichen Eigenschaften angewandt; auch auf Geräte, die keine eigentlichen Protokollkonverter sind. Die Ungenauigkeit dieses Begriffs birgt Gefahren für den Anwender, vor allem weil viele Konvertierungsprobleme nicht mit "klassischen" Protokollkonvertern gelöst werden können, sondern einen Datenstationskonverter erfordern.

Einige Beispiele von Konvertierungsfunktionen, die zum Teil unter der Bezeichnung Protokollkonverter angeboten werden, zeigen die Probleme bei der Begriffsbestimmung:

- SDLC/SNA - X.25-LLC/SNA ist ein klassischer Protokollkonverter.

- 3270/SNA - asynchron; diese Geräte werden Protokollkonverter genannt, sind aber Emulatoren.

- 3287/Koax - asynchroner ASCII-Drucker, wird ebenfalls als Protokollkonverter bezeichnet, ist aber auch ein Emulator.

In diesem und dem vorherigen Beispiel wird zweifellos auch eine Konvertierung durchgeführt, zusammen mit dem Endgerät bildet der Konverter aber einen Emulator; da das Endgerät außer seiner Eigenschaft als Ein-/Ausgabegerät keine Funktionen der Emulation übernimmt, ist die Bezeichnung Emulator wohl zutreffender.

- PC mit 3270/SNA-Adapterkarte und Emulationssoftware: Das ist bestimmt eine Emulation.

- 3780 (BSC) - 3776 (SNA) ist ein Datenstationskonverter.

- Teletex - internes Protokoll (Teletexbox) hat Merkmale einer Emulation, ist aber vorrangig ein Datenstationskonverter.

Diese Beispiele zeigen, daß die Grenzen zwischen den Begriffen Protokollkonverter, Emulator und Datenstationskonverter fließend sind. Es gibt aber einige Unterscheidungskriterien:

Ein Protokollkonverter konvertiert die unteren Protokollschichten, also ISO-Level 1,2 und eventuell 3. Die höheren Schichten bleiben unberührt. Eine Ausnahme hiervon kann eine Code-Konvertierung, zum Beispiel EBCDIC-ASCII, sein, die aber nur bei einfachen Protokollen möglich ist und nicht in die Datendarstellung eingreift.

Die Arbeitsweise eines Protokollkonverters ist in Abbildung 1 anhand des ISO-7-Schichtenmodells dargestellt.

Ein Emulator kann Konvertierungsfunktionen durchführen. Wie oben ausgeführt, ist die Emulation aber fast vollständig in dem Emulator implementiert; in den Peripherie-Geräten wird nur wenig Intelligenz benötigt.

Ein Datenstationskonverter konvertiert im Unterschied zum Protokollkonverter auch die höheren Protokollschichten bis OSI-Level 5 oder 6. Unter Umständen bleibt "nur" die Anwendung erhalten. Im Unterschied zum Emulator erfordert das Ausgabeprotokoll eine intelligente Verarbeitung. Zusammen mit dem Zielrechner bildet der Datenstationskonverter einen Emulator, aber wesentliche Teile dieser Emulation werden vom Zielrechner übernommen Die Arbeitsweise eines Datenstationskonverters ist in Abbildung anhand des ISO-7-Schichten-Modells dargestellt.

Wie bereits in den obigen Beispielen gezeigt wurde, gibt es zwei Varianten:

1. Konvertierung einer Standard-Station auf eine andere Standard-Station.

2. Konvertierung einer Standard-Station auf ein internes Nicht-Standard-Protokoll.

Variante 1 ermöglicht den Anschluß einer Station oder Emulation an "nicht passende" Netze ohne Eingriffe am Zielsystem und kann beispielsweise den Übergang von BSC nach SNA ermöglichen. Neben dem obengenannten Beispiel gibt es viele weitere Möglichkeiten, wie etwa:

- 3270/BSC - 3270/SNA/SDLC oder X.25-LLC: Hier bleibt die Datendarstellung unberührt, aber bis einschließlich der Kommunikationssteuerung müssen alle Ebenen konvertiert werden.

- IBM 3780 - Siemens 8418: Obwohl beides Bisync-Batch-Stationen sind, sind in allen Schichten Konvertierungen erforderlich.

Bei dieser Variante 1 der Datenstationskonvertierung sind kleinere Einbußen in der Funktionalität nicht zu vermeiden, da die zu konvertierenden Stationen im allgemeinen nicht 100 Prozent kompatibel sind und der Konverter im allgemeinen nur die gemeinsamen Funktionen umsetzen kann.

Variante 2 bildet das meistens komplexe Datenstationsprotokoll auf ein erheblich einfacheres ab. Das sollte natürlich ohne Funktionsverlust geschehen!

Vorteile dieser Variante gegenüber der direkten Emulation auf dem Zielsystem sind zum Beispiel:

- geringere Belastung des Zielsystems durch einfaches Protokoll-Handling;

- schnellere Implementation der Emulation durch Adaption eines fertigen Datenstationskonverters;

- es sind keine oder nur geringe Hardwareänderungen auf dem Zielsystem erforderlich, da kein neuer Front-End-Prozessor eingesetzt werden muß.

Ein weiteres Beispiel für diese Variante neben dem obengenannten (Teletexbox) ist die Konvertierung der IBM 3777 auf ein internes Protokoll.

Wie bereits bemerkt, sollte der Funktionsumfang durch die Konvertierung nicht zu stark eingeschränkt werden. Erhebliche Einschränkungen können erforderlich sein, wenn

die zu konvertierenden Stationen sehr unterschiedlich sind, dann ist die Konvertierung eventuell gar nicht sinnvoll.

Entscheidungskriterien für den Einsatz

Vor allem bei Filetransfer-Stationen muß die End-to-End-Kontrolle gesichert sein, andernfalls kann die Übertragung zu einem Glücksspiel werden; Bei Konvertierungen von SNA nach BSC muß der Anwender wissen, daß BSC nicht die Übertragungssicherheit von SNA bietet!

Eine Verlängerung der Reaktionszeit durch Einschaltung einer zusätzlichen Instanz, des Konverters, muß einkalkuliert werden. Bei Filetransfer-Anwendungen wird dieser Punkt eine geringe Rolle spielen, denn der Durchsatz muß durch einen Datenstationskonverter nicht beeinträchtigt werden. Für Dialog-Anwendungen sind Verlängerungen der Antwortzeiten zu erwarten; das Ausmaß dieser Verlängerung hängt auch von der Implementation des Datenstationskonverters ab!

Warum kein Protokollkonverter? Ganz einfach, weil er die Aufgaben eines Datenstationskonverters nicht erfüllen kann, da vom Protokollkonverter die höheren Protokollschichten unverändert übergeben werden und im Zielsystem verarbeitet werden müssen.

*Rolf Wildhack ist Kommunikationsberater bei der Stollmann GmbH, Hamburg.