DE60109602T2

DE60109602T2 - Verfahren und vorrichtung zur effizienten verringerung von graphischen anzeigedaten für ihre übertragung mittels eines übertragungsprotokolls für niedrige bandbreiten

Info

Publication number: DE60109602T2
Application number: DE60109602T
Authority: DE
Inventors: Paul Coleman; Ruiguo Yang; Henry Collins
Original assignee: Citrix Systems Inc
Current assignee: Citrix Systems Inc
Priority date: 2000-05-26
Filing date: 2001-05-29
Publication date: 2006-04-27
Anticipated expiration: 2021-05-30
Also published as: WO2001092973A3; DE60109631T2; JP2004501445A; KR20030031903A; ES2246432T3; US20020073061A1; HK1049415A1; EP1285517A2; US20030046432A1; KR100824120B1; US8099389B2; US7127525B2; CA2408924A1; KR20070086443A; EP1285517B1; US20100205246A1; US7490166B2; US20090144292A1; ES2246433T3; HK1049415B

Description

TECHNISCHES GEBIET
Die vorliegende Erfindung betrifft allgemein die Kommunikation zwischen einem Anwendungsserver und einem Thin-Client in einem verteilten System und insbesondere die Reduktion der Menge an über einen Transportprotokollmechanismus mit niedriger Bandbreite übertragenen graphischen Anzeigedaten.
ALLGEMEINER STAND DER TECHNIK
Verteilte Computersysteme verwenden die Technik des Verteilens der Anwendungsausführung. Genauer gesagt führt ein Anwendungsserver lokal ein Anwendungsprogramm aus und liefert die Anwendungsausgangsdaten an Client/Netzwerkbenutzer, die die Ergebnisse dann auf einem an ihren lokalen Computer angekoppelten Anzeigeschirm anzeigen. Durch Durchführen der Anwendungsverarbeitungsfunktionen im Server und Anzeigen der Anwendungsausgabe im Client nutzen diese verteilten Systeme Server- und Clientbetriebsmittel am besten aus, d.h. der fähigere Server führt die rechen- und speicherintensiven Anwendungsverarbeitungsfunktionen aus, während der Client mit einer potentiell größeren Videoleistungsfähigkeit die Ausgabe anzeigt. Während der Ausführung des Anwendungsprogramms betrachtet ein Benutzer des Client die Anwendungsausgangsdaten auf der Anzeige des Client und tritt über Tastatur- oder Mauseingaben mit dem Anwendungsprogramm in Dialog. Die Eingaben des Client-Benutzers entsprechen Anforderungen für den Anwendungsserver, bestimmte Aktionen auszuführen, die sich auf die Funktionsweise des Anwendungsprogramms auswirken. Der Anwendungsserver leitet diese Anforderungen zur weiteren Verarbeitung an die Anwendung weiter. Außerdem fängt der Anwendungsserver die Anwendungsausgangsdaten ab, die durch das Anwendungsprogramm erzeugt und typischerweise auf das Betriebssystem des Anwendungsservers abgezielt sind, und sendet alle Daten oder einen Teil davon zur Anzeige zu dem Client. Vom Standpunkt des Benutzers aus gesehen wird das Anwendungsprogramm scheinbar lokal ausgeführt, obwohl es tatsächlich auf einem abgesetzten Server ausgeführt und einfach nur lokal angezeigt wird.
Die Leistungsfähigkeit verteilter Systeme hängt zu einem großen Grad von der Fähigkeit des Netzwerks ab, das Client und Server koppelt, und deshalb von der Menge an graphischen Daten (entsprechend den Anwendungsausgangsdaten), die über das Netzwerk übertragen wird. Da der Anwendungsserver und die Client-Workstation im allgemeinen nur durch einen Transportmechanismus (wie zum Beispiel serielle Leitungen, Telefonleitungen, lokale Netzwerke und großflächige Netzwerke) verbunden werden, der eine niedrigere Bandbreite besitzt, als anderweitig verfügbar wäre, falls das Anwendungsprogramm lokal ausgeführt werden würde, kann die wahrgenommene Leistungsfähigkeit des verteilten Systems beeinträchtigt werden. Folglich versuchen Hersteller von verteilten Systemen/Software fortwährend, die Leistungsfähigkeit solcher Systeme zu verbessern.
Das US-Patent 5 864 711 beschreibt ein System mit den Merkmalen des Oberbegriffs von Anspruch 1 und Anspruch 19.
KURZE DARSTELLUNG DER ERFINDUNG
Gemäß der Erfindung wird ein Verfahren zum effizienten Verringern der Menge an sich wiederholenden graphischen Daten, die zu einer abgesetzten Anzeigeeinrichtung übertragen werden, bereitgestellt, wobei das Verfahren die folgenden Schritte umfaßt: Durchsuchen einer Tabelle nach einem Index, der einem graphischen Datenelement zugeordnet ist, wobei die Anwesenheit des Index in der Tabelle eine vorherige Übertragung des graphischen Datenelements anzeigt; dadurch gekennzeichnet, daß das Verfahren weiterhin die folgenden Schritte umfaßt: wenn der Index nicht in der Tabelle gefunden werden kann, Durchsuchen einer Fuzzy-Datenbank nach einem dem graphischen Datenelement zugeordneten Fuzzy-Schlüssel, wobei die Anwesenheit des Fuzzy-Schlüssels in der Fuzzy-Datenbank eine Wahrscheinlichkeit anzeigt, daß das graphische Datenelement in einem an die abgesetzte Anzeigeeinrichtung angekoppelten persistenten Speicher gespeichert ist; und wenn der Fuzzy-Schlüssel gefunden wird, Übertragen des Fuzzy-Schlüssels zu einem dem persistenten Speicher und der abgesetzten Anzeigeeinrichtung zugeordneten Agent.
Gemäß einem weiteren Aspekt der Erfindung wird außerdem ein System zum effizienten Verringern der Menge an sich wiederholenden graphischen Daten, die zu einer abgesetzten Anzeigeeinrichtung übertragen werden bereitgestellt, wobei das System folgendes umfaßt: eine Tabelle, die einen Index speichert, der einem graphischen Datenelement zugeordnet ist, wobei die Anwesenheit des Index in der Tabelle eine vorherige Übertragung des graphischen Datenelements anzeigt; dadurch gekennzeichnet, daß das System weiterhin folgendes umfaßt: eine Fuzzy-Datenbank, die einen dem graphischen Datenelement zugeordneten Fuzzy-Schlüssel speichert, wobei die Anwesenheit des Fuzzy-Schlüssels in der Fuzzy-Datenbank eine Wahrscheinlichkeit anzeigt, daß die graphischen Daten in einem an die abgesetzte Anzeigeeinrichtung angekoppelten persistenten Speicher gespeichert sind; und einen Server-Agent, der im Betrieb dafür ausgelegt ist, die Fuzzy-Datenbank nach dem Fuzzy-Schlüssel zu durchsuchen, wenn der Index nicht in der Tabelle gefunden werden kann und, wenn der Fuzzy-Schlüssel gefunden wird, den Fuzzy-Schlüssel zu einem dem persistenten Speicher und der abgesetzten Anzeigeeinrichtung zugeordneten Client-Agent zu übertragen.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die obige Besprechung wird aus der folgenden ausführlichen Beschreibung der Erfindung in Verbindung mit den beigefügten Zeichnungen besser verständlich. Es zeigen:
1 schematisch einen über ein Kommunikationsnetz an einen Server-Knoten angekoppelten Client-Knoten, wobei Client- und Server-Knoten jeweils jeweilige Client- und Server-Agents aufweisen, die gemäß einer Ausführungsform der vorliegenden Erfindung wirken;
2 ein Flußdiagramm auf hoher Ebene der durch den Server-Agent von 1 durchgeführten Schritte gemäß einer Ausführungsform der vorliegenden Erfindung;
3 ein im Vergleich zu dem Diagramm von 2 ausführlicheres Flußdiagramm gemäß einer Ausführungsform der vorliegenden Erfindung;
4 schematisch den Inhalt des flüchtigen und persistenten Speichers von Client und Server, so wie er durch Operationen der Client- und Serveragents von 1 beeinflußt wird, gemäß einer Ausführungsform der vorliegenden Erfindung;
5 ein Flußdiagramm der Schritte zur Minimierung der Menge an zu dem Client übertragenen Daten durch Verwendung von Cache-Techniken unter Beteiligung einer Fuzzy-Datenbank und von Fuzzy-Schlüsseln gemäß einer Ausführungsform der vorliegenden Erfindung;
6 schematisch eine Menge von Prozeduren für Ferntextinformationen, die durch ein Anwendungsprogramm auf einem Server erzeugt werden, zu einer Anzeige eines fernen Client gemäß einer Ausführungsform der vorliegenden Erfindung;
7A ein Liniendiagramm mehrerer Segmente, die einen bestimmten Weg bilden;
7B eine Repräsentation des Liniendiagramms von 7A auf Pixelniveau, in der dargestellt wird, wie der Weg tatsächlich auf einer Computeranzeige approximiert wird;
8A ein Flußdiagramm der Schritte bei der Verarbeitung und Codierung von Segment- und Streifendaten gemäß einer Ausführungsform der vorliegenden Erfindung;
8B ein Koordinatensystem, das zu einer Menge von 16 Regionen organisiert wird, mit dem Winkelinformationen in bezug auf Streifen quantisiert werden und das die Komprimierungseffizienz verbessert, gemäß einer Ausführungsform der vorliegenden Erfindung;
9 eine Überlagerung des Koordinatensystems von 8B auf die Repräsentation auf Pixelniveau von 7B zur Darstellung einer Ausführungsform einer Streifenverarbeitungstechnik gemäß der vorliegenden Erfindung;
10 eine Tabelle, die zeigt, wie man den nächsten Streifen von dem Endpunkt des vorherigen Streifens erhält, für Streifen in jedem der quantisierten Segmente von 8B, gemäß einer Ausführungsform der vorliegenden Erfindung; und
11 ein Flußdiagramm der Schritte, die von dem Server-Agent als Reaktion auf eine Fehlerbedingung durchgeführt werden, wobei die Außerbildschirm-Oberfläche eines Client ausgebildet wird.
AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG
Die vorliegende Erfindung verringert die Menge an zwischen einem Anwendungsserver, der ein Anwendungsprogramm ausführt, und einem teilnehmenden Client, der lokal die Ausgangsdaten des Anwendungsprogramms anzeigt, übertragenen graphischen Daten durch Codieren der Daten zu relativ kleinen Repräsentationen, die sich innerhalb des zwischen dem Client und dem Server übertragenen Protokollstroms wiederholen. Auf diese Weise minimiert die Erfindung die Größe jedes diskreten Datenelements, das übertragen werden muß, und vergrößert die Wiederholbarkeit der Daten innerhalb des Protokollstroms, so daß Komprimierungsalgorithmen, die effizienter an sich wiederholenden codierten Daten operieren, einen größeren Grad an Komprimierungseffizienz realisieren können. Die Erfindung verwendet eine Anzahl von Techniken zur Realisierung der verbesserten Komprimierung, darunter die folgenden: Scannen einer Befehlswarteschlange nach später ausgegebenen Befehlen, die früher ausgegebene Befehle ablösen haben; Disk-Cache-Techniken, die die Komprimierung von Daten, die bereits während einer Client-Server-Sitzung angetroffen wurden, verbessern; Übertragung relativer Koordinaten unter Verwendung quantisierter Regionen zur Vermeidung des Sendens beider Endpunkte und/oder des Winkels eines assoziierten Streifens; und Manipulation von Außerbildschirm-Oberflächen zur Verbesserung der Leistungsfähigkeit während der Client-Server-Sitzung.
Die Erfindung verringert außerdem die Häufigkeit von Überrollproblemen, die auftreten, wenn eine Leistungsfähigkeitsfehlanpassung zwischen einem schnellen Server und einem relativ langsamen Netzwerk oder Client besteht.
Mit Bezug auf 1 befinden sich ein oder mehrere Client-Knoten 110', 110'' (im folgenden wird jeder Client-Knoten oder Vielzahl von Client-Knoten im allgemeinen als 110 bezeichnet) in Kommunikation mit einem oder mehreren Server-Knoten 150', 150'' (im folgenden wird jeder Server-Knoten oder jede Vielzahl von Server-Knoten allgemein als 150 bezeichnet) über ein Kommunikationsnetz 140. Das Netzwerk 140 kann ein lokales Netzwerk (LAN), ein mittelflächiges Netzwerk (MAN) oder ein großflächiges Netzwerk (WAN), wie zum Beispiel das Internet oder das World Wide Web sein. Benutzer des Client-Knotens 110 können durch vielfältige Verbindungen mit dem Netzwerk 140 verbunden sein, darunter Standard-Telefonleitungen, LAN- oder WAN-Verbindungen (z.B. T1, T3, 56 kb, X.25), Breitbandverbindungen (ISDN, Frame Relay, ATM) und drahtlose Verbindungen. Die Verbindungen können mit vielfältigen Kommunikationsprotokollen hergestellt werden (z.B. TCP/IP, IPX, SPX, NetBIOS und direkte asynchrone Verbindungen). Bei bestimmten besonders vorteilhaften Ausführungsformen kann das verwendete Protokoll das Protokoll der unabhängigen Datenverarbeitungsarchitektur von Citrix Systems, Inc., in Fort Lauderdale, Florida, sein, oder das Remote Display Protocol von Microsoft Corporation in Redmond, Washington.
Der Client-Knoten 110 kann ein beliebiger Personal Computer sein (z.B. 286, 386, 486, Pentium, Pentium II, Macintosh-Computer), ein auf Windows basierendes Terminal, ein Netzwerkcomputer, eine drahtlose Einrichtung, ein Informationsgerät, ein RISC-Power-PC, eine X-Einrichtung, eine Workstation, ein Minicomputer, ein Zentralrechner oder eine andere Datenverarbeitungseinrichtung, die ein auf Windows basierendes Desktop und ausreichend Speicher zur Ausführung eines kleinen Anzeigepräsentationsprogramms aufweist. Das Anzeigepräsentationsprogramm verwendet Befehle und Daten, die ihm über das Netzwerk 140 von dem Anwendungsserver 150 gesendet werden, um eine graphische Anzeige wiederzugeben. Bei einem verteilten Computersystemmodell findet die Ausführung von Anwendungsprogrammen hauptsächlich auf dem Anwendungsserver 150 statt, und die Benutzeroberfläche, die Tastenbetätigungen und die Mausbewegungen, die durch Eingaben auf der Clientseite erzeugt werden, werden über das Netzwerk 140 zu und von dem Client-Knoten 110 übertragen.
Der Client-Knoten 110 enthält typischerweise einen Prozessor 112, einen flüchtigen Speicher 114 (z.B. RAM-Cache), ein Betriebssystem 116, einen Client-Agent 118, einen persistenten Speicher 120, eine Netzwerkschnittstelle 122 (z.B. eine Netzwerkschnittstellenkarte), eine Tastatur 124, eine Maus 126 und eine Anzeige 128. Zu von dem Client-Knoten 110 unterstützten Windows-orientierten Plattformen können ohne Einschränkung die folgenden gehören: WINDOWS 3.x, WINDOWS 95, WINDOWS 98, WINDOWS NT 3.51, WINDOWS NT 4.0, WINDOWS 2000, WINDOWS CE, MAC/OS, Java und UNIX. Der Client-Agent 118 entspricht einem Softwareprogramm, das Befehle und Daten von dem Server-Knoten 150 und von einem (nicht gezeigten) Benutzer des Client-Knotens 110 empfängt. Der Client-Agent 118 verwendet die empfangenen Informationen, wenn er mit anderen Komponenten des Client-Knotens 110 in Wechselwirkung tritt (z.B. beim Anleiten des Betriebssystems 116, Daten auf die Anzeige 128 auszugeben). Außerdem sendet der Client-Agent 118 Anforderungen und Daten als Reaktion auf vom Server ausgegebene Befehle oder Benutzeraktionen an dem Client-Knoten 110 zu dem Server-Knoten 150.
Ähnlich enthält der Server-Knoten 150 einen Prozessor 152, einen flüchtigen Speicher 154, ein Betriebssystem 156, ein Anwendungsprogramm 158, einen Server-Agent 160, persistenten Speicher 162 und eine Netzwerkschnittstelle 164. Der Server-Agent 160 entspricht einem Softwareprogramm, das eine Schnittstelle mit dem Client-Agent 118 und anderen Komponenten des Server-Knotens 150 zur Unterstützung der Fernanzeige und Operabilität des Anwendungsprogramms 158 aufweist.
Jeder Anwendungsserver 150 ist Host für ein oder mehrere Anwendungsprogramme 158, auf die die Client-Knoten 110 zugreifen können. Zu Beispielen für solche Anwendungen gehören Textverarbeitungsprogramme wie etwa MICROSOFT WORD und Tabellenkalkulationsprogramme wie etwa MICROSOFT EXCEL, wobei beides von der Microsoft Corporation in Redmond, Washington hergestellt wird, Finanzberichtprogramme, Kundenregistrationsprogramme, Programme, die technische Serviceinformationen liefern, Kundendatenbankanwendungen oder Anwendungssatzmanager.
Während der Ausführung des Anwendungsprogramms 158 kommuniziert ein Server 150 über einen Transportmechanismus (Teil des Server-Agent 160) mit dem Client-Knoten 110. Bei einer Ausführungsform liefert der Transportmechanismus mehrere virtuelle Kanäle, und einer der virtuellen Kanäle liefert ein Protokoll zur Übertragung von graphischen Bildschirmdaten aus dem Server-Knoten 150 zu dem Client-Knoten 110. Der Server 150 führt einen Protokolltreiber aus (Teil des Server-Agent 160), der Schnittstellenbefehle der graphischen Anzeige (die durch das Anwendungsprogramm 158 erzeugt werden und für das Betriebssystem 156 im Server bestimmt sind) abfängt, und übersetzt diese in ein für die Übertragung über den Transportmechanismus geeignetes Protokollpaket.
Bei einer Ausführungsform und mit Bezug auf 2 fängt der Server-Agent 160 eine von dem Anwendungsprogramm 158 ausgegebenen und an das Betriebssystem 156 gerichteten Schnittstellenbefehl der graphischen Anzeige ab (Schritt 202), codiert mit dem Befehl und dem Anwendungsprogramm 158 assoziierte Daten (Schritt 204), komprimiert die codierten graphischen Daten (Schritt 206), erzeugt ein Transportprotokollpaket, das den abgefangenen Befehl und komprimierte codierte Daten enthält (Schritt 208) und sendet das Transportprotokollpaket zu dem Zielclient-Knoten 110 (Schritt 210). Graphische Daten bedeuten eine beliebige Art von Daten, die auf der Anzeige 128 angezeigt werden kann, wie zum Beispiel Bitmaps, Glyphen, Koordinaten, Linienlisten, Streifen usw. Im folgenden können Beschreibungen von Techniken, die auf bestimmte Arten von graphischen Daten oder graphischen Objekten angewandt werden, als für alle Arten von graphischen Daten geltend aufgefaßt werden.
Genauer gesagt fängt ein Protokolltreiber des Server-Agent 160 die Schnittstellenbefehle der graphischen Anzeige ab (Schritt 202). Bei einer Ausführungsform fängt der Protokolltreiber Aufrufe der Anwendungsprogrammierschnittstelle auf hoher Ebene ab, die von dem Anwendungsprogramm 158 durchgeführt werden. Bei einer Ausführungsform fängt der Protokolltreiber GDI-Befehle ab, die von dem auf WINDOWS basierenden Betriebssystemen bereitgestellt werden. Bei einer anderen Ausführungsform fängt der Protokolltreiber QUICKDRAW-Befehle ab, die von Betriebssystemen auf MAC/OS-Basis bereitgestellt werden. Bei weiteren Ausführungsformen fängt der Protokolltreiber Befehle auf niedrigerer Ebene ab, wie zum Beispiel Schnittstellenaufrufe des Gerätetreibers, der der graphischen Anzeige des Server-Knotens 150 zugeordnet ist. Bei weiteren Ausführungsformen kann der Schnittstellenbefehl der graphischen Anzeige nicht abgefangen, sondern dupliziert werden. Bei diesen Ausführungsformen wird die Anzeige der Anwendungsprogrammausgangsdaten auf dem Server 150 und dem Client 110 im wesentlichen ähnlich oder identisch sein. Der Protokolltreiber erzeugt auf der Basis des abgefangenen graphischen Anzeigebefehls ein Transportprotokollpaket (Schritt 208). Der Protokolltreiber kann einen Protokollbefehlssatz verwenden, der für jeden möglichen abgefangenen Anzeigeschnittstellenbefehl einen analogen Befehl enthält. Als Alternative kann der Protokolltreiber einen Befehlssatz verwenden, der eine Teilmenge der abgefangenen Anzeigeschnittstellenbefehle ist. Bei anderen Ausführungsformen kann der Protokollbefehlssatz eine Übermenge der möglichen abgefangenen Anzeigeschnittstellenbefehle sein.
Für jeden abgefangenen GDI-Befehl und betroffene graphische Daten, die zu dem Client-Agent 118 gesendet werden müssen, um die Ausgabe des Anwendungsprogramms 158 auf der Anzeige 128 des Client anzuzeigen, reiht der Server-Agent 160 den betreffenden Protokollbefehle zusammen mit einem eindeutigen Schlüssel 412 (4), der den betroffenen graphischen Daten zugeordnet ist, in eine Warteschlange ein. Der eindeutige Schlüssel 412 beschreibt die graphischen Daten und identifiziert diese eindeutig. Bei einer Ausführungsform wird der eindeutige Schlüssel durch Ausführen einer 64-Bit-CRC-Prüfung (Cyclic Redundancy Check) an den graphischen Daten erzeugt. Bei einer anderen Ausführungsform wird die 64-Bit-CRC als zwei 32-Bit-CRCs erzeugt, die sequentiell und in entgegengesetzten Richtungen an den graphischen Daten ausgeführt werden. Außerdem können andere Verfahren zum Erzeugen eines eindeutigen, graphischen Daten zugeordneten Schlüssels, die Fachleuten bekannt sind, verwendet werden. Der Protokollbefehl und der eindeutige Schlüssel 412 werden im Server 150 zusammen mit anderen Sätzen von Befehlen/eindeutigen Schlüsseln in eine Warteschlange eingereiht. Die in Warteschlangen eingereihten Befehle werden dann gescannt, um zu bestimmen, ob später ausgegebene Befehle (d.h. die in der Nähe des hinteren Endes der Warteschlange) früher ausgegebene Befehle (d.h. denen näher am Anfang der Warteschlange) ablösen. Wenn andere gegenüber den früher ausgegebenen Befehlen Vorrang haben, dann entfernt der Server-Agent 160 diese aus der Warteschlange und vermeidet somit das Übertragen unnötiger Daten zu dem Client-Agent 118.
Zum Beispiel muß eine Reihe von Befehlen zur Anzeige der nächsten Datenseite, die in schneller Abfolge ausgegeben wird, nicht individuell an dem Client 110 angezeigt werden. Es muß lediglich die letzte ausgegebene Anzeigeseite angezeigt werden, da diese letzte Datenseite alle vorherigen Datenseiten überschreiben wird. Durch Entfernen der unnötigen Befehle und der eindeutigen Schlüssel, die den früheren Seiten entsprechen, aus der Warteschlange des Servers verringert der Server-Agent 160 die Menge an zu verarbeitenden und zu übertragenden Daten wesentlich.
Bei einem Ausführungsbeispiel werden nur unnötige Befehle und damit zusammenhängende Daten in bezug auf durchlässige Operationen von der Warteschlange des Servers entfernt. Wenn zum Beispiel bei einem zuvor eingereihten Befehl eine rechteckige Region mit den Koordinaten 10, 10, 50, 50 erzeugt wird und ihm ein später eingereihter Befehl folgt, bei dem eine größere/abdeckende rechteckige Region mit den Koordinaten 0, 0, 100, 100 erzeugt wird, dann werden der zuvor eingereihte Befehl und die diesbezüglichen Daten als unnötig betrachtet und aus der Warteschlange entfernt.
Die nachfolgende Tabelle 1 zeigt eine beispielhafte Menge von bei einer Ausführungsform der Erfindung bereitgestellten Protokollbefehlen.
TABELLE 1 – PROTOKOLLBEFEHLE
Bei einer Ausführungsform werden die Protokollbefehle und zugeordneten graphischen Daten so konfiguriert, daß die Wiederholung von Informationen in dem durch den Protokolltreiber erzeugten Protokollpaketstrom maximiert wird. In einem Aspekt der Erfindung werden die graphischen Daten zuerst codiert (Schritt 204), bevor die codierten graphischen Daten und/oder Protokollbefehle einem Kompressionsalgorithmus unterzogen werden (Schritt 206), der die sich wiederholende Beschaffenheit des Protokollstroms ausnutzt (z.B. kann ein Kompressionsprotokoll des Typs Lempel-Ziv verwendet werden). Bei einer Ausführungsform und bei der ersten Instanz der graphischen Daten in der Client-Server-Sitzung wird zusammen mit den entsprechenden codierten Daten in dem Protokollstrom ein Indicia der graphischen Daten übertragen, um so die Menge an über das Netzwerk 140 für zukünftige Instanzen der graphischen Daten, die während derselben Client-Server-Sitzung auftreten, übertragenen Daten zu verringern. Die komprimierten Daten werden danach in das Transportprotokollpaket gebündelt und zur Dekomprimierung und Interpretation zu dem Client-Knoten 110 übertragen (Schritt 208).
Bei einem Ausführungsbeispiel führt das Anwendungsprogramm 158 einen GDI-Befehl aus, der das Betriebssystem 156 des Servers anweist, eine Bitmap zu zeichnen. Der Server-Agent 160 fängt diesen GDI-Befehl ab (Schritt 202) und gibt einen BITBLT-Befehl an den Client-Agent 118 aus, der den Client-Agent 118 anweist, die Ausgangsdaten des Anwendungsprogramms auf der Anzeige 128 des Client anzuzeigen. Vor der Ausgabe des BITBLT-Befehls codiert der Server-Agent 160 die Ausgangsdaten (Schritt 204) und nimmt die codierten Daten zusammen mit dem BITBLT-Befehl in den zu dem Client-Agent 118 übertragenen komprimierten Protokollpaketstrom auf. Bei einer Ausführungsform werden die die Bitmap 410 (4) beschreibenden Daten codiert und komprimiert (Schritte 204 und 206), um bestimmte der in der Bitmap 410 vorhandenen Redundanzen auszunutzen. Zum Beispiel kann die Bitmap 410 dergestalt sein, daß sukzessive Rasterzeilen redundant oder angrenzende Pixel redundant sind.
Zusätzlich zu der Codierung von Bitmaps oder anderer diskreter graphischer Datenelemente auf der Basis ihrer internen Datenredundanzen umfaßt die Erfindung außerdem Cache-Techniken, die die Codierung und Komprimierung graphischer Daten, die zuvor während einer bestimmten Client-Server-Sitzung angetroffen wurden, weiter verbessern. Wenn zum Beispiel eine bestimmte Bitmap zum ersten Mal während einer Client-Server-Sitzung angetroffen wird, wird sie wie oben beschrieben codiert. Für nachfolgende Übertragungen der Bitmap während derselben Client-Server-Sitzung können anstelle der relativ größeren codierten Bitmap Indicia der Bitmap gesendet werden. Bei einer Ausführungsform entsprechen die Indicia einer Stelle in dem flüchtigen Speicher des Client, die die zuvor übertragene Bitmap enthält.
Genauer gesagt und mit Bezug auf 3 und 4 erzeugt der Server-Agent 160 wie oben beschrieben den eindeutigen Schlüssel 412 (Schritt 330) und ordnet den eindeutigen Schlüssel 412 den graphischen Daten (z.B. der Bitmap 410) zu. Diese Zuordnung definiert im wesentlichen die Bitmap 410 und ihre betreffenden Daten als ein graphisches Objekt, das danach zusammen mit seinem eindeutigen Schlüssel 412 und den codierten Daten 414 in einer Datenstruktur 411 (z.B. einer Tabelle) registriert wird (Schritt 340), die in dem flüchtigen Speicher 154 (z.B. dem Cache-Subsystem des Servers) des Servers gespeichert wird. Bei anderen Ausführungsformen können die die Bitmap betreffenden Daten in die persistente Speicherung 162 des Servers geschrieben werden.
Unter der Annahme, daß später ausgegebene Befehle (wie zuvor beschrieben) nicht gegenüber dem Protokollbefehl (z.B. BITBLT) und zugeordneten graphischen Daten Vorrang haben, entfernt der Server-Agent 160 den BITBLT-Befehl und den eindeutigen Schlüssel 412 aus der Warteschlange (Schritt 360) und durchsucht die in dem flüchtigen Speicher 154 des Servers gespeicherte Tabelle 411, um zu bestimmen, ob der eindeutige Schlüssel 412 zuvor darin gespeichert wurde. Wenn sich der eindeutige Schlüssel 412 in der Tabelle 411 befindet, bestimmt der Server-Agent 160, daß die codierten Daten 414 zuvor bereits durch den Server 150 verarbeitet worden sind. Der Server-Agent 160 durchsucht dann die Tabelle 411 nach einem der codierten Bitmap 414 zugeordneten Index oder Handle 416. Wenn der Index 416 gefunden wurde, bestimmt der Server-Agent 160, daß die codierte Bitmap 414 nicht nur durch den Server 150 verarbeitet wurde, sondern daß sie auch zuvor zu dem Client-Agent 118 übertragen wurde. Wenn sich der Index 416 nicht in der Tabelle 411 befindet, bestimmt der Server-Agent 160, daß die codierte Bitmap 414 nicht zuvor übertragen wurde.
Bei einer Ausführungsform identifiziert der Index 416 eine bestimmte Stelle in dem flüchtigen Speicher 114 des Client, die die zuvor übertragene codierte Bitmap 414 speichert. Bei einer Ausführungsform liefert der Client-Agent 118 einen Schnappschuß seines verfügbaren flüchtigen Speichers 114 beim Einleiten einer Client-Server-Sitzung mit dem Server-Agent 160 an den Server-Agent 160. Nachdem die Sitzung hergestellt wurde, steuert der Server-Agent 160 danach die Zuteilung des verfügbaren flüchtigen Speichers 114 des Client. Auf diese Weise kann der Server-Agent 160 den flüchtigen Speicher 114 der codierten Bitmap 414 zuteilen und dem Index 416 als Zeiger oder Referenz auf den zugeteilten Speicher und als Kennung der zuvor übertragenen codierten Bitmap 414 behalten.
Wenn sich der Index 416 in der Tabelle 411 des Servers befindet, erhält der Server-Agent 160 den Index 416 (Schritt 370), komprimiert den Index 416 zusammen mit dem betreffenden Protokollbefehl (Schritt 380) und sendet die komprimierten Daten in einem an den Client-Agent 118 gerichteten Paket über das Netzwerk 140. Bei einer Ausführungsform ist der Index 416 kürzer (z.B. 16 Bit) als der eindeutige Schlüssel 412 (z.B. 64 Bit) und verbraucht folglich bei der Übertragung weniger Bandbreite. Nach dem Empfang und der Dekomprimierung des komprimierten Pakets greift der Client-Agent 118 auf die bestimmte Speicherstelle in dem flüchtigen Speicher 114 des Client zu, die durch den Index 416 spezifiziert wird, um die entsprechenden graphischen Daten 410 zu erhalten. Danach manipuliert der Client-Agent 118 die erhaltenen graphischen Daten 410 gemäß dem Befehl, der den Index 416 in dem komprimierten Paket begleitet hat. Auf diese Weise vermeidet die Erfindung die Notwendigkeit, relativ große Bitmap- oder andere graphische Daten, die zuvor während einer bestimmten Client-Server-Sitzung angetroffen wurden, neu zu übertragen.
Wenn sich der Index 416 nicht in der Tabelle 411 des Servers befindet (und somit nicht zuvor zu dem Client-Agent 118 übertragen wurde), teilt der Server-Agent 160 einen Teil des flüchtigen Speichers 114 des Client für die Bitmap 410 zu und bildet den Index 416, der die Speicherstelle identifiziert. Der Server-Agent 160 speichert die codierte Bitmap 414 (entsprechend der Bitmap 410), den neugebildeten Index 416 und den der codierten Bitmap 414 zugeordneten eindeutigen Schlüssel 412 dann in der Tabelle 411 des Servers. Danach komprimiert der Server-Agent 160 die codierte Bitmap 414, den Index 416 und betreffenden Befehl und sendet die komprimierten Daten in einem an den Client-Agent 118 gerichteten Paket. Nach Empfang und Dekomprimierung decodiert der Client-Agent 118 die codierten Daten 414 und speichert die resultierende Bitmap 410 in der durch den Index 416 identifizierten Speicherstelle und manipuliert die resultierende Bitmap 410 gemäß dem Begleitbefehl. Alternativ dazu speichert der Client-Agent 118 die codierten Daten 414 in der durch den Index 416 identifizierten Speicherstelle und decodiert die codierten Daten 414 nur, wenn notwendig zur weiteren Manipulation der resultierenden Bitmap 410. Auf diese Weise wird der Client-Speicher effizienter ausgenutzt.
Obwohl die Erfindung bisher so beschrieben wurde, daß der Server-Agent 160 die Speicherzuteilung und Indexbildung des Client steuert, ist es auch möglich, daß der Client-Agent 118 diese Funktionen ausführt. Wenn zum Beispiel zum ersten Mal während einer Client-Server-Sitzung eine Bitmap angetroffen und codiert, komprimiert und zu dem Client-Agent 118 übertragen wird (mit dem Begleitbefehl, aber ohne den Index 416), kann der Client-Agent 118 die bestimmte Stelle in dem flüchtigen Speicher 114 zum Speichern der Bitmap 410 bestimmen. Bei dieser Ausführungsform bildet der Client-Agent 118 einen (nicht gezeigten) Index, der die codierte Bitmap und ihre entsprechende Speicherstelle eindeutig identifiziert, und sendet den Index zu dem Server-Agent 160, der den Index an der entsprechenden Stelle in der Tabelle 411 des Servers speichert.
Weiter mit Bezug auf die Ausführungsform, bei der der Server-Agent 160 die Zuteilung des flüchtigen Speichers 114 des Client steuert, führt der Client-Agent 118 eine kreisförmige Warteschlange 421 aller durch den Server-Agent 160 spezifizierten Indizes gemäß auch von diesem empfangenen Warteschlangenwartungsbefehlen. Zum Beispiel kann der Server-Agent 160 den Client-Agent 118 anleiten, die Zuordnung eines vorbestimmten Blocks von Indizes 417 (z.B. entsprechend 128K Speicher) zu ihren jeweiligen graphischen Daten aufzuheben, um neu angetroffene graphische Objekte unterzubringen, wenn der flüchtige Speicher 114 des Client ansonsten voll abonniert ist. Danach erhält ein nachfolgendes neues graphisches Objekt einen zuvor benutzten Index.
Der Server-Agent 160 bestimmt außerdem gemäß vorbestimmten Kriterien, ob jedes durch die Neuzuweisung der Indizes beeinflußte graphische Objekt abgestoßen oder gesichert werden soll. Der Server-Agent 160 übermittelt diese Entscheidung zu dem Client-Agent 118. Wenn zum Beispiel der Server-Agent 160 die Indizes 0, 1, 2 und 3 neu zuweist und bestimmt, daß die den Handles 0 und 2 zugeordneten graphischen Objekte gelöscht oder in die persistente Speicherung 120 des Client verschoben und die den Handles 1 und 3 zugeordneten Objekte gesichert werden sollen, weist der Server-Agent 160 somit den Client-Agent 118 an, 0 und 2 zu löschen (oder zu verschieben) und 1 und 3 zu sichern. Der Client-Agent 118 verschiebt dann den Index jedes gesicherten Objekts an das Ende der kreisförmigen Warteschlange. Mindestens ein Index bleibt am Ende der Warteschlange für eine Zuweisung zu dem verschobenen Objekt verfügbar; das heißt, bei einer Ausführungsform zeigen Kopf und Ende der Warteschlange nicht auf denselben Index in der kreisförmigen Warteschlange. Ein verschobenes Objekt wird folglich sowohl an einer anderen physischen Speicherstelle gespeichert als auch einem anderen Index zugeordnet.
Die an der kreisförmigen Warteschlange 421 des Client ausgeführten Wartungsaktionen werden typischerweise häufiger, wenn die Client-Server-Sitzung andauert, und der begrenzte flüchtige Speicher 114 des Client 110 wird voll von zuvor übertragenen Bitmaps 410 und anderen graphischen Objekten. Die Anzahl zuvor übertragener graphischer Objekte 422, die aus dem flüchtigen Speicher 114 in die persistente Speicherung 120 des Client verschoben werden, nimmt folglich zu. Die vorliegende Erfindung verbessert die oben beschriebene Cache-Technik weiter, um nach Indicia (siehe den nachfolgenden „Fuzzy-Schlüssel") zuvor übertragener graphischer Objekte 422 zu suchen, die möglicherweise in der persistenten Speicherung 120 des Client gespeichert sind, wenn ein Index auf dieses graphische Objekt 422 nicht in der Tabelle 411 des Servers gefunden wird. Wenn solche Indicia gefunden werden, besteht eine starke Wahrscheinlichkeit, daß das zuvor übertragene graphische Objekt 422 immer noch lokal in dem Client-Agent 118 verankert und diesem zugänglich ist und daß das graphische Objekt 422 deshalb möglicherweise nicht neu von dem Server-Agent 150 zu dem Client-Agent 110 übertragen werden muß. Es muß beachtet werden, daß das Finden solcher Indicia eine starke Wahrscheinlichkeit, aber keine Bestimmtheit, ergibt, daß das graphische Objekt 422 lokal verankert ist, da möglicherweise andere Programme oder Client-Agents, die möglicherweise gemeinsam dieselbe persistente Speicherung 120 verwenden, das graphische Objekt 422 aus der persistenten Speicherung 120 gelöscht haben (z.B. um in der persistenten Speicherung Platz für ein neues Objekt zu schaffen).
Genauer gesagt und mit Bezug auf 4 und 5 durchsucht der Server-Agent 118, wenn der Server-Agent 160 keinen Index für eine bestimmte Bitmap 422 in der Indextabelle 411 des Servers finden kann, eine zweite Tabelle 418 (im folgenden „Fuzzy-Datenbank") nach einem Eintrag 419 (im folgenden „Fuzzy-Schlüssel"), der mit der Bitmap 422 assoziiert ist (Schritt 520). Bei einer Ausführungsform ist jeder Fuzzy-Schlüssel 419 eine Kombination des eindeutigen Schlüssels 412 in der Tabelle 411 des Servers und der Länge/Größe der zugeordneten Bitmap 422. Der Fuzzy-Schlüssel kann zum Beispiel über eine XOR-(exklusiv-OR-)Verknüpfung zwischen den zur Berechnung des eindeutigen 64-Bit-Schlüssels 412 in der Tabelle 411 des Servers verwendeten 32-Bit-CRSs und der Länge der mit dem eindeutigen Schlüssel 412 assoziierten Bitmap 422 gebildet werden. Die Fuzzy-Datenbank 418 liefert im wesentlichen eine Anfangsprädiktion darüber, ob in der persistenten Speicherung 120 des Clients 110 eine Kopie der Bitmap 422 gespeichert ist. Wenn die Fuzzy-Datenbank 418 den der Bitmap zugeordneten Fuzzy-Schlüssel 419 nicht enthält, ist wahrscheinlich keine Kopie der Bitmap 422 in der persistenten Speicherung 120 des Clients gespeichert und der Server-Agent 160 muß deshalb eine codierte Version der Bitmap 422 wie zuvor beschrieben zu dem Client-Agent 118 übertragen. Wenn dagegen die Fuzzy-Datenbank 418 den Fuzzy-Schlüssel 419 für die Bitmap 422 enthält, besteht eine starke Wahrscheinlichkeit, daß die Bitmap 422 in der persistenten Speicherung 120 des Clients gespeichert ist.
Wenn der Server-Agent 160 keinen Fuzzy-Schlüssel 419 in der Fuzzy-Datenbank 418 findet, der der Bitmap 422 zugeordnet ist, sendet der Server-Agent 160 genauer gesagt eine (der Bitmap 422 entsprechende) codierte Bitmap zu dem Client-Agent 118 mit einem Befehl, der von dem Client-Agent 118 anfordert, die Bitmap 422 (oder die entsprechende codierte Bitmap) in dem flüchtigen Speicher 114 zu speichern (Schritt 530). Außerdem und wie oben beschrieben nimmt der Server-Agent 160 den der Bitmap 422 zugeordneten Fuzzy-Schlüssel in die Fuzzy-Datenbank 418 auf (Schritt 540). Man beachte, daß die Reihenfolge der Schritte 530 und 540 umgekehrt werden kann, so daß die Fuzzy-Datenbank 418 vor der Übertragung des Befehls und der codierten Version der Bitmap 422 aktualisiert wird. Der Client-Agent 118 kopiert danach die Bitmap 422 in eine bestimmte Stelle in dem flüchtigen Speicher 114 des Client, wie durch den Server-Agent 160 spezifiziert (Schritt 560).
Bei einer Ausführungsform wartet der Server-Agent 160 nicht auf eine Bestätigung von dem Client-Agent 118, da die der Bitmap 422 zugeordnete codierte Bitmap erfolgreich empfangen und verarbeitet wurde. Statt dessen nimmt der Server-Agent 160 an, daß die codierte Bitmap ordnungsgemäß verarbeitet wurde, und streamt weiter Protokollbefehle, ohne auf die Rückgabe einer Bestätigungsnachricht von dem Client-Agent 118 zu warten. Der Server-Agent 160 verfolgt die Anzahl der seit der letzten gelesenen Bestätigung ausgegebenen Protokollbefehle. Der Server-Agent 160 blockiert die weitere Übertragung von Protokollbefehlen, wenn die Anzahl eine vordefinierte Schwelle erreicht. Durch die Schwelle kann der Client-Agent 118 eine obere Schranke für die Menge an Speicher herstellen, der zum Einreihen ankommender Protokollbefehle während des Betriebs im Recovery-Modus notwendig ist, einrichten wie später ausführlicher beschrieben werden wird.
Wenn ein Fuzzy-Schlüssel 419 in der Fuzzy-Datenbank 420 gefunden wird, sendet der Server-Agent 160 einen Befehl zu dem Client 110, der den Client-Agent 118 anweist, die dem Fuzzy-Schlüssel 419 zugeordnete Bitmap 422 aus der persistenten Speicherung 120 des Client in den flüchtigen Speicher 114 des Client zu kopieren (Schritt 550). Diesen Befehl begleitet nicht nur der Fuzzy-Schlüssel 419, der die interessierende Bitmap 422 eindeutig identifiziert, sondern auch der durch den Server-Agent 160 (wie zuvor beschrieben) erzeugte zugeordnete Index, um die spezifische Speicherstelle in dem flüchtigen Speicher 114 des Clients zu identifizieren, der die kopierte Bitmap 422 empfängt und speichert. Durch Kopieren der Bitmap 422 in den flüchtigen Speicher 114, statt einfach nur ihre Stelle in der persistenten Speicherung 120 aufrechtzuerhalten, kann die Erfindung schnell auf mehrere Anforderungen zum Entnehmen der Bitmap 422 reagieren, die in schneller Abfolge empfangen werden oder ohne viel dazwischentretende Cache-Aktivität, indem die Bitmap 422 beim Auftreten der ersten Anforderung kopiert wird.
Wenn die Bitmap 422 trotz der Anwesenheit des entsprechenden Fuzzy-Schlüssels 419 in der Fuzzy-Datenbank 418 nicht gerade in der persistenten Speicherung 120 gespeichert ist, gibt der Client-Agent 118 (als Antwort auf den zuvor von dem Server-Agent 160 ausgegebenen Befehl „LACHE_READ_DISK_OBJECT") eine Nachricht an den Server-Agent 160 zurück, die angibt, daß die Bitmap 422 fehlt. Nach dem Empfang dieser Nachricht sendet der Server-Agent 160 die der Bitmap 422 zugeordneten codierten Bitmapdaten neu zu dem Client-Agent 118 (Schritt 530). Man beachte, daß der Server-Agent 160 eine sequentielle Liste aller zu dem Client-Agent 118 gesendeten solchen LACHE_READ_DISK_OBJECT-Befehle, für die der Server-Agent 160 noch keine Bestätigung empfangen hat, führt, so daß der Server-Agent 160 eine empfangene Bestätigung ordnungsgemäß einer bestimmten Bitmap 422 zuordnen kann (um so die codierte Bitmap, die übertragen werden muß, ordnungsgemäß zu identifizieren).
In der Zwischenzeit tritt der Client-Agent 118 in einen Recovery-Modus ein, in dem der Client-Agent 118 weiter den ankommenden Protokollstrom liest, aber ihn nicht verarbeitet. Statt dessen konstruiert der Client-Agent 118 eine Warteschlange zum Empfang des Befehlsstroms, der weiter von dem Server 150 nach dem Befehl, der die Bitmap 422 nicht in der persistenten Speicherung 120 finden konnte, fließt. Der Client-Agent 118 speichert diese Befehle weiter in dieser Warteschlange im FIFO-Verfahren (first in, first out), bis die codierte Bitmap empfangen und erfolgreich decodiert wird, um die Bitmap 422 zu erzeugen. Um die fehlende Bitmap 422 in dem ankommenden Befehlsstrom zu erkennen, sucht der Client-Agent 118 nach einer Recovery-Markierung in den Protokollstrom begleitenden graphischen Daten. Bei einer Ausführungsform ist die Recovery-Markierung eine bestimmte Pseudozufallszahl, die mit dem eindeutigen Schlüssel der Bitmap 422 (d.h. dem 64-Bit-CRC und 32-Bit Länge) XOR-verknüpft wird. Der Server-Agent 160 erzeugt die Recovery-Markierung nach dem Empfang einer Keine-Bestätigung-Nachricht von dem Client-Agent 118. Wenn die Bitmap 422 ankommt, speichert der Client-Agent 118 sie in seinem flüchtigen Speicher 114 (Schritt 560) (d.h. wo die Bitmap 422 gespeichert worden wäre, wenn das Objekt zu Anfang in der persistenten Speicherung 120 vorhanden gewesen wäre) und beginnt mit der Verarbeitung der Befehle in der Warteschlange. Nach der Verarbeitung aller Befehle in der Warteschlange nimmt der Client-Agent 118 den ankommenden Strom von Protokollbefehlen, der von dem Server 150 über das Netzwerk 140 ankommt, wieder auf.
Ein Vorteil des oben beschriebenen Recovery-Prozesses besteht darin, daß er die Zeitverzögerungskosten vermeidet, die durch Cache-Systeme entstehen, die die Befehle in der Pipeline nach dem Auftreten einer Cache-Verfehlung ausräumen. Außerdem verursacht der Recovery-Prozeß keine Unterbrechung des Stroms von Protokollbefehlen und auch keine Zunahme des Verkehrs auf dem Kanal um mehr als nur einige wenige Byte mehr als das, was der Server 150 zu dem Client 110 gesendet hätte, wenn der Server-Agent 160 zu Anfang gewußt hätte, daß sich die Bitmap 422 nicht in der persistenten Speicherung 120 befand.
Bei einer Ausführungsform erleichtert die vorliegende Erfindung das Finden der Bitmap 422 in der persistenten Speicherung 120 des Clients durch Speichern der Bitmap 422 in einer Datei, deren Dateiname durch Codieren des Fuzzy-Schlüssels 419 zusammen mit der Bitmap 422 zugeordneten am-wenigsten-jüngst-verwendet- und/oder am-wenigsten-häufig-verwendet-Informationen. Auf diese Weise liefert der Dateiname selbst die gewünschten Informationen und es wird also vermieden, die Datei öffnen und lesen zu müssen. Die Codierung des Fuzzy-Schlüssels 419 als Teil des Dateinamens der Bitmap ermöglicht dem Client-Agent 118 außerdem eine schnelle Extraktion der Fuzzy-Schlüssel-Informationen aus dem Dateinamen und ein Senden dieser zu dem Server-Agent 160 während eines anfänglichen Bootens des Client 110 oder beim Start der Client/Server-Sitzung. Die extrahierten Fuzzy-Schlüssel können in einer Reihenfolge zu dem Server 150 übertragen werden, die zum Beispiel auf den am-wenigsten-jüngst-verwendet- und/oder am-wenigsten-häufig-verwendet-Informationen basiert, die auch einen Teil des Dateinamens bilden.
Bei einer Ausführungsform werden die Fuzzy-Schlüssel 419 in einer von drei Weisen zu der Fuzzy-Datenbank 418 hinzugefügt und aus dieser gelöscht. Erstens sendet beim Herauffahren des Client-Agent 118 oder bei Herstellung einer Client-Server-Sitzung mit dem Server-Agent 160 der Client-Agent 118 Befehle zu dem Server-Agent 160, um für jede entsprechende Bitmap 422 in der persistenten Speicherung 120 des Client (die Fuzzy-Schlüssel begleiten die Befehle des Client-Agent) Befehle zu dem Server-Agent 160 hinzuzufügen. Der Client-Agent 118 kann eine Sendeliste führen, die für das Senden von Fuzzy-Schlüsseln beim Herauffahren zu dem Server 150 eine Reihenfolge spezifiziert (z.B. auf der Basis von aus vorherigen Client-Server-Sitzungen bestimmten zuletzt-benutzt- oder am häufigsten-benutzt-Informationen). Die Sendeliste kann von dem Client-Agent 118 beim Lesen des Verzeichnisses seiner persistenten Speicherung 120 und dem Führen einer Repräsentation des Verzeichnisses in dem flüchtigen Speicher 114 gebildet werden. In einem Aspekt der Erfindung extrahiert der Client-Agent 118 Fuzzy-Schlüssel-Informationen aus dem Dateinamen der Datei, die die Bitmap 422 enthält, wenn die Repräsentation des Verzeichnisses erstellt wird. In vorbestimmten Abfrageintervallen fragt zweitens der Client-Agent 118 seine persistente Speicherung 120 ab, um die Bitmaps zu bestimmen, die sich gerade in seiner persistenten Speicherung 120 befinden (z.B. durch Suchen nach Dateinamen, die eine fuzzy-schlüssel-artige Struktur enthalten) und sendet dann Hinzufüge- und/oder Löschbefehle zu dem Server-Agent 160, so wie es notwendig ist, um die Fuzzy-Datenbank 418 des Servers zu aktualisieren. Wenn der Server-Agent 160 einen Befehl zum Schreiben einer Bitmap in die persistente Speicherung 120 des Client zu dem Client-Agent 118 sendet, erzeugt und speichert drittens der Server-Agent 160 einen entsprechenden Fuzzy-Schlüssel 419 in der Fuzzy-Datenbank 418.
Die Übertragung von Bitmap-Daten von dem Server 150 zu dem Client 110 kann einen relativ großen Zeitraum in Anspruch nehmen, insbesondere wenn die Netzwerkverbindung zwischen Client und Server relativ langsam ist. Bei einer Ausführungsform paßt die Erfindung die Funktionsweise des Servers an sich ändernde Netzwerkbedingungen an, indem die relative Geschwindigkeit des Netzwerks 140 bestimmt wird. Zum Beispiel kann der Server-Agent 180 durch dynamisches Bewerten der Bandbreite des Netzwerks 140 die Codierungs- und Komprimierungstechniken modifizieren, mit denen Bitmapdaten verarbeitet werden, um Bandbreitenanforderungen bei der Übertragung über ein langsames Netzwerk zu verringern. Die Erfindung verarbeitet Spalten von Bitmapdaten von links nach rechts und bereitet den Client-Cache 114 entsprechend vor. Während die codierte Bitmap 414 übertragen wird, kann die Übertragungszeit überwacht werden, um die Leistungsfähigkeit des Netzwerks 140 zu bestimmen. Wenn die Übertragungszeit einen Schwellenwert übersteigt, kann der Client-Agent 118 jegliche bereits in seinem Cache 114 gespeicherten Bitmap-Daten entnehmen und die übrigen Teile der Bitmapdaten entweder in Echtzeit, während sie in dem Cache 114 empfangen werden, oder in vorbestimmten Intervallen anzeigen. Auf diese Weise erkennt ein Benutzer des Clients, daß der Client 114 immer noch an den Bitmapdaten operiert und kann erkennen, daß sich der Client 110 nicht in einem Häng- oder erfolglos-/Fehler-Zustand befindet. Durch Approximieren der effektiven Netzwerkbandbreite für den Client 110 und entsprechendes Anpassen des Verhaltens des Servers 150 kann der Server-Agent 160 zum Beispiel den Client-Agent 118 anweisen, im Gegensatz zu einem Ganze-Spalte-Modus der Anzeige für eine bestimmte Bitmap einen ganze-Bitmap-Modus zu verwenden.
Genauer gesagt sendet der Server-Agent 160 einen Start_StopWatch-Befehl, gefolgt durch die codierten Bitmapdaten 414 und einen Start_StopWatch-Befehl zu dem Client-Agent 118. Der Client-Agent 118 reagiert auf den Start_StopWatch-Befehl, indem er den aktuellen Zeit-Tick liest und ihn in ein erstes Arrayelement schreibt. Nachdem die codierte Bitmap 414 empfangen wurde, reagiert der Client-Agent 118 auf den Start_StopWatch-Befehl, indem er den aktuellen Zeit-Tick liest und ihn in ein zweites Arrayelement schreibt. Ein Vergleich der Differenz der Zeit-Ticks zwischen den Befehlen Start_StopWatch und Stop_StopWatch liefert eine Schätzung der Zeit, die benötigt wurde, um die codierten Bitmapdaten zu empfangen. Die resultierende Zeitdifferenz wird dann zu dem Server-Agent 160 zurück übertragen. Diese Prozedur kann wiederholt werden, um einen geglätteten, laufenden Mittelwert zu berechnen, aus dem eine vernünftige Schätzung des effektiven Durchsatzes codierter Bitmapdaten bestimmt werden kann. Die Erfindung verwendet diese Durchsatzschätzung im Hinblick auf die Größe der codierten Daten für eine bestimmte Bitmap, um zu entscheiden, ob der ganze-Bitmap-Modus (z.B. wenn es wahrscheinlich ist, daß es weniger als 5 Sekunden dauert) oder fortschreitende ganze Spalten (z.B. wenn es wahrscheinlich ist, daß es mehr als 5 Sekunden dauert) benutzt werden soll. Obwohl diese Prozedur nicht zu einer 100% genauen Durchsatzschätzung führt, ergibt sie genug Granularität, um schnelle oder langsame Netzwerkverbindungen zu erkennen, aus denen verschiedene Anzeigearten bestimmt werden können. Mit einer ähnlichen Technik kann man die Zeit für große Schirm-zu-Schirm-Kopien am Clientende messen und eine ähnliche laufende Mittelwertschätzung der Leistungsfähigkeit des Client während dieser Operationen konstruieren, mit der man dann einen Producer-Thread auf dem Server 150 verlangsamen und ein Überlaufen an der Quelle verhindern kann, wenn der Server 150 Daten schneller erzeugt, als der Client 110 handhaben kann.
Bei einer Ausführungsform bildet die Erfindung Objekte, die groß genug sind, um die Daten einer gesamten Cache-Spalte zu enthalten. Zum Beispiel können die maximale Objektgröße und die Größe des Cache vom Server-Agent 160 beim Herauffahren der Client-Server-Sitzung als Funktion der Größe des Verbindungsfensters und seiner Farbtiefe auswählen, wobei für größere Schirmbilder und Tiefen größere Größen zugeteilt werden. Ferner können derzeitige Techniken zum Zerlegen einer Bitmap in Spalten zu Spalten mit einer Breite an einem oder beiden Enden der Bitmap führen, die kleiner als der Standard ist. Wenn diese vom Standard abweichenden Spalten zu schmal sind, sind sie möglicherweise nicht groß genug, um in der persistenten Speicherung 120 des Client behalten zu werden und werden also während nachfolgender Client/Server-Sitzungen nicht in dem Client 110 vorhanden sein. Die Erfindung vermeidet dieses Problem durch Zusammenführen der schmalen Spalten mit benachbarten Spalten, so daß nur breite Spalten verwendet werden und somit zum Beispiel alle Teile eines Splash-Schirmbilds in der persistenten Speicherung 120 enthalten sein werden. Bei einer Ausführungsform werden ganze Spalten dann in zwei Phasen angezeigt. Die erste Phase bereitet den Cache 114 mit etwaigen fehlenden Daten vor und die zweite Phase entnimmt dann die Spalte aus dem Cache 114, wobei möglicherweise mehr als ein Cache-gespeichertes Objekt benutzt wird. Die Spalte wird deshalb auf atomische Weise auf dem Anzeigeschirm 128 angezeigt. Wenn die Netzwerkverbindung langsam ist, können wie bereits besprochen die Spalten einzeln atomisch angezeigt werden, um dem Benutzer an dem Client 110 zu versichern, daß das System noch arbeitet. Alternativ dazu kann die gesamte Bitmap atomisch unter Verwendung einer ähnlichen Technik angezeigt werden, wenn eine schnelle Netzwerkverbindung erkannt wird.
Die oben besprochene Technik der laufenden Mittelwertschätzung kann auch dazu verwendet werden, schon lange existierende Überrollprobleme in einer Anwendung, die auf einem schnellen Server ausgeführt wird und die auf einem relativ langsamen Client angezeigt wird, zu lindern. Zu dem Überrollproblem kommt es zum Beispiel, wenn ein Benutzer des Client 110 mehrere Rollbefehle einleitet wie zum Beispiel durch mehrmaliges Anklicken der Rolleiste (oder Ziehen der Rolleiste) mit einer Maus 126. Da die Rollbefehle zu dem schnellen Server gesendet werden, führt der Server 150 die Rolloperationen aus und gibt die assoziierten Daten schneller zurück, als der langsame Client 110 (oder das langsame Netzwerk 140) die Ergebnisse auf seinem Anzeigeschirm 128 anzeigt. Wenn der Benutzer an dem Client 110 danach schließlich die gewünschte Schirmposition betrachtet und das Rollen stoppen möchte (durch Aufhören der Mausklicks und/oder dem Ziehen der Rolleiste), rollt die Anzeige weiter über die gewünschte Schirmposition hinaus. Dieser Überrollzustand entsteht, weil der schnelle Server 150 bereits die Rollbefehle verarbeitet und die entsprechenden Daten zu dem Client 110 zurückübertragen hat, aber die Daten an dem langsamen Client in eine Warteschlange eingereiht und noch nicht ganz verarbeitet wurden.
Die Erfindung lindert dieses Überrollproblem durch Verringern seiner Häufigkeit des Auftretens. Genauer gesagt mißt die Erfindung periodisch die Zeit für gewählte Rollereignisse in dem Server 150 (durch Rollen des Rahmenpuffers) und im Client 110 (über die oben beschriebenen StopWatch-Befehle), um eine laufende Mittelwertschätzung ihrer jeweiligen Geschwindigkeiten zu berechnen. Auf diese Weise schätzt der Server-Agent 160, wie lange ein bestimmtes Rollereignis dauern wird (Geschwindigkeit mal die Anzahl beteiligter Pixel), um im Server 150 verarbeitet zu werden, und wie lange erwartungsgemäß der Client 110 brauchen wird, und wenn die erwartete Verarbeitungszeit im Client 110 größer als die des Servers 150 ist, wird die Serververarbeitung durch die entsprechende Zeitdifferenz suspendiert, um so Client 110 und Server 150 im wesentlichen im Gleichschritt zu halten. Dieser Ansatz führt zu viel weniger Überrollereignissen aufgrund der Zeitverzögerung zwischen Client 110 und Server 150 im Vergleich zu der Anzahl von Überrollereignissen, die auftritt, wenn dieser Ansatz nicht implementiert wird.
Zusätzlich zu der Manipulation von Bitmapdaten kann die vorliegende Erfindung auch eine auf dem Server 150 erzeugte Textkette zu der Anzeige 128 des fernen Client 110 remoten. Mit Bezug auf 6 führt der Server 150 das Anwendungsprogramm 158 aus, das eine Textkette erzeugt, die zu dem Client 110 geremotet werden muß. Der Server-Agent 160 fängt die von dem Anwendungsprogramm 158 zu dem Serverbetriebssystem 156 gesendeten Befehle ab, die die Textkette betreffen und bewirkt, daß der Anzeigetreiber 612 des Server-Agent 160 die textbezogenen Informationen verarbeitet und eine Reihe von Protokollbefehlen 614 für die Anzeige einer Textkette 416 auf der Anzeige 128 des Clients einer Reihe von Protokollbefehlen 614 zu dem Client-Agent 118 zu senden. Zum Beispiel führt die Anwendung 158 Prozeduraufrufe aus, die die Textfarbe und die Hintergrundfarbe (hier „Hello!") setzen. Die Ausführung der TextOut-Prozedur 618 durch die Anwendung 158 löst die Ausführung der DrvTextOut-Prozedur 620 des Anzeigetreibers 612 aus. Wie gezeigt, definiert die DrvTextOut-Prozedur 620 die Clip-Region, das Grenzrechteck und den Textmodus (einschließlich Hintergrund- und Textfarbe) durch Ausführen einer Sequenz entsprechender Prozeduren.
Die Ausführung solcher Prozeduren bewirkt, daß der Anzeigetreiber 612 die entsprechenden Daten und Protokollbefehle (wie zum Beispiel eine Teilmenge der in Tabelle 1 angegebenen) zu dem Client-Agent 118 sendet. Die Protokollbefehle werden von dem Client-Agent 118 empfangen und verarbeitet und er führt Prozeduren 614 aus, die die Clip-Region, das begrenzende Rechteck, den Textmodus und das jedem anzuzeigenden Textzeichen zugeordnete Glyph spezifizieren. Man beachte, daß das einem Glyph-Objekt zugeordnete Protokoll nicht nur die Glyph-Bitmap selbst codiert, sondern auch ihre relativen Positionierungsinformationen. Der Server 150 kann außerdem andere Protokollbefehle zu dem Client-Agent 118 senden, die den Client-Agent 118 anweisen, die zugeordnete Glyphen in dem flüchtigen Speicher 114 und/oder in der persistenten Speicherung 120 wie zuvor beschrieben zu speichern. Der Client-Agent 118 erzeugt eine Bitmap, die der Größe des begrenzenden Rechtecks entspricht, das die Textkette umgibt, und setzt die Relativpositionen jedes Glyph an seine ordnungsgemäße Position innerhalb des begrenzenden Rechtecks. Nachdem das letzte Glyph empfangen und seine Position gesetzt wurde, weist der Client-Agent 118 das Client-Betriebssystem 116 an, die Bitmap auf dem Anzeigeschirm 128 des Client 110 zu zeichnen bzw. zu rendern.
Die vorliegende Erfindung unterstützt außerdem mehrere verschiedene Beschreibungen von Wegen (einer Menge von Linien oder Kurven, die als Teil der Beschreibung einer Linienzeichnungsoperation oder im Fall eines geschlossenen Weges zum Beschreiben einer Region verwendet wird), darunter Ellipsen, Beziers, Segmente, Streifen und Styles. Segmente bedeuten Liniensegmente, die bei Kombination einen Weg bilden. Ähnlich können Segmente weiter zu Streifen analysiert werden, die Teile des Liniensegments sind (entsprechend einer Reihe aufeinanderfolgender Pixel), die dieselben Winkeleigenschaften aufweisen. Die Codierungstechnik, mit der zum Beispiel Streifen repräsentiert werden, verwendet Relativortsinformationen und quantisierte Winkel zur Charakterisierung aufeinanderfolgender Streifen in bestimmten Liniensegmenten, wodurch nicht nur die Menge an graphischen Liniendaten minimiert wird, die codiert werden müssen, sondern auch eine besser wiederholbare Sequenz von Daten entsteht, die effizienter komprimiert werden kann. Die Zunahme der Wiederholbarkeit wird besonders verstärkt, wenn Streifen repräsentiert werden, die eine Form wie etwa ein Rechteck oder einen Kreis bilden. Das für Streifen verwendete Protokoll ermöglicht dem Client-Agent 118 außerdem, einen Weg unabhängig und ohne Kenntnis des von dem Server-Agent 160 zum Umsetzen des Weges in eine Sequenz von Pixel verwendeten Algorithmus genau wiederzugeben.
Mit Bezug auf das nicht einschränkende Beispiel in 7A umfaßt ein Weg 700 zwei Liniensegmente 710, 720, die perfekt linear zu sein scheinen. Für Fachleute ist jedoch erkennbar, daß Liniesegmente, die nicht perfekt horizontal, vertikal oder 45 Grad diagonal liegen, durch eine entsprechende Reihe von Streifen approximiert werden müssen, wenn der Weg 700 auf einem Anzeigeschirm 128 angezeigt wird (1). Diese Approximation ist notwendig, weil die einzelnen Pixel auf dem Anzeigeschirm 128 von höchstens acht anderen Pixeln umgeben werden, die entweder perfekt horizontal, vertikal oder 45 Grad diagonal relativ zueinander liegen und alle Liniensegmente 710, 720, die in einem anderen Gesamtwinkel liegen, müssen also durch eine Reihe von Streifen approximiert werden. Folglich und mit Bezug auf den beispielhaften Weg 700 von 7B besteht das Segment 710 aus vier Streifen 712, 714, 716, 718, wobei die einzelnen Pixel (durch quadratische Blöcke abgebildet) jedes Streifens 712, 714, 716, 718 in 45-Grad-Diagonalen relativ zueinander organisiert sind und das Segment 720 besteht aus fünf Streifen 722, 724, 726, 728, 730 wobei die einzelnen Pixel jedes Streifens 722, 724, 726, 728, 730 horizontal relativ zueinander organisiert sind.
Bei einer Ausführungsform und mit Bezug auf 7B und 8A analysiert der Server-Agent 160 den Weg 700 zu Liniensegmenten 710, 720, die jeweils eine bestimmte Länge und einen bestimmten Winkel aufweisen (Schritt 810). Dann wird ein Array von Liniensegmenten gebildet, um quantisierte Segmentinformationen (die im folgenden als ein quantisierter Winkel oder „QA" bezeichnet werden) für jedes Liniensegment 710, 720 zu speichern (Schritt 820). Anstatt den einem bestimmten Segment 710, 720 zugeordneten Absolutwinkel zu berechnen, bestimmt der Server-Agent 160 auch mit Bezug auf 8B statt dessen, in welchen der 16 quantisierten Winkel 880 der absolute Winkel liegt. Diese Quantisierungstechnik bestimmt, in welchen sechzehn der Umrandung der Endpunkt für ein Liniensegment beginnend mit der Mitte eines Kreises (einem Radius) liegt. Diese Informationen können als das vorzeichenlose Delta aus dem letzten in diesem Kontext spezifizierten Segment ausgedrückt werden (Mod 16, initialisiert auf 0). Diese Technik führt zu einer wiederholbareren Sequenz (als bei Verwendung des Absolutwinkels), insbesondere wenn die Segmente eine Form wie etwa ein Rechteck oder einen Kreis bilden.
Der Server-Agent 160 analysiert dann jedes Liniensegment 710, 720 zu Streifen (712, 714, 716, 718; 722, 724, 726, 728 bzw. 730) (Schritt 830). Die Länge jedes Streifens eines bestimmten Segments 710, 720 wird danach in einem Streifenlängenarray zur weiteren Verarbeitung gespeichert (Schritt 840). Bei einer Ausführungsform wird der Algorithmus bLine von Windows NT zum Zerlegen des Weges 700 in ein Array von Streifen verwendet. Der NT-Algorithmus bestimmt den quantisierten Winkel jedes Streifens und Segments, so daß Segmenten oder Streifen, die auf einer Grenze zwischen quantisierten Winkelbereichen liegen, keine Mehrdeutigkeit zugeordnet ist. Der NT-Algorithmus klappt eine nach oben gehende Linie so senkrecht um, daß die Linie immer nach unten geht (der y-Wert nimmt weiter zu) und setzt das Flag FL_FLIP_V. Ähnlich wird eine nach links gehende Linie horizontal so umgeklappt, daß sie immer nach rechts geht (der x-Wert nimmt immer zu) und setzt das Flag FL_FLIP_H. Das von diesem Algorithmus ausgegebene Array von Streifen fällt folglich in einen einzigen Quadranten. Bei dieser konkreten Ausführungsform macht der Server-Agent 160 die Umklappoperation des NT-Algorithmus rückgängig, so daß das Array von Streifen wieder auf ihre vorherigen/ursprünglichen quantisierten Winkel zurückgeklappt wird, um sicherzustellen, daß die Endpunkte eines vorherigen Streifens und der Startpunkt des nächsten nachfolgenden Streifens zusammenfallen, um so zu vermeiden, die Startkoordinate des nächsten nachfolgenden Streifens senden zu müssen.
Der Server-Agent 160 codiert dann die Anfangskoordinate des Weges 700 zusammen mit den quantisierten Winkeldaten in dem Liniensegmentarray und Pixellängendaten in dem Streifenmengenarray, um einen Protokollstrom zu bilden (Schritt 850). Die codierten Daten werden dann einem Kompressionsalgorithmus unterzogen, um die Datenredundanzen in dem Protokollstrom auszunutzen (Schritt 860), und die komprimierten graphischen Liniendaten werden danach zur Decodierung und weiteren Verarbeitung zu dem Client-Agent 118 gesendet (Schritt 870).
Mit Bezug auf die beispielhafte Darstellung in 9 und die quantisierten Winkelinformationen von 10 umfaßt das Liniensegment 710 vier Streifen 712, 714, 716, 718, die innerhalb des quantisierten Winkels 1 positioniert sind. Die Anfangskoordinate des Weges 700, die von dem Server-Agent 160 als Teil der komprimierten graphischen Liniendaten zu dem Client-Agent 118 gesendet werden, entsprechen dem ersten Pixel im Streifen 712 (positioniert am Ursprung von 880). Die graphischen Liniendaten umfassen ferner die Pixellänge jedes Streifens 712, 714, 716, 718 in dem Segment 710.
Da das Segment 710 keiner perfekten Horizontalen, Vertikalen oder 45-Grad-Diagonalen entspricht, wird jeder nachfolgende Streifen 714, 716 und 718 in dem Segment 710 wie in 10 angegeben um einen bestimmten Deltawert eingestellt, um den Gesamtwinkel des Segments 710 ordnungsgemäß zu approximieren. Bei dem vorliegenden Beispiel zeigt der Client-Agent 118, um von dem letzten Punkt in dem vorherigen Streifen 712 zu dem Anfangspunkt des nächsten nachfolgenden Streifen 714 zu gelangen, den Streifen 714 im wesentlichen bei demselben x-Wert und bei einem zunehmenden y-Wert an. Dieser Prozeß wird für jeden Schritt in dem Segment 710 sowie für die Streifen in dem Segment 720, die innerhalb des QA 15 positioniert sind, wiederholt.
Entsprechend und bei einer Ausführungsform umfaßt der von der vorliegenden Erfindung bei der Verarbeitung von Streifen erzeugte Protokollstrom die Startposition des Weges, einen (etwaigen) Index, der einer Speicherstelle in dem flüchtigen Speicher 114 (1) des Client entspricht, die bereits möglicherweise einen zu einem bestimmten früheren Zeitpunkt in der Client-Server-Sitzung gesendeten bestimmten Streifen speichern kann, die Anzahl der Segmente in dem Weg, den quantisierten Winkel jedes Segments (woraus die in 10 wiedergegebenen Deltawerte bestimmt werden), die Länge jedes Streifens zusammen mit bestimmten Steuerinformationen und quantisierte Winkeldeltainformationen, die zu dem quantisierten Winkel eines ersten oder vorherigen Segments addiert werden, um den Client-Agent 118 über den quantisierten Winkel nachfolgender Segment zu informieren. Auf diese Weise vermeidet die Erfindung, Koordinaten- und Absolutwinkelinformationen für jeden Streifen in dem Weg senden zu müssen. Ferner ermöglicht die oben besprochene Streifenverarbeitungstechnik die effiziente Komprimierung graphischer Liniendaten durch Ausnutzen der sich wiederholenden Beschaffenheit der Daten in dem unkomprimierten Protokollstrom.
Die vorliegende Erfindung kann auch auf Bitmaps angewandt werden, die in einer Onscreen-Oberfläche angezeigt werden, und auch auf Bitmaps in einer Außerbildschirm-Oberfläche (z.B. die in dem Speicher eines Videoanzeigeadapters und/oder in einem im voraus zugeteilten Teil des flüchtigen Speichers 114 des Client gespeichert werden, woran durch eine Graphikumsetzungsbibliothek operiert werden wird). Außerbildschirm-Oberflächen werden häufig von Anwendungen wie zum Beispiel Microsoft Word gebildet, die Bitmaps in die Außerbildschirm-Oberfläche schreiben, bis die Oberfläche vollständig ist, und an diesem Punkt wird die Außerbildschirm-Oberfläche auf dem Anzeigeschirm 128 des Client 110 in Endform wie eine Onscreen-Oberfläche angezeigt. Außerbildschirm-Oberflächen liefern deshalb häufig die Quelle für Onscreen-Oberflächen.
Bei einer Ausführungsform und mit Bezug auf Außerbildschirm-Oberflächen informiert der Client-Agent 118 den Server-Agent 160 über die Menge an für Außerbildschirm-Oberflächen verfügbarem lokalen flüchtigen Speicher 114, so daß der Server-Agent 160 keine Außerbildschirm-Oberfläche bildet, die größer als der verfügbare Speicher des Clients ist. Danach bildet der Server-Agent 160 eine Außerbildschirm-Oberfläche und sendet sie mit Anweisungen zum Speichern der Oberfläche in dem flüchtigen Speicher 114 des Client-Agent 118 zu dem Client-Agent 118. Der Client-Agent 118 wählt einen bestimmten Teil seines flüchtigen Speichers 114 und teilt diesen der Oberfläche zu und speichert die Oberfläche darin. Jede Außerbildschirm-Oberfläche besitzt eine Menge zugeordneter Attribute, wie zum Beispiel eine Kennung, die die Oberfläche eindeutig identifiziert, ein Pixelformat, Abmessungen, Zeichnungsattribute, Protokollzustand usw.
Um den flüchtigen Speicher 114 des Clients effizient zu benutzen, kann der Server-Agent 160 bei einer Ausführungsform Befehle an den Client-Agent 118 ausgeben, die anweisen, daß bestimmte Operationen an der Außerbildschirm-Oberfläche nur dann ausgeführt werden, wenn die Außerbildschirm-Oberfläche mit der Onscreen-Oberfläche in Wechselwirkung tritt (z.B. beim Aktualisieren der Onscreen-Oberfläche mit Bitmapdaten von der Außerbildschirm-Oberfläche). Wenn die einzige Interaktion zwischen der Onscreen-Oberfläche und der Außerbildschirm-Oberfläche eine letzte Kopie zu dem Schirm ist, können die Operationen auf die Onscreen-Oberfläche abgezielt werden und verringern somit die Menge an Bitmapdaten, die über das Netzwerk 140 übertragen werden muß. Alternativ dazu kann die Quelle der Onscreen-Oberfläche so eingeschränkt werden, daß sie entweder einer fern im Server 150 gespeicherten Außerbildschirm-Oberfläche oder einer lokal in dem Client 110 gespeicherten Außerbildschirm-Oberfläche entspricht. Zu typischen Operationen an der Außerbildschirm-Oberfläche, die von dem Server-Agent 160 angefordert werden, gehört das Aktualisieren der Bitmap in der Außerbildschirm-Oberfläche mit aktualisierten Text-, Linien- oder anderen Daten.
Bei einer Ausführungsform und mit Bezug auf 11 fängt der Server-Agent 160 an das Server-Betriebssystem 156 gestellte Aufrufe, die die Erzeugung einer Außerbildschirm-Oberfläche betreffen, ab und der Server-Agent 160 bildet ein Duplikat der Oberfläche und speichert es zusammen mit seinen Attributen in dem lokalen Speicher des Servers. Der Server-Agent 160 gibt dann einen Befehl an den Client-Agent 118 aus, die Außerbildschirm-Oberfläche in dem flüchtigen Speicher 114 des Clients zu bilden (Schritt 1102). Den Befehl begleitet eine codierte Repräsentation der Außerbildschirm-Oberfläche, wenn es sich um die erste Instanz der Außerbildschirm-Oberfläche handelt, oder ein Index oder Fuzzy-Schlüssel, wenn die Außerbildschirm-Oberfläche zuvor während der Client-Server-Sitzung übertragen worden ist (Schritt 1104). Der Server-Agent 160 weist den Client-Agent 118 an, die durch den Index bzw. die Fuzzy-Key-Indicia oder codierte Oberfläche identifizierten graphischen Daten in die Außerbildschirm-Oberfläche des Clients zu integrieren (Schritt 1106). Der Client-Agent 118 reagiert auf die Anweisungen des Server-Agent, indem er die identifizierte Oberfläche/Bitmap in die Außerbildschirm-Oberfläche des Clients kopiert (Schritt 1108). Wenn ein von dem Server-Agent 160 ausgegebener BITBLT-Befehl erfolglos bleibt, zum Beispiel eine Bitmap in der Außerbildschirm-Oberfläche des Clients zu bilden, wenn zum Beispiel ein Speicherzuteilungsfehler auftritt, sendet der Client-Agent 118 einen C2S_OSS_Error-Befehl zu dem Server-Agent 160, der den erfolglos-Zustand anzeigt (Schritt 1110). Als Reaktion auf den Fehlerzustand verwendet der Server-Agent 160 seine lokale Kopie der Außerbildschirm-Oberfläche als Quelle für die Aktualisierung der Außerbildschirm-Oberfläche des Clients. Der Client-Agent 118 verwendet die von der lokalen Kopie des Servers empfangenen Informationen zur Aktualisierung der Außerbildschirm-Oberfläche auf dem Client 110 und zur Korrektur etwaiger verfälschter/schmutziger Regionen der Außerbildschirm-Oberfläche. Alternativ sendet, wenn ein Fehlerzustand angetroffen wird, der Server-Agent 160 seine lokale bzw. Duplikatkopie der Außerbildschirm-Oberfläche (Schritt 1112) zu dem Client-Agent 118 und befiehlt dem Client-Agent 118, das Duplikat der Oberfläche als Quelle für die Aktualisierung der Onscreen-Oberfläche des Clients zu verwenden und die verfälschte Außerbildschirm-Oberfläche im Client zu verwerfen (1114).
Obwohl die vorliegende Erfindung mit Bezug auf spezifische Einzelheiten beschrieben wurde, ist nicht beabsichtigt, daß solche Einzelheiten als den Schutzumfang der Erfindung einschränkend betrachtet werden sollen, außer insofern, als sie in den beigefügten Ansprüchen enthalten sind.

Claims

Verfahren zum effizienten Verringern der Menge an sich wiederholenden graphischen Daten, die zu einer abgesetzten Anzeigeeinrichtung (128) übertragen werden, wobei das Verfahren die folgenden Schritte umfaßt: Durchsuchen einer Tabelle (411) nach einem Index (416), der einem graphischen Datenelement zugeordnet ist, wobei die Anwesenheit des Index (416) in der Tabelle (411) eine vorherige Übertragung des graphischen Datenelements anzeigt; dadurch gekennzeichnet, daß das Verfahren weiterhin die folgenden Schritte umfaßt: wenn der Index (416) nicht in der Tabelle (411) gefunden werden kann, Durchsuchen einer Fuzzy-Datenbank (418) nach einem dem graphischen Datenelement zugeordneten Fuzzy-Schlüssel (419), wobei die Anwesenheit des Fuzzy-Schlüssels (419) in der Fuzzy-Datenbank (418) eine Wahrscheinlichkeit anzeigt, daß das graphische Datenelement in einem an die abgesetzte Anzeigeeinrichtung (128) angekoppelten persistenten Speicher (120) gespeichert ist; und wenn der Fuzzy-Schlüssel (419) gefunden wird, Übertragen des Fuzzy-Schlüssels zu einem dem persistenten Speicher (120) und der abgesetzten Anzeigeeinrichtung (128) zugeordneten Agent (118).
Verfahren nach Anspruch 1, wobei das graphische Datenelement einer codierten Bitmap entspricht.
Verfahren nach Anspruch 1, wobei das graphische Datenelement einer Glyphe entspricht.
Verfahren nach Anspruch 1, wobei das graphische Datenelement einem Streifen entspricht.
Verfahren nach Anspruch 1, wobei das graphische Datenelement einer Außerbildschirm-Oberfläche entspricht.
Verfahren nach Anspruch 1, wobei der Index (416) eine Speicherstelle in einem an die abgesetzte Anzeigeeinrichtung (128) angekoppelten Cache (114) identifiziert, wobei der Agent (128) die vorherige Übertragung des graphischen Datenelements zuvor an der Speicherstelle gespeichert hat.
Verfahren nach Anspruch 6, wobei die Größe des graphischen Datenelements nicht größer als eine maximale Cache-Objektgröße ist.
Verfahren nach Anspruch 1, wobei der Fuzzy-Schlüssel (419) einer Länge des graphischen Datenelements entspricht.
Verfahren nach Anspruch 1, weiterhin mit dem folgenden Schritt: Empfangen mehrerer Fuzzy-Schlüssel (419) von dem Agent (118) als Reaktion auf das Einleiten einer Session mit dem Agent (118).
Verfahren nach Anspruch 1, weiterhin mit dem folgenden Schritt: periodisches Empfangen mehrerer Fuzzy-Schlüssel (419) von dem Agent (118).
Verfahren nach Anspruch 1, weiterhin mit dem folgenden Schritt: wenn der Index (416) gefunden wird, Übertragen des Index (416) zu dem Agent (118).
Verfahren nach Anspruch 1, weiterhin mit den folgenden Schritten: wenn der Fuzzy-Schlüssel (419) nicht gefunden werden kann, Bilden des Fuzzy-Schlüssels (419); Speichern des Fuzzy-Schlüssels (419) in der Fuzzy-Datenbank (418); Übertragen des graphischen Datenelements zu dem Agent (118); und Anweisen des Agent (118), das graphische Datenelement in einem an den Agent (118) angekoppelten flüchtigen Speicher (114) zu speichern.
Verfahren nach Anspruch 12, weiterhin mit dem folgenden Schritt: Speichern des graphischen Datenelements in einer in dem persistenten Speicher (120) verankerten Datei, wobei die Datei einen Dateinamen aufweist, der dem Fuzzy-Schlüssel (419) entspricht.
Verfahren nach Anspruch 1, weiterhin mit dem folgenden Schritt: Anweisen des Agent, das graphische Datenelement aus dem persistenten Speicher in einen an den Agent (118) und die abgesetzte Anzeigeeinrichtung (128) angekoppelten Cache zu kopieren.
Verfahren nach Anspruch 14, weiterhin mit dem folgenden Schritt: wenn der Agent das graphische Datenelement nicht kopieren kann, Übertragen des graphischen Datenelements und einer Behebungsmarkierung zu dem Agent.
Verfahren nach Anspruch 1, weiterhin mit den folgenden Schritten: Einreihen eines dem graphischen Datenelement zugeordneten Befehls zusammen mit mehreren anderen Befehlen in einer Warteschlange; Bestimmen, ob der eingereihte, dem graphischen Datenelement zugeordnete Befehl mindestens einen der mehreren anderen eingereihten Befehle ablöst; und wenn bestimmt wird, daß der eingereihte, dem graphischen Datenelement zugeordnete Befehl den mindestens einen der mehreren anderen eingereihten Befehle ablöst, Entfernen des mindestens einen der mehreren anderen eingereihten Befehle aus der Warteschlange.
Verfahren nach Anspruch 16, wobei der eingereihte, dem graphischen Datenelement zugeordnete Befehl nach dem mindestens einen der mehreren anderen eingereihten Befehle in der Warteschlange plaziert ist.
Verfahren nach Anspruch 1, weiterhin mit den folgenden Schritten: wenn das dem übertragenen Fuzzy-Schlüssel (419) zugeordnete graphische Datenelement nicht gefunden werden kann, speichert der Agent (118) einen dem graphischen Datenelement zugeordneten Befehl zusammen mit mehreren später empfangenen Befehlen in einer an den Agent (118) angekoppelten Warteschlange; Empfangen des graphischen Datenelements; und Verarbeiten des dem graphischen Datenelement zugeordneten Befehls und mindestens eines Teils der in der Warteschlange gespeicherten später empfangenen Befehle.
System zum effizienten Verringern der Menge an sich wiederholenden graphischen Daten, die zu einer abgesetzten Anzeigeeinrichtung (128) übertragen werden, wobei das System folgendes umfaßt: eine Tabelle (411), die einen Index (416) speichert, der einem graphischen Datenelement zugeordnet ist, wobei die Anwesenheit des Index (416) in der Tabelle (411) eine vorherige Übertragung des graphischen Datenelements anzeigt; dadurch gekennzeichnet, daß das System weiterhin folgendes umfaßt: eine Fuzzy-Datenbank (418), die einen dem graphischen Datenelement zugeordneten Fuzzy-Schlüssel (419) speichert, wobei die Anwesenheit des Fuzzy-Schlüssels (419) in der Fuzzy-Datenbank eine Wahrscheinlichkeit anzeigt, daß die graphischen Daten in einem an die abgesetzte Anzeigeeinrichtung (128) angekoppelten persistenten Speicher (120) gespeichert sind; und einen Server-Agent (160), der im Betrieb dafür ausgelegt ist, die Fuzzy-Datenbank (418) nach dem Fuzzy-Schlüssel (419) zu durchsuchen, wenn der Index (416) nicht in der Tabelle (411) gefunden werden kann und, wenn der Fuzzy-Schlüssel (419) gefunden wird, den Fuzzy-Schlüssel (419) zu einem dem persistenten Speicher (120) und der abgesetzten Anzeigeeinrichtung (128) zugeordneten Cache zu übertragen.
System nach Anspruch 19, wobei das graphische Datenelement einer codierten Bitmap entspricht.
System nach Anspruch 19, wobei das graphische Datenelement einer Glyphe entspricht.
System nach Anspruch 19, wobei das graphische Datenelement einem Streifen entspricht.
System nach Anspruch 19, wobei das graphische Datenelement einer Außerbildschirm-Oberfläche entspricht.
System nach Anspruch 19, wobei der Index (416) eine Speicherstelle in einem an die abgesetzte Anzeigeeinrichtung (128) angekoppelten Cache (114) identifiziert.
System nach Anspruch 19, wobei die Größe des graphischen Datenelements nicht größer als die maximale Cache-Objektgröße ist.
System nach Anspruch 19, wobei der Fuzzy-Schlüssel einer Länge des graphischen Datenelements entspricht.
System nach Anspruch 19, weiterhin mit einer in dem persistenten Speicher (120) verankerten Datei, wobei die Datei einen Dateinamen aufweist, der dem Fuzzy-Schlüssel entspricht.
System nach Anspruch 19, weiterhin mit einer Warteschlange, wobei der Server-Agent im Betrieb dafür ausgelegt ist, wenn der Fuzzy-Schlüssel nicht in der Fuzzy-Datenbank gefunden werden kann, in einer Warteschlange einen dem graphischen Datenelement zugeordneten Befehl zu speichern, wobei der Client-Agent (118) im Betrieb dafür ausgelegt ist, den zugeordneten Befehl bei Empfang des graphischen Datenelements zu verarbeiten.