MÜNCHEN (COMPUTERWOCHE) - Die Akzeptanz von Thin-Client-Architekturen etwa zur Anbindung von Außenstellen an die Unternehmens-IT lässt Anwender zu Microsofts Windows Terminal Server (WTS) und Citrix´ "Metaframe" greifen. Inzwischen gibt es aber auch schon eine Reihe von Klagen über WTS-Implementierungen. Frank Walther* beschreibt zwei der wesentlichen Defizite, an denen ganze Projekte scheitern können.
Der Weg vom "Thick Client" zum "Thin Client" ist aus Kosten- und Administrationsgründen prinzipiell sinnvoll. In jüngster Zeit mehren sich aber Meldungen über WTS-Projekte, die unter Störungen leiden. Es zeigt sich, dass unter ungünstigen Bedingungen ein kostspieliges Scheitern nicht ausgeschlossen werden kann.
In der traditionellen Client-Server-Welt laufen Applikationen wie Autocad, Lohnbuchhaltung oder Büropakete auf den Endgeräten der Benutzer. Dabei kann man davon ausgehen, dass kein Anwender das gesamte Spektrum aller in einem Unternehmen verwendeten Applikationen benutzt: Auf jedem Frontend ist also nur eine Teilmenge der Anwendungen installiert.
Bei der Migration zur WTS-Architektur werden alle Applikationen auf die Terminal-Server zusammengezogen. Im Idealfall hält jeder Terminal-Server 100 Prozent aller Applikationen vor, um ein vollständiges Load Balancing durchführen zu können. Damit ergibt sich jedoch ein ungleich höheres Konfliktpotenzial zwischen den Applikationen sowie mit den Softwaremodulen des Server-Betriebssystems, etwa den Kommunikations-Treibern (TCP/IP). Seuchenmediziner würden dazu sagen: Ein Keim, der zuvor nur auf kleinen Populationsinseln gelebt hat, kann sich jetzt ungehemmt verbreiten.
Dem Anwender präsentieren sich die Probleme in Form langer Antwortzeiten beziehungsweise scheinbar eingefrorener Bildschirme. Dies kann verschiedene Ursachen haben, im Fall von WTS spielen jedoch Konflikte auf dem Terminal-Server selbst eine erhebliche Rolle. Die Probleme werden deutlich, betrachtet man die Hürden, die Videoströme einer Terminal-Server-Applikation im Vergleich zu denen einer Stand-alone-Anwendung nehmen müssen. Hier nur zwei von vielen Beispielen: So verläuft der Datenstrom auf einem PC unidirektional und quittungsfrei, am Terminal-Server dagegen bidirektional mit Quittungsmechanismen. Außerdem sichern moderne PC-Architekturen einen nahezu verzögerungsfreien Signalfluss, während der Videostrom eines Terminal-Servers eine Vielzahl von Komponenten innerhalb des LAN oder WAN passieren muss.
Quittungen bremsen den Datenstrom aus
Ein Terminal-Konzept kann deshalb nur Aussicht auf Erfolg haben, wenn es die Charakteristik für Videoströme auf Stand-alone-Systemen so weit wie möglich erreicht. Im Prinzip bietet die LAN-WAN-Kommunikation via TCP/IP gute Voraussetzungen dafür. Doch die zum Teil völlig falsche Verwendung von TCP/IP führt zu einer der häufigsten Fehlerursachen. Der bei vielen WTS-Projekten vorprogrammierte Fehler besteht darin, dass einige Applikationen den TCP-Treiber gemäß ihren Bedürfnissen exakt ansteuern, während andere darauf verzichten und mit Default-Werten (Fremdwerten) arbeiten. Eine Applikation greift also auf einen TCP-Treiber zu, der mit anderen Werten konfiguriert ist, als vom Programmierer ursprünglich angenommen wurde.
Die Übertragung großer Datenmengen setzt voraus, dass der Server viele TCP-Pakete quittungsfrei senden kann und deshalb keine Wartezeiten entstehen. Genau das sehen die Default-Einstellungen Microsofts im TCP-Treiber vor, um eine möglichst verzögerungsfreie Arbeit zu gewährleisten. Jede Applikation kann nun aber den TCP-Treiber anweisen, auf Einzelquittungsbetrieb umzustellen, also wieder im "Ping-Pong"-Verfahren zu arbeiten. Arbeitet eine Applikation nach diesem Prinzip, werden die Daten der anderen Applikationen ebenfalls im Einzelquittungsbetrieb versendet, auch wenn diese von Microsofts Default-Einstellungen der TCP-Parameter ausgehen. Ab diesem Moment ist auf allen Client-Server-Verbindungen "warten" angesagt, weil der erforderliche beziehungsweise gewohnte Datendurchsatz nicht mehr erreicht wird.
Darüber hinaus zwingen manche Applikationen wie 3270-SNA-Emulationen den TCP-Treiber zum Einzelquittungsbetrieb. Ein Beispiel ist der "Personal Communicator" von IBM. Ein solches Verhalten ist vollkommen korrekt, allerdings gelten die SNA-Einstellungen des TCP-Treibers dann auch für alle anderen Applikationen des Rechners, sofern Programmierer auf eine eigene Parametrisierung verzichtet haben.
Auf die Antwortzeiten hat das katastrophale Auswirkungen. Der Server wird die in seinem Ausgangspuffer bereits vorliegenden Videodaten nicht los, weil er auf ein vielfach größeres Volumen an Quittungen zu warten hat. Liegt zwischen Terminal-Server und Terminal-Client ein WAN, das nicht mit LAN-Geschwindigkeit arbeitet, summiert sich die Laufzeit hin und zurück (Round Trip Delay) jeder einzelnen Quittung massiv. Es wurde nachgewiesen, dass die durch den Ping-Pong-Quittungs-Mechanismus erzeugten Sendestaus der Server unter WAN-Bedingungen eine um das Tausendfache erhöhte Antwortzeit erzeugen können. Anders ausgedrückt: Ein Vorgang, der auf dem Bildschirm eines Stand-alone-PCs im Sekundenbereich abläuft, dauert im Ping-Pong-WTS-Verkehr Stunden.
Tritt dies ein, ist das WTS-Projekt in seiner gegebenen Form nicht mehr haltbar. Dramatisch spitzt sich die Situation zu, wenn sich eine WTS-Umgebung bereits über Jahre bewährt hat und die Konflikte erst mit dem Update einer Applikation oder des Betriebssystems auftreten. Die Erfahrung mit mehreren Anwendern hat gezeigt, dass sich sowohl Microsoft als auch Citrix als vollkommen unfähig beziehungsweise unwillig erwiesen haben, die Probleme im Bereich der TCP-Treiber abzustellen.
Im Herbst 1999 wurde ein ausführlicher Nachweis dieses Problems an die Softwareentwickler von Citrix geschickt - bis heute gibt es darauf keine Reaktion. Ein Hinweis könnte allerdings sein, dass die vom Hersteller zur CeBIT 2000 angekündigte neue Version von Metaframe nicht auf den Markt gebracht wurde, was einer Bankrotterklärung gleichkäme. Dass auch Microsoft seit Monaten hierzu schweigt, darf inzwischen als Hinweis in dieselbe Richtung gedeutet werden.
Bilschirm-Refresh: Eine "unendliche Geschichte"
Es gibt aber noch ein weiteres Problem, das WTS-Projekte unter Umständen zum Scheitern verurteilt: die Bildschirm-Ansteuerung beziehungsweise das massive Auslösen von Refresh-Ereignissen innerhalb einer Applikation. Hintergrund ist der, dass Programmierer den Neuaufbau der Oberfläche vorschreiben, und das völlig unabhängig davon, ob sich am Bildschirminhalt etwas geändert hat oder nicht.
Das Horrorszenario sieht dann so aus: Die Applikation betreibt eine zyklische Verarbeitung von Daten oder Darstellungselementen. Anstatt jedoch erst alle Änderungen durchzurechnen und am Ende ein einziges Mal den neuen Inhalt als Gesamtergebnis auf den Bildschirm zu bringen, wird bei jedem Durchgang eines Zyklus (Schleife, Loop) die Darstellung der Teilergebnisse veranlasst. Das Ergebnis: Auf teilweise Tausende von Subroutinen entfallen ebenso viele Bildschirm-Refresh-Ereignisse. Die Folge ist ein extrem steigendes Datenvolumen - aus einem Videostream wird ein Videostorm.
Citrix bietet zwar Features, mit denen nur die veränderten Bildschirmanteile erfasst beziehungsweise gesendet werden und außerdem die Übertragung stark komprimiert erfolgt. Betreffen die Veränderungen jedoch den gesamten Bildschirm anstatt nur kleine Bereiche daraus, hilft auch das nichts mehr. Es wurden Fälle beobachtet, bei denen Screen-Refreshs das Datenaufkommen derart auftürmten, dass den Anwendern nach fünf bis fünfzehn Minuten Wartezeit der Geduldsfaden riss und sie den Rechner ausgeschaltet haben.
Sollte bei diesem Szenario zusätzlich TCP im Ping-Pong-Dialog arbeitet, kann man gleich abschalten - gerade unter WAN-Bedingungen ist warten dann zwecklos. Im schlimmsten Fall, so wurde in einer WTS-Umgebung festgestellt, war ein Vorgang, dessen Durchlauf normalerweise wenige Sekunden gedauert hätte, nach sechs Stunden erst zu rund 20 Prozent erledigt.
Eine mit diesem Problemen unmittelbar verbundene Applikation ist Microsofts "Excel". Jeder WTS-Anwender, der mit dem Spreadsheet arbeitet, kennt die Verzögerung beim Scrollen eines vollen Tabellenblatts. Dieses Warten hat mit dem extrem hohen Maß an Videorefreshs zu tun, die nach der Berechnung von Tabellenzellen ausgelöst werden. Dadurch zwingt ein simpler Programmierfehler des Herstellers (Microsoft) das WTS-System in die Knie. Wenn derselbe Hersteller den Windows Terminal Server nicht immer wieder auf die richtigen TCP-Parameter zurücksetzt, steht der Kunde vor der bizarren Situation, viel Geld in das Produkt eines Hauses investiert zu haben, aus dieser Sackgasse aber nur noch unter erheblichem Einsatz von Finanzmitteln und Zeit wieder herauszukommen.
Die Lösung dieser Probleme dürfte noch in weiter Zukunft liegen. Microsoft scheint bei der WTS-Entwicklung wichtige Teilbereiche der NT-Server-Technik nicht weit genug durchdacht zu haben - oder der ewige Zwang zur Abwärtskompatibilität hat die Änderungen behindert. So ist die Frage zu stellen, ob möglicherweise erst eine grundlegende Änderung der Treibertechnik die notwendige Zuverlässigkeit bringen könnte. Die TCP/IP-Treiber bei Windows NT gelten als "single threaded", alle Applikationen teilen sich also den selben Treiberstapel. Erst wenn für jede Applikation eine Treiberkopie zur Verfügung steht, dürfte der weitgehend konfliktfreie Zugriff auf das Netzwerk möglich sein.
Einschränkend gilt aber auch hier, dass die Ausgangspuffer des LAN-Adapters nicht mit den sinnlosen Videodaten eines Refresh-Storms gefüllt werden dürfen. Entsprechend ist die Applikationsentwicklung gefordert. Eine Änderung ist allerdings kaum in Sicht. Programmierer müssen warten, bis ihre verschiedenen Software Developer Kits die neuen Funktionen beziehungsweise WTS-APIs enthalten, um überhaupt in diese Richtung arbeiten zu können. Damit ist es völlig illusorisch, von einer schnellen Verbesserung der WTS-Szene auszugehen.
*Frank Walther ist Inhaber der Firma Synapse Networks, Bonn. Bei diesem Bericht handelt es sich um eine gekürzte Fassung des Vortrags, den Walther am 5. Juni auf dem Windows NT Forum, einer Veranstaltung der NT User Group, in Heidelberg halten wird.