DE60109631T2

DE60109631T2 - Verfahren und Vorrichtung zur effizienten Verringerung von graphischen Anzeigedaten für ihre Übertragung mittels eines Übertragungsprotokolls für niedrige Bandbreiten

Info

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

Description

ERFINDUNGSGEBIET
Die vorliegende Erfindung betrifft allgemein die Kommunikation zwischen einem Applikationsserver und einem dünnen Client in einem verteilten System und insbesondere die Reduzierung der Menge graphischer Displaydaten, die über einen Transportprotokollmechanismus mit niedriger Bandbreite übertragen wird.
ALLGEMEINER STAND DER TECHNIK
Verteilte Computersysteme verwenden die Technik des Verteilens der Applikationsausführung. Insbesondere führt ein Applikationsserver lokal ein Applikationsprogramm aus und liefert die Applikationsausgangsdaten an Clients/Netzbenutzer, die dann die Ergebnisse auf einem an ihrem lokalen Computer angekoppelten Displayschirm anzeigen. Durch Durchführen der Applikationsverarbeitungsfunktionen beim Server und Anzeigen der Applikationsausgabe am Client nützen diese verteilten Systeme die Server- und Clientressourcen am besten, d.h., der leistungsfähigere Server führt die rechen- und speicherintensiven Applikationsverarbeitungsfunktionen aus, während der Client, mit potentiell größerer Videoleistung, die Ausgabe anzeigt. Während der Ausführung des Applikationsprogramms betrachtet ein Benutzer des Client die Applikationsausgabedaten auf dem Clientdisplay und interagiert mit dem Applikationsprogramm über Tastatur- oder Mauseingaben. Die Eingaben des Clientbenutzers entsprechen Anforderungen an den Applikationsserver, bestimmte Aktionen auszuführen, die den Betrieb des Applikationsprogramms beeinflussen. Der Applikationsserver leitet diese Anforderungen zur weiteren Verarbeitung an die Applikation weiter. Der Applikationsserver fängt auch die Applikationsausgabedaten ab, die von dem Applikationsprogramm erzeugt wurden und in der Regel auf das Betriebssystem des Applikationsservers abzielen, und überträgt die Daten ganz oder teilweise an den Client, um dort angezeigt zu werden. Aus der Perspektive des Benutzers scheint das Applikationsprogramm lokal auszuführen, obwohl es tatsächlich auf einem abgesetzten Server ausgeführt und lediglich lokal angezeigt wird.
Die Leistung von verteilten Systemen hängt zu einem großen Grad von der Fähigkeit des Netzes ab, das den Client und den Server koppelt, und deshalb von der Menge graphischer Daten (entsprechend den Applikationsausgabedaten), die über das Netz übertragen werden. Da der Applikationsserver und die Client-Workstation im allgemeinen nur durch einen Transportmechanismus verbunden sind (wie etwa serielle Leitungen, Telefonleitungen, lokale Netze und Fernnetze), die eine niedrigere Bandbreite besitzen, als ansonsten zur Verfügung stehen würde, wenn das Applikationsprogramm lokal ausgeführt würde, kann die wahrgenommene Leistung des verteilten Systems leiden. Dementsprechend streben Hersteller von verteilten Systemen/Software ständig danach, die Leistung derartiger Systeme zu verbessern.
US-Patent 5,864,711 beschreibt ein System zum Fernsteuern durch einen Server, in einem über ein Kommunikationsnetz an den Server angekoppelten Client einer Außerschirm-Oberfläche.
KURZE DARSTELLUNG DER ERFINDUNG
Gemäß der Erfindung wird folgendes bereitgestellt: ein Verfahren zum Fernsteuern durch einen Server, in einem über ein Kommunikationsnetz an den Server angekoppelten Client eine Außerschirm-Oberfläche zu bilden, wobei das Verfahren im Server durchgeführt wird und die folgenden Schritte umfaßt: Anweisen des Client, eine erste Speicherregion für eine Zuteilung zu der Außerschirm-Oberfläche zu wählen, wobei die erste Speicherregion einem an den Client angekoppelten Speicher entspricht; Senden von Indicia der graphischen Daten zu dem Client; und Anweisen des Client, die den Indicia zugeordneten graphischen Daten zu einer bestimmten Speicherstelle in der ersten Speicherregion zu kopieren.
Gemäß einem weiteren Aspekt der Erfindung wird auch folgendes bereitgestellt: ein System zum Fernsteuern durch einen Server, in einem über ein Kommunikationsnetz an den Server angekoppelten Client eine Außerschirm-Oberfläche zu bilden, wobei das System folgendes umfaßt: einen auf dem Client ausgeführten Client-Agent; eine an den Client-Agent angekoppelte erste Speicherregion; eine in der ersten Speicherregion gespeicherte Außerschirm-Oberfläche; einen auf dem Server ausgeführten und an den Client-Agent angekoppelten Server-Agent; und graphische Daten, wobei die graphischen Daten zugeordnete Indicia aufweisen und durch den Client gespeichert werden, und wobei der Server-Agent im Betrieb für folgendes ausgelegt ist: Senden von Indicia der graphischen Daten zu dem Client-Agent; und Anweisen des Client, die erste Speicherregion für eine Zuteilung zu der Außerschirm-Oberfläche zu wählen und die den Indicia zugeordneten graphischen Daten zu einer bestimmten Speicherstelle in der ersten Speicherregion zu kopieren.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die vorausgegangene Erörterung läßt sich anhand der folgenden ausführlichen Beschreibung der Erfindung in Verbindung mit den beiliegenden Zeichnungen besser verstehen. Es zeigen:
1 schematisch einen Client-Knoten, der über ein Kommunikationsnetz an einen Server-Knoten angekoppelt ist, wobei der Client- und Server-Knoten jeweils Client- und Server-Agents aufweisen, die gemäß einer Ausführungsform der vorliegenden Erfindung arbeiten;
2 auf hoher Ebene ein Flußdiagramm der von dem Server-Agent von 1 ausgeführten Schritte gemäß einer Ausführungsform der vorliegenden Erfindung;
3 ein ausführlicheres Flußdiagramm für das Diagramm von 2 gemäß einer Ausführungsform der vorliegenden Erfindung;
4 schematisch den Inhalt des flüchtigen und persistenten Speichers des Client und Servers, beeinflußt durch Operationen der Client- und Server-Agents von 1, gemäß einer Ausführungsform der vorliegenden Erfindung;
5 ein Flußdiagramm der Schritte, die unternommen werden, um die von dem Client übertragene Datenmenge zu minimieren, indem Caching-Techniken verwendet werden mit einer Fuzzy-Datenbank und Fuzzy-Schlüsseln gemäß einer Ausführungsform der vorliegenden Erfindung;
6 schematisch eine Menge von Prozeduren, die dazu verwendet werden, von einem Applikationsprogramm auf einem Server erzeugte Textinformationen zu einem Display eines verschobenen Client zu bewegen, gemäß einer Ausführungsform der vorliegenden Erfindung;
7A ein Liniendiagramm, das mehrere einen bestimmten Weg bildende Segmente darstellt;
7B auf Pixelebene eine Darstellung des Liniendiagramms von 7A, die darstellt, wie der Weg auf einem Computerdisplay tatsächlich approximiert wird;
8 ein Flußdiagramm der Schritte, die unternommen werden, wenn Segment- und Streifendaten gemäß einer Ausführungsform der vorliegenden Erfindung verarbeitet und codiert werden;
8B ein Koordinatensystem, das in eine Menge von 16 Regionen organisiert ist, das dazu verwendet wird, Winkelinformationen hinsichtlich Streifen zu quantisieren, und das die Kompressionseffizienz gemäß einer Ausführungsform der vorliegenden Erfindung verbessert.
9 eine Überlagerung des Koordinatensystems von 8B auf die Darstellung von 7B auf Pixelebene, um eine Ausführungsform einer Streifenverarbeitungstechnik gemäß der vorliegenden Erfindung zu veranschaulichen;
10 eine Tabelle, die darstellt, wie man den nächsten Streifen aus dem Endpunkt des vorausgegangenen Streifens erhält, und zwar 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 ausgeführt werden, was die Ausbildung einer Außerschirm-Oberfläche des Client beinhaltet.
AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG
Die vorliegende Erfindung reduziert die Menge graphischer Daten, die zwischen einem Applikationsserver, der ein Applikationsprogramm ausführt, und einem abonnierenden Client, der die Ausgabedaten des Applikationsprogramms örtlich anzeigt, übertragen werden, durch Codieren der Daten in relativ kleine Darstellungen, 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 erhöht die Wiederholbarkeit der Daten innerhalb des Protokollstroms, so daß mit Kompressionsalgorithmen, die an wiederholten codierten Daten effizienter arbeiten, ein größerer Grad an Kompressionseffizienz realisiert werden kann. Die Erfindung verwendet eine Reihe von Techniken, um diese verbesserte Kompression zu realisieren, einschließlich der folgenden: Scannen einer Befehlsschlange für später ausgegebene Befehle, die an die Stelle von früher ausgegebenen Befehlen treten; Disc-Caching-Techniken, die die Kompression von Daten verbessern, die zuvor während einer Client-Server-Sitzung angetroffen wurden; Übertragung relativer Koordinaten unter Verwendung quantisierter Regionen, um zu vermeiden, daß beide Endpunkte und/oder der Winkel eines zugeordneten Streifens gesendet werden; und Manipulation von Außerschirm-Oberflächen, um die Leistung während der Client-Server-Sitzung zu verbessern. Die Erfindung reduziert auch die Häufigkeit von Overscroll-Problemen, die angetroffen werden, wenn eine Leistungsfehlanpassung zwischen einem schnellen Server und einem relativ langsamen Netz oder Client vorliegt.
Unter Bezugnahme auf 1 stehen ein oder mehrere Client-Knoten 110', 110'' (im folgenden wird jeder Client-Knoten oder mehrere Client-Knoten allgemein als 110 bezeichnet) über ein Kommunikationsnetz 140 mit einem oder mehreren Server-Knoten 150', 150'' (im folgenden wird jeder Server-Knoten oder werden mehrere Server-Knoten allgemein als 150 bezeichnet) in Kommunikation. Bei dem Netz 140 kann es sich um ein lokales Netz (LAN), ein Mittelnetz (MAN – medium-area network), oder ein Fernnetz (WAN) wie etwa das Internet oder das World Wide Web handeln. Benutzer des Client-Knoten 110 können über eine Vielzahl von Verbindungen mit dem Netz 140 verbunden sein, einschließlich standardmäßiger Telefonleitungen, LAN- oder WAN-Strecken (z.B. T1, T3, 56kb, X.25), Breitbandverbindungen (ISDN, Frame Relay, ATM) und Funkverbindungen. Die Verbindungen können unter Verwendung einer Vielzahl von Kommunikationsprotokollen hergestellt werden (z.B. TCP/IP, IPX, SPX, NetBIOS und direkte asynchrone Verbindungen). Bei einigen besonders vorteilhaften Ausführungsformen kann das verwendete Protokoll das Independent Computing Architecture-Protokoll sein, das von der Firma Citrix Systems, Inc., in Fort Lauderdale, Florida, USA hergestellt wird, oder das Remote Display Protocol, das von der Firma Microsoft Corporation in Redmond, Washington, USA, hergestellt wird.
Bei dem Client-Knoten 110 kann sich um einen beliebigen PC (z.B. 286, 386, 486, Pentium, Pentium II, Macintosh-Computer), ein Terminal auf Windows-Basis, ein Network-Computer, eine Funkeinrichtung, ein Informationsgerät, ein RISC Power-PC, eine X-Einrichtung, eine Workstation, einen Minicomputer, einen Mainframe-Computer oder irgendeine andere Recheneinrichtung handeln, die einen Desktop auf Windows-Basis und ausreichend Speicher zum Ausführen eines kleinen Displaypräsentationsprogramms aufweist. Das Displaypräsentationsprogramm verwendet Befehle und Daten, die über das Netz 140 von dem Applikationsserver 150 gesendet wurden, um ein graphisches Display wiederzugeben. Bei einem Systemmodell mit verteilten Computern tritt die Ausführung von Applikationsprogrammen in erster Linie in dem Applikationsserver 150 und der Benutzerschnittstelle auf, Tastenanschläge und Mausbewegungen, die von Eingaben auf der Client-Seite erzeugt werden, werden über das Netz 140 zu und von dem Client-Knoten 110 übertragen.
Der Client-Knoten 110 enthält in der Regel einen Prozessor 112, einen flüchtigen Speicher 114 (z.B. RAM-Cache), ein Betriebssystem 116, einen Client-Agent 118, einen persistenten Speicherungsspeicher 120, eine Netzschnittstelle 122 (z.B. eine Netzschnittstellenkarte), eine Tastatur 124, eine Maus 126 und ein Display 128. Zu den von dem Client-Knoten 110 unterstützten Windows-orientierten Plattformen können unter anderem zählen: 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-Knoten 110 empfängt. Der Client-Agent 118 verwendet die empfangenen Informationen, wenn er mit anderen Komponenten des Client-Knoten 110 interagiert (z.B. wenn das Betriebssystem 116 angewiesen wird, Daten auf dem Display 128 auszugeben). Der Client-Agent 118 überträgt auch Anforderungen und Daten an den Server-Knoten 150 als Reaktion auf vom Server erteilte Befehle oder Benutzeraktionen am Client-Knoten 110.
Analog enthält der Server-Knoten 150 einen Prozessor 152, einen flüchtigen Speicher 154, ein Betriebssystem 156, ein Applikationsprogramm 158, einen Server-Agent 160, einen persistenten Speicherungsspeicher 162 und eine Netzschnittstelle 164. Der Server-Agent 160 entspricht einem Softwareprogramm, das mit dem Client-Agent 118 und anderen Komponenten des Server-Knotens 150 gekoppelt ist, um das entfernte Display und die Betätigbarkeit des Applikationsprogramms 158 zu unterstützen. Auf jedem Applikationsserver 150 befinden sich ein oder mehrere Applikationsprogramme 158, auf die durch die Client-Knoten 110 zugegriffen werden kann. Zu Beispielen für solche Applikationen zählen Textverarbeitungsprogramme wie etwa MICROSOFT WORD und Tabellenkalkulationsprogramme wie etwa MICROSOFT EXCEL, beide von Microsoft Corporation in Redmond, Washington, USA hergestellt, Finanzberichtserstellungsprogramme, Kundenregistrierprogramme, Programme, die technische Support-Informationen liefern, Kundendatenbankapplikationen oder Applikationssetmanager. Während der Ausführung des Applikationsprogramms 158 kommuniziert ein Server 150 mit dem Client-Knoten 110 über einen Transportmechanismus (Teil des Server-Agent 160). Bei einer Ausführungsform liefert der Transportmechanismus mehrere virtuelle Kanäle, und einer der virtuellen Kanäle liefert ein Protokoll für die Übertragung von graphischen Schirmdaten von dem Server-Knoten 150 zum Client-Knoten 110. Der Server 150 führt einen Protokolltreiber aus (Teil des Server-Agent 160), der Graphikdisplayschnittstellenbefehle (von dem Applikationsprogramm 158 erzeugt und auf das Betriebssystem 156 des Servers abzielend) abfängt und sie in ein Protokollpaket übersetzt, das sich zur Übertragung über den Transportmechanismus eignet.
Bei einer Ausführungsform und unter Bezugnahme auf 2 fängt der Server-Agent 160 einen von dem Applikationsprogramm 158 erteilten und auf das Betriebssystem 156 abzielenden Graphikdisplayschnittstellenbefehl ab (Schritt 202), codiert den Befehl und dem Applikationsprogramm 158 zugeordnete Graphikdaten (Schritt 204), komprimiert die codierten Graphikdaten (Schritt 206) erzeugt ein Transportprotokollpaket, das den abgefangenen Befehl und komprimierte codierte Daten enthält (Schritt 208) und überträgt das Transportprotokollpaket an den Client-Zielknoten 110 (Schritt 210). Graphische Daten beziehen sich auf eine beliebige Art von Daten, die auf dem Display 128 angezeigt werden können, wie etwa mit Bitmaps, Glyphen, Koordinaten, Liste von Linien, Streifen usw. Im folgenden können Beschreibungen von Techniken, die auf bestimmte Arten graphischer Daten oder graphischer Objekte angewendet werden, so ausgelegt werden, daß sie für alle Arten graphischer Daten gelten.
Insbesondere fängt ein Protokolltreiber des Server-Agent 160 die Graphikdisplayschnittstellenbefehle ab (Schritt 202). Bei einer Ausführungsform fängt der Protokolltreiber von dem Applikationsprogramm 158 gemachte High-Level-Applikationsprogrammierungsschnittstellenanrufe ab. Bei einer Ausführungsform fängt der Protokolltreiber von WINDOWS-basierten Betriebssystemen gelieferte GDI-Befehle ab. Bei einer weiteren Ausführungsform fängt der Protokolltreiber von MAC/OS-basierten Betriebssystemen gelieferte QUICKDRAW-Befehle ab. Bei noch weiteren Ausführungsformen fängt der Protokolltreiber Befehle auf niedrigerer Ebene ab, wie etwa Schnittstellenanrufe an den Gerätetreiber, der dem Graphikdisplay des Server-Knotens 150 zugeordnet ist. Bei noch weiteren Ausführungsformen kann der Graphikdisplayschnittstellenbefehl dupliziert werden anstatt abgefangen zu werden. Bei diesen Ausführungsformen ist das Display der Applikationsprogrammausgabedaten auf dem Server 150 und dem Client 110 im wesentlichen ähnlich, wenn nicht identisch. Der Protokolltreiber erzeugt ein Transportprotokollpaket auf der Basis des abgefangenen Graphikdisplaybefehls (Schritt 208). Der Protokolltreiber kann einen Protokollbefehlsatz verwenden, der einen analogen Befehl für jeden möglichen abgefangenen Displayschnittstellenbefehl enthält. Alternativ kann der Protokolltreiber einen Befehlssatz verwenden, der ein Teilsatz der abgefangenen Displayschnittstellenbefehle ist. Bei anderen Ausführungsformen kann der Protokollbefehlssatz eine Obermenge der möglichen abgefangenen Displayschnittstellenbefehle sein.
Für jeden abgefangenen GDI-Befehl und betroffene Graphikdaten, die zu dem Client-Agent 118 übertragen werden müssen, um die Ausgabe des Applikationsprogramms 158 auf dem Client-Display 128 anzuzeigen, stellt der Server-Agent 160 den verwandten Protokollbefehl zusammen mit einem eindeutigen Schlüssel 412 (4), der den betroffenen Graphikdaten zugeordnet ist, in eine Schlange. Der eindeutige Schlüssel 412 beschreibt und identifiziert eindeutig die Graphikdaten. Bei einer Ausführungsform wird der eindeutige Schlüssel erzeugt durch Ausführen einer zyklischen 64 Bit-Blockprüfung (CRC) an den Graphikdaten. Bei einer weiteren Ausführungsform wird die 64-Bit-CRC als zwei 32-Bit-CRCs erzeugt und sequentiell und in entgegengesetzten Richtungen an den Graphikdaten vorgenommen. Weitere Verfahren zum Erzeugen eines Graphikdaten zugeordneten eindeutigen Schlüssels, wie einem Fachmann bekannt, können ebenfalls verwendet werden. Der Protokollbefehl und der eindeutige Schlüssel 412 werden am Server 150 zusammen mit anderen Mengen aus Befehlen oder eindeutigen Schlüsseln in eine Schlange gestellt. Die aufgereihten Befehle werden dann gescannt, um festzustellen, ob die später erteilten Befehle (d.h. jene näher am hinteren Ende der Schlange) an die Stelle von früher erteilten Befehlen treten (d.h. jenen näher an der Vorderseite der Schlange). Wenn die früher erteilten Befehle ersetzt werden, dann entfernt sie der Server-Agent 160 aus der Schlange und vermeidet dadurch, daß unnötige Daten zu dem Client-Agent 118 übertragen werden müssen.
Beispielsweise muß eine Reihe von Befehlen zum Anzeigen der nächsten Datenseite, die in schneller Reihenfolge erteilt werden, nicht am Client 110 individuell angezeigt werden. Alles was angezeigt werden muß, ist die zuletzt ausgegebene Displayseite, da diese letzte Seite von Daten alle vorausgegangenen Seiten von Daten überschreibt. Indem die unnötigen Befehle und eindeutigen Schlüssel entsprechend den früheren Seiten aus der Schlange des Servers entfernt werden, reduziert der Server-Agent 160 im wesentlichen die Datenmenge, die verarbeitet und übertragen werden muß.
Bei einer veranschaulichenden Ausführungsform werden aus der Schlange des Servers nur unnötige Befehle und verwandte Daten hinsichtlich undurchsichtiger Operationen entfernt. Wenn beispielsweise ein zuvor in die Schlange gestellter Befehl, der die Erzeugung einer rechteckigen Region mit Koordinaten 10,10,50,50 beinhaltet, von einem zu einem jüngeren Zeitpunkt in die Schlange gestellten Befehl gefolgt wird, der die Erzeugung einer größeren/abdeckenden rechteckigen Region mit Koordinaten 0,0,100,100 beinhaltet, dann wird der zuvor in die Schlange gestellte Befehl und die verwandten Daten als unnötig erachtet und aus der Schlange entfernt.
Die nachfolgende Tabelle 1 führt eine beispielhafte Menge von in einer Ausführungsform der Erfindung bereitgestellten Protokollbefehlen auf.
TABELLE 1
Bei einer Ausführungsform werden die Protokollbefehle und assoziierte Graphikdaten so konfiguriert, daß die Wiederholung von Informationen in dem von dem Protokolltreiber erzeugten Protokollpaketstrom maximiert wird. Bei einem Aspekt der Erfindung werden die Graphikdaten zuerst codiert (Schritt 204), bevor die Graphikdaten und/oder Protokollbefehle einen Kompressionsalgorithmus unterzogen werden (Schritt 206), die die wiederholende Art des Protokollstroms nutzt (z.B. kann ein Lempel-Ziv-Kompressionsprotokoll verwendet werden). Bei einer Ausführungsform und bei dem ersten Auftreten der Graphikdaten in der Client-Server-Sitzung wird eine Indicia der Graphikdaten zusammen mit den entsprechenden codierten Daten in dem Protokollstrom übertragen, um die über das Netz 140 übertragene Datenmenge für zukünftige Fälle, daß die Graphikdaten während der gleichen Client-Server-Sitzung auftreten, zu reduzieren. Die komprimierten Daten werden danach in das Transportprotokollpaket gebündelt und zur Dekompression und Interpretation an den Client-Knoten 110 übertragen (Schritt 208). Bei einer veranschaulichenden Ausführungsform führt das Applikationsprogramm 158 einen GDI-Befehl aus, der das Server-Betriebssystem 156 anweist, eine Bitmap zu zeichnen. Der Server-Agent 160 fängt diesen GDI-Befehl ab (Schritt 202) und erteilt dem Client-Agent 118 einen BITBLT-Befehl, der den Client-Agent 118 anweist, die Ausgangsdaten des Applikationsprogramms auf dem Client-Display 128 anzuzeigen. Vor der Erteilung des BITBLT-Befehls codiert der Server-Agent 160 die ausgegebenen Daten (Schritt 204) und nimmt die codierten Daten zusammen mit dem BITBLT-Befehl in den dem Client-Agent 118 übertragenen komprimierten Protokollpaketstrom auf. Bei einer Ausführungsform werden die die Bitmap 410 beschreibenden Daten (4) codiert und komprimiert (Schritte 204 und 206), um einige der in der Bitmap 410 vorliegenden Redundanzen auszunutzen. Beispielsweise kann die Bitmap 410 derart sein, daß aufeinanderfolgende Rasterlinien oder benachbarte Pixel redundant sind.
Zusätzlich zu der Codierung von Bitmaps oder anderen diskreten Graphikdatenelementen auf der Basis ihrer internen Datenredundanzen enthält die Erfindung auch Caching-Techniken, die die Codierung und Kompression von Graphikdaten, die zuvor während einer bestimmten Client-Server-Sitzung angetroffen wurden, weiter verbessert. Wenn beispielsweise eine bestimmte Bitmap zuerst während einer Client-Server-Sitzung angetroffen wird, wird sie wie oben beschrieben codiert. Für nachfolgende Übertragungen der Bitmap während der gleichen Client-Server-Sitzung können Indicia der Bitmap anstelle der relativ größeren codierten Bitmap übertragen werden. Bei einer Ausführungsform entsprechen die Indicia einer Speicherstelle innerhalb des flüchtigen Speichers des Client, der die zuvor übertragene Bitmap enthält.
Insbesondere und unter Bezugnahme auf 3 und 4 erzeugt der Server-Agent den eindeutigen Schlüssel 412 (Schritt 330) wie oben beschrieben und assoziiert den eindeutigen Schlüssel 412 mit den Graphikdaten (z.B. Bitmap 410). Diese Assoziation definiert im wesentlichen die Bitmap 410 und ihre verwandten Daten als ein Graphikobjekt, das danach zusammen mit seinem eindeutigen Schlüssel 412 und codierten Daten 414 in einer Datenstruktur 411 (z.B. einer Tabelle) registriert wird (Schritt 340), die in dem flüchtigen Speicher 154 des Servers gespeichert ist (z.B. dem Server-Cache-Teilsystem). Bei anderen Ausführungsformen können die die Bitmap betreffenden Daten in die persistente Speicherung 162 des Servers geschrieben werden.
Unter der Annahme, daß der Protokollbefehl (z.B. BITBLT) und assoziierte Graphikdaten nicht durch später erteilte Befehle ersetzt werden (wie zuvor beschrieben), entfernt der Server-Agent 160 (Schritt 360) den BITBLT-Befehl und den eindeutigen Schlüssel 412 aus der Warteschlange und durchsucht die im flüchtigen Speicher 154 des Servers gespeicherte Tabelle 411, um zu bestimmen, ob der eindeutige Schlüssel 412 zuvor darin gespeichert wurde. Falls sich der eindeutige Schlüssel 412 innerhalb der Tabelle 411 befindet, dann bestimmt der Server-Agent 160, daß die codierten Daten 414 zuvor von dem Server 150 verarbeitet wurden. Der Server-Agent 160 durchsucht die Tabelle 411 dann nach einem Index oder einem Handle 416, der bzw. das mit der codierten Bitmap 414 assoziiert ist. Falls der Index 416 gefunden wird, dann bestimmt der Server-Agent 160, daß die codierte Bitmap 414 nicht nur von dem Server 150 verarbeitet worden ist, sondern daß sie auch zuvor zu dem Client-Agent 118 übertragen worden ist. Wenn sich der Index 416 nicht in der Tabelle 411 befindet, dann bestimmt der Server-Agent 160, daß die codierte Bitmap 414 nicht zuvor übertragen worden ist.
Bei einer Ausführungsform identifiziert der Index 416 eine bestimmte Speicherstelle innerhalb des flüchtigen Speichers 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 an den Server-Agent 160 bei Initiierung einer Client-Server-Sitzung mit dem Server-Agent 160. Nachdem die Sitzung hergestellt worden ist, steuert der Server-Agent 160 danach die Zuweisung des verfügbaren flüchtigen Speichers 114 des Client. Auf diese Weise kann der Server-Agent 160 den flüchtigen Speicher 114 des Client der codierten Bitmap 114 zuweisen und den Index 416 als einen Zeiger oder eine Referenz auf den zugewiesenen Speicher und als einen Identifizierer der zuvor übertragenen codierten Bitmap 414 beibehalten.
Falls 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 verwandten Protokollbefehl (Schritt 380) und überträgt die komprimierten Daten über das Netz 140 in einem an den Client-Agent 118 adressierten Paket. Bei einer Ausführungsform weist der Index 416 eine geringere Länge (z.B. 16 Bits) als der eindeutige Schlüssel 412 (z.B. 64 Bits) auf und verbraucht deshalb bei der Übertragung weniger Bandbreite. Bei Empfang und Dekompression des komprimierten Pakets greift der Client-Agent 118 auf die jeweilige Speicherstelle in dem flüchtigen Speicher 114 des Client zu, die von dem Index 416 spezifiziert wird, um die entsprechenden Graphikdaten 410 zu erhalten. Der Client-Agent 118 verarbeitet danach die erhaltenen Graphikdaten 410 gemäß dem Befehl, der den Index 416 in dem komprimierten Paket begleitet. Auf diese Weise wird mit der Erfindung vermieden, daß eine relativ große Bitmap oder andere Graphikdaten wieder übertragen werden müssen, die während einer bestimmten Client-Server-Sitzung bereits schon einmal angetroffen worden sind.
Falls sich der Index 416 nicht innerhalb der Tabelle 411 des Servers befindet (und somit nicht zuvor zu dem Client-Agent 118 übertragen worden ist), weist der Server-Agent 160 einen Teil des flüchtigen Speichers 114 des Client für die Bitmap 410 zu und bildet den die Speicherstelle identifizierenden Index 416. Der Server-Agent 160 speichert dann die codierte Bitmap 414 (entsprechend der Bitmap 410), den neu gebildeten Index 416 und den mit der codierten Bitmap 414 assoziierten eindeutigen Schlüssel 412 in der Tabelle 411 des Servers. Der Server-Agent 160 komprimiert danach die codierte Bitmap 414, den Index 416 und den verwandten Befehl und überträgt die komprimierten Daten in einem an den Client-Agent 118 adressierten Paket. Nach Empfang und Dekompression decodiert der Client-Agent 118 die codierten Daten 414 und speichert die resultierende Bitmap 410 in der durch den Index 416 identifizierten Speicherstelle und verarbeitet die resultierende Bitmap 410 gemäß dem begleitenden Befehl. Alternativ 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 dies erforderlich ist, um die resultierende Bitmap 410 weiter zu bearbeiten. Auf diese Weise wird Client-Speicher effizienter verwendet.
Obwohl die Erfindung bisher so beschrieben worden ist, daß der Server-Agent 160 die Speicherzuweisung und die Indexbildung des Client steuert, ist es auch möglich, daß der Client-Agent 118 diese Funktionen ausführt. Wenn beispielsweise während einer Client-Server-Sitzung zuerst eine Bitmap angetroffen und codiert, komprimiert und zu dem Client-Agent 118 (mit dem begleitenden Befehl, aber ohne den Index 416) übertragen wird, kann der Client-Agent 118 die bestimmte Speicherstelle innerhalb seines flüchtigen Speichers 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 den Index an den Server-Agent 160 überträgt, der den Index in der entsprechenden Speicherstelle in der Tabelle 411 des Servers speichert.
Mit der Ausführungsform fortfahrend, bei der der Server-Agent 160 die Zuweisung des flüchtigen Speichers 114 des Client steuert, pflegt der Client-Agent 118 eine kreisförmige Warteschlange 421 aller von dem Server-Agent 160 spezifizierten Indizes gemäß Warteschlangenpflegeanweisungen, die ebenfalls von dort erhalten wurden. Beispielsweise kann der Server-Agent 160 den Client-Agent 118 anweisen, einen vorbestimmten Block von Indizes 417 (z.B. entsprechend 128 K an Speicher) von ihren jeweiligen Graphikdaten zu disassoziieren, um neu angetroffene Graphikobjekte zu berücksichtigen, wenn der flüchtige Speicher 114 des Client ansonsten vollständig belegt ist. Folglich eignet sich ein nachfolgendes neues Graphikobjekt einen zuvor verwendeten Index an.
Der Server-Agent 160 bestimmt außerdem gemäß vorbestimmter Kriterien, ob jedes von der Neuzuordnung der Indizes beeinflußte Graphikobjekt gelöscht oder gesichert werden soll. Der Server-Agent 160 übermittelt diese Entscheidung an den Client-Agent 118. Wenn beispielsweise der Server-Agent 160 die Indizes 0, 1, 2 und 3 neu zuordnet und bestimmt, daß die mit den Handles 0 und 2 assoziierten Graphikobjekte gelöscht oder in die persistente Speicherung 120 des Client bewegt und die mit den Handles 1 und 3 assoziierten Objekte gesichert werden sollen, weist der Server-Agent 160 somit den Client-Agent 118 an, 0 und 2 zu löschen (oder zu bewegen) und 1 und 3 zu sichern. Der Client- Agent 118 bewegt dann den Index jedes gesicherten Objekts zum Ende der kreisförmigen Warteschlange. Mindestens ein Index bleibt an dem Warteschlangenende zur Zuordnung zu dem bewegten Objekt verfügbar; d.h., bei einer Ausführungsform zeigen der Kopf und das Ende der Warteschlange nicht auf den gleichen Index in der kreisförmigen Warteschlange. Folglich wird ein bewegtes Objekt sowohl an einer anderen physischen Speicherstelle gespeichert als auch mit einem anderen Index assoziiert.
Die in der kreisförmigen Warteschlange 421 des Client ausgeführten Pflegeaktionen werden in der Regel bei Fortsetzung der Client-Server-Sitzung häufiger, und der begrenzte flüchtige Speicher 114 des Client 110 wird mit zuvor übertragenen Bitmaps 410 oder anderen Graphikobjekten gefüllt. Dementsprechend steigt die Anzahl zuvor übertragener Graphikobjekte 422, die von dem flüchtigen Speicher 114 in die persistente Speicherung 120 des Client bewegt werden. Die vorliegende Erfindung verbessert weiterhin die oben beschriebene Caching-Technik zur Suche nach Indicia (siehe „Fuzzy-Schlüssel" unten) von zuvor übertragenen Graphikobjekten 422, die in der persistenten Speicherung 120 des Client gespeichert werden können, wenn sich in der Tabelle 411 des Servers kein Index zu diesem Graphikobjekt 422 findet. Wenn solche Indicia gefunden wird, dann besteht eine starke Wahrscheinlichkeit, daß das zuvor übertragene Graphikobjekt 422 immer noch örtlich resident und für den Client-Agent 118 zugänglich ist und daß das Graphikobjekt 422 deshalb möglicherweise nicht wieder von dem Server-Agent 150 zum Client-Agent 110 übertragen werden muß. Es ist wichtig, anzumerken, daß man durch das Finden solcher Indicia eine starke Wahrscheinlichkeit, aber keine Gewißheit, darüber erhält, daß das Graphikobjekt 420 örtlich resident ist, weil möglicherweise andere Programme oder Client-Agents, die sich möglicherweise die gleiche persistente Speicherung 120 teilen, das Graphikobjekt 422 aus der persistenten Speicherung 120 gelöscht haben können (um z.B. in der persistenten Speicherung für ein neues Objekt Platz zu machen).
Insbesondere und unter Bezugnahme auf 4 und 5: Wenn der Server-Agent 160 nicht in der Lage ist, einen Index für eine bestimmte Bitmap 422 in der Indextabelle 411 des Servers zu finden, durchsucht der Server-Agent 118 eine zweite Tabelle 418 (im weiteren „Fuzzy-Datenbank") nach einem Eintrag 419 (im weiteren „Fuzzy-Schlüssel"), der mit der Bitmap 422 assoziiert ist (Schritt 520). Bei einer Ausführungsform ist jeder Fuzzy-Schlüssel 419 eine Kombination aus dem eindeutigen Schlüssel 412 in der Tabelle 411 des Servers und der Länge/Größe der assoziierten Bitmap 422. Der Fuzzy-Schlüssel kann beispielsweise über eine XOR-Verknüpfung (exclusive OR) beider 32-Bit-CRCs, die zum Berechnen des eindeutigen 64-Bit-Schlüssels 412 in der Tabelle 411 des Servers verwendet werden, und der Länge der mit dem eindeutigen Schlüssel 412 assoziierten Bitmap 422 gebildet werden. Die Fuzzy-Datenbank 418 liefert im wesentlichen eine anfängliche Vorhersage darüber, ob in der persistenten Speicherung 120 des Client 110 eine Kopie der Bitmap 422 gespeichert ist. Wenn die Fuzzy-Datenbank 418 nicht den mit der Bitmap 422 assoziierten Fuzzy-Schlüssel 419 enthält, dann weist die persistente Speicherung 120 des Client wahrscheinlich keine gespeichert Kopie der Bitmap 422 auf, weshalb der Server-Agent 160 deshalb eine codierte Version der Bitmap 422 wie bereits beschrieben an den Client-Agent 118 übertragen muß. Wenn andererseits die Fuzzy-Datenbank 418 den Fuzzy-Schlüssel 419 für die Bitmap 422 enthält, dann besteht eine starke Wahrscheinlichkeit dafür, daß die Bitmap 422 in der persistenten Speicherung 120 des Client gespeichert ist.
Wenn genauer gesagt der Server-Agent 160 in der Fuzzy-Datenbank 418 keinen Fuzzy-Schlüssel 419 findet, der mit der Bitmap 422 assoziiert ist, sendet der Server-Agent 160 eine (der Bitmap 422 entsprechende) codierte Bitmap an den Client-Agent 118 mit einem Befehl, der anfordert, daß der Client-Agent 118 die Bitmap 422 (oder die entsprechende codierte Bitmap) in dem flüchtigen Speicher 114 speichern soll (Schritt 530). Außerdem, und wie oben beschrieben, fügt der Server-Agent 160 den mit der Bitmap 422 assoziierten Fuzzy-Schlüssel zu der Fuzzy-Datenbank 418 hinzu (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 an eine bestimmte Speicherstelle innerhalb des flüchtigen Speichers 114 des Client, wie durch den Server-Agent 160 spezifiziert (Schritt 560).
Bei einer Ausführungsform wartet der Server-Agent 160 nicht auf eine Quittung von dem Client-Agent 118, daß die mit der Bitmap 422 assoziierte codierte Bitmap erfolgreich empfangen und verarbeitet worden ist. Vielmehr nimmt der Server-Agent 160 an, daß die codierte Bitmap ordnungsgemäß verarbeitet worden ist, und schickt weiterhin einen Strom von Protokollbefehlen, ohne auf die Rückkehr einer Quittungsmeldung von dem Client-Agent 118 zu warten. Der Server-Agent 160 verfolgt jedoch die seit der letzten gelesenen Quittung ausgegebenen Protokollbefehle. Der Server-Agent 160 blockiert die weitere Übertragung von Protokollbefehlen, wenn die Anzahl einen vorbestimmten Schwellwert erreicht. Der Schwellwert ermöglicht dem Client-Agent 118, eine Obergrenze hinsichtlich der Speichermenge festzulegen, die benötigt wird, um ankommende Protokollbefehle während einer Wiederherstellungsmodusoperation in eine Warteschlange aufzunehmen, wie unten ausführlicher beschrieben.
Wenn sich in der Fuzzy-Datenbank 420 ein Fuzzy-Schlüssel 419 findet, sendet der Server-Agent 160 einen Befehl an den Client 110, der den Client-Agent 118 anweist, die mit dem Fuzzy-Schlüssel 419 assoziierte Bitmap 422 aus der persistenten Speicherung des Client in den flüchtigen Speicher 114 des Client zu kopieren (Schritt 550). Dieser Befehl wird nicht nur von dem Fuzzy-Schlüssel 419 begleitet, der die relevante Bitmap 422 eindeutig identifiziert, sondern auch von dem von dem Server-Agent 160 (wie oben beschrieben) erzeugten assoziierten Index zum Identifizieren der spezifischen Speicherstelle innerhalb des flüchtigen Speichers 114 des Client, die die kopierte Bitmap 422 erhalten und speichern wird. Durch Kopieren der Bitmap 422 in den flüchtigen Speicher 114 anstatt einfach ihre Speicherstelle in der persistenten Speicherung 120 beizubehalten, kann die Erfindung schnell auf mehrere Anforderungen zum Zeichnen der Bitmap 422 reagieren, die in schneller Reihenfolge erhalten werden, oder ohne viel eingreifende Cache-Aktivität durch Kopieren der Bitmap 422 bei dem Eintreten der ersten Anforderung.
Falls die Bitmap 422 trotz des Vorliegens des entsprechenden Fuzzy-Schlüssels 419 in der Fuzzy-Datenbank 418 nicht gegenwärtig in der persistenten Speicherung 120 gespeichert wird, dann gibt der Client-Agent 118 (als Reaktion auf den zuvor von dem Server-Agent 160 erteilten „CACHE_READ_DISK_OBJECT"-Befehl) eine Nachricht an den Server-Agent 160 zurück, die anzeigt, daß die Bitmap 422 fehlt. Bei Empfang dieser Nachricht überträgt der Server-Agent 160 wieder die mit der Bitmap 422 assoziierten codierten Bitmapdaten zu dem Client-Agent 118 (Schritt 530). Man beachte, daß der Server-Agent 160 eine sequentielle Liste aller derartigen, zu dem Client-Agent 118 gesendeten CACHE_READ_DISK_OBJECT-Befehle pflegt, für die der Server-Agent 160 noch keine Quittung erhalten hat, so daß der Server-Agent 160 eine empfangene Quittung ordnungsgemäß mit einer bestimmten Bitmap 422 assozi ieren kann (um die codierte Bitmap, die übertragen werden muß, ordnungsgemäß zu identifizieren).
In der Zwischenzeit tritt der Client-Agent 118 in einen Wiederherstellungsmodus ein, in dem der Client-Agent 118 weiterhin den ankommenden Protokollstrom liest, ihn aber nicht verarbeitet. Statt dessen baut der Client-Agent 118 eine Warteschlange für den Empfang des Stroms von Befehlen auf, die weiterhin von dem Server 150 zu dem Befehl strömen, der die Bitmap 420 nicht in der persistenten Speicherung 120 gefunden hat. Der Client-Agent 118 speichert weiterhin diese Befehle in dieser Warteschlange auf FIFO-Weise (first in, first out), bis die codierte Bitmap erhalten und erfolgreich decodiert wird, um die Bitmap 422 herzustellen. Um in dem ankommenden Strom von Befehlen die fehlende Bitmap 422 zu erkennen, hält der Client-Agent 118 Ausschau nach Daten, die in dem Protokollstrom einen Wiederherstellungsmarker begleiten. Bei einer Ausführungsform ist der Wiederherstellungsmarker eine bestimmte Pseudozufallszahl, die über XOR mit dem eindeutigen Schlüssel der Bitmap 422 (d.h. der 64-Bit-CRC und 32 Bit Länge) verknüpft wird. Der Server-Agent 160 erzeugt den Wiederherstellungsmarker bei Erhalt einer nicht-Quittung-Nachricht von dem Client-Agent 118. Wenn die Bitmap 422 ankommt, speichert der Client-Agent 118 sie in seinen flüchtigen Speicher 114 (Schritt 560) (d.h., wo die Bitmap 422 gespeichert worden wäre, wenn das Objekt anfänglich in der persistenten Speicherung 120 vorgelegen hätte) und beginnt mit der Verarbeitung der Befehle in der Warteschlange. Nach der Verarbeitung aller Befehle in der Warteschlange nimmt der Client-Agent 118 die Verarbeitung des ankommenden Stroms von Protokollbefehlen auf, die über das Netz 140 vom Server 150 kommen.
Ein Vorteil des oben beschriebenen Wiederherstellungsprozesses besteht darin, daß durch ihn die Zeitverzögerungseinbuße vermieden wird, die sich solche Cache-Systeme aufladen, die bei Auftreten eines Cache-Miss die Befehle in der Pipeline löschen. Außerdem bewirkt der Wiederherstellungsprozeß keine Unterbrechung beim Strom von Protokollbefehlen und auch keine Zunahme bei dem Verkehr auf dem Kanal um mehr als einige wenige Byte über das hinaus, was der Server 150 an den Client 110 gesendet hätte, hätte der Server-Agent 160 zu Anfang gewußt, daß die Bitmap 422 nicht in der persistenten Speicherung 120 vorlag.
Bei einer Ausführungsform erleichtert die vorliegende Erfindung das Finden der Bitmap 422 in der persistenten Speicherung 120 des Client durch Speichern der Bitmap 422 in einer Datei, deren Dateiname durch Codieren des Fuzzy-Schlüssels 419 zusammen mit den mit der Bitmap 422 assoziierten, am wenigsten jüngst verwendeten und/oder am wenigsten häufig verwendeten Informationen gebildet wird. Auf diese Weise liefert der Dateiname selbst die gewünschten Informationen, und so wird vermieden, daß die Datei geöffnet und gelesen werden muß. Das Codieren des Fuzzy-Schlüssels 419 als Teil des Dateinamens der Bitmap ermöglicht auch dem Client-Agent 118, die Fuzzy-Schlüssel-Informationen schnell aus dem Dateinamen zu extrahieren und sie während eines anfänglichen Bootvorgangs des Client 110 oder bei Start der Client-Server-Sitzung an den Server-Agent 160 zu senden. Die extrahierten Fuzzy-Schlüssel können an den Server 150 in einer Reihenfolge übertragen werden, die beispielsweise auf den am wenigsten jüngst verwendeten und/oder am wenigsten häufig verwendeten Informationen basiert, die ebenfalls Teil des Dateinamens bilden.
Bei einer Ausführungsform werden Fuzzy-Schlüssel 419 auf eine von drei Weisen zu der Fuzzy-Datenbank 418 hinzugefügt oder aus dieser gelöscht. Zuerst sendet beim Hochfahren des Client-Agent 118 oder bei der Herstellung einer Client-Server-Sitzung mit dem Server-Agent 160 der Client-Agent 118 Befehle an den Server-Agent 160, zu der Fuzzy-Datenbank 418 für jede entsprechende Bitmap 422 in der persistenten Speicherung 120 des Client einen Fuzzy-Schlüssel 419 hinzuzufügen (die Fuzzy-Schlüssel begleiten die Befehle des Client-Agent). Der Client-Agent 118 kann eine Sendeliste pflegen, die (z.B. auf der Basis der anhand von vorausgegangenen Client-Server-Sitzungen bestimmten, zu allerletzt verwendeten oder am häufigsten verwendeten Informationen) eine Reihenfolge spezifiziert, um beim Hochfahren Fuzzy-Schlüssel an den Server 150 zu senden. Die Sendeliste kann von dem Client-Agent 118 bei Lesen des Verzeichnisses seiner persistenten Speicherung 120 und Aufheben einer Darstellung des Verzeichnisses im flüchtigen Speicher 114 gebildet werden. Bei 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 Darstellung des Verzeichnisses hergestellt wird. Zweitens fragt der Client-Agent 118 in vorbestimmten Abfrageintervallen seine persistente Speicherung 120 ab, um jene Bitmaps zu bestimmen, die sich gegenwärtig in seiner persistenten Speicherung 120 befinden (z.B. durch Suche nach Dateinamen, die eine Struktur wie ein Fuzzy-Schlüssel enthalten), und sendet dann Hinzufüge- und/oder Lösch-Befehle an den Server-Agent 160, wie dies erforderlich ist, um die Fuzzy-Datenbank 418 des Servers zu aktualisieren. Wenn drittens der Server-Agent 160 einen Befehl an den Client-Agent 118 sendet, eine Bitmap in die persistente Speicherung 120 des Client zu schreiben, erzeugt der Server-Agent 160 einen entsprechenden Fuzzy-Schlüssel 419 und speichert ihn in der Fuzzy-Datenbank 418.
Die Übertragung von Bitmapdaten vom Server 150 zum Client 110 kann insbesondere dann einen relativ langen Zeitraum erfordern, wenn die Netzverbindung zwischen Client und Server relativ langsam ist. Bei einer Ausführungsform adaptiert die Erfindung den Serverbetrieb an sich ändernde Netzbedingungen durch Bestimmen der relativen Geschwindigkeit des Netzes 140.
Beispielsweise kann der Server-Agent 160 durch dynamisches Beurteilen der Bandbreite des Netzes 140 die zum Verarbeiten von Bitmapdaten verwendeten Codier- und Kompressionstechniken modifizieren, um die Bandbreitenanforderungen zu reduzieren, wenn über ein langsames Netz übertragen wird. 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 Leistung des Netzes 140 zu bestimmen. Wenn die Übertragungszeit einen Schwellwert übersteigt, kann der Client-Agent 118 alle Bitmapdaten zeichnen, die bereits in seinem Cache 114 gespeichert worden sind, und die verbleibenden Teile der Bitmapdaten entweder in Echtzeit, während sie im Cache 114 empfangen werden, oder zu vorbestimmten Intervallen anzeigen. Auf diese Weise erkennt ein Benutzer des Client, daß der Client 110 immer noch an den Bitmapdaten arbeitet, und kann erkennen, daß sich der Client 110 nicht in einem aufgehängten oder abgestürzten bzw. Fehlerzustand befindet. Durch Approximieren der effektiven Netzbandbreite an den Client 110 und entsprechendes Adaptieren des Verhaltens des Servers 150 kann der Server-Agent 160 beispielsweise den Client-Agent 118 anweisen, eine ganze Bitmap zu verwenden, gegenüber der Verwendung eines Ganzspaltenmodus der Anzeige für eine bestimmte Bitmap.
Insbesondere sendet der Server-Agent 160 einen Start_StopWatch-Befehl, gefolgt von codierten Bitmapdaten 414, und einen Stop_StopWatch-Befehl an den Client-Agent 118. Der Client-Agent 118 reagiert auf den Start_Stopwatch-Befehl, indem er das aktuelle Uhrsignal liest und es in ein erstes Arrayelement schreibt. Nach dem Empfang der codierten Bitmap 414 reagiert der Client-Agent 118 auf den Stop_StopWatch-Befehl, indem er das aktuelle Uhrsignal liest und es in ein zweites Arrayelement schreibt. Durch Vergleich der Differenz bei den Uhrsignalen zwischen den Befehlen Start_StopWatch und Stop_StopWatch erhält man einen Schätzwert der Zeit, die zum Empfangen der codierten Bitmapdaten aufgewendet wurde. Die resultierende Zeitdifferenz wird dann zurück zum Server-Agent 160 übertragen. Dieser Vorgang kann wiederholt werden, um einen geglätteten beweglichen Mittelwert zu berechnen, aus dem ein sinnvoller Schätzwert für den effektiven Durchsatz codierter Bitmapdaten bestimmt werden kann. Die Erfindung verwendet den Durchsatzschätzwert angesichts der Größe der codierten Daten für eine bestimmte Bitmap, um zu entscheiden, ob der ganze Bitmapmodus (z.B. wenn es wahrscheinlich ist, daß es weniger als 5 Sekunden benötigt) oder zunehmend ganze Spalten (wenn es wahrscheinlich ist, daß es mehr als 5 Sekunden benötigt) verwendet werden sollen. Man beachte, daß dieser Vorgang zwar nicht zu einem 100%ig genauen Durchsatzschätzwert führt, der aber ausreichend Granularität liefert, um schnelle oder langsame Netzverbindungen zu detektieren, anhand derer verschiedene Displaymodi bestimmt werden können. Eine ähnliche Technik kann dazu verwendet werden, große Schirm-zu-Schirm-Kopien am Clientende zeitlich zu planen und einen ähnlich beweglichen mittleren Schätzwert der Client-Leistung während dieser Operationen aufzubauen, mit denen dann ein Producer-Thread am Server 150 verlangsamt und ein Überlauf an der Quelle verhindert werden kann, wenn der Server 150 Daten schneller erzeugt, als der Client 110 sie verarbeiten kann.
Bei einer Ausführungsform bildet die Erfindung Objekte, die ausreichend groß sind, um die Daten einer ganzen Cache-Spalte zu enthalten. Beispielsweise können die maximale Objektgröße und die Größe des Cache von dem Server-Agent 160 bei Beginn der Client-Server-Sitzung als Funktion der Größe des Verbindungsfensters und seiner Farbtiefe ausgewählt werden, wobei größere Größen für größere Schirme und Tiefen zugeordnet werden. Zudem können gegenwärtige Techniken zum Aufbrechen einer Bitmap in Spalten an einem oder beiden Enden der Bitmap zu Spalten führen, die geringer sind als die Standardbreite. Wenn diese vom Standard abweichenden Spalten zu schmal sind, dann sind sie möglicherweise nicht groß genug, um in der persistenten Speicherung 120 des Client zurückbehalten zu werden, und sie werden deshalb während nachfolgender Client-Server-Sitzungen nicht beim Client 110 vorliegen. Durch die Erfindung wird dieses Problem vermieden, indem die schmalen Spalten mit benachbarten Spalten vereinigt werden, so daß nur breite Spalten verwendet werden, und somit sind alle Teile eines Splash-Schirms beispielsweise in der persistenten Speicherung 120 enthalten. Bei einer Ausführungsform werden dann ganze Spalten in zwei Phasen angezeigt. Die erste Phase bereitet den Cache 114 mit etwaigen fehlenden Daten vor, und die zweite Phase zieht die Spalte aus dem Cache 114, was die Verwendung von mehr als einem Cache-gespeicherten Objekt beinhalten kann. Die Spalte wird deshalb auf dem Displayschirm 128 in atomarer Weise angezeigt. Wie zuvor erörtert können die Spalten, wenn die Netzverbinung langsam ist, auf atomare Weise jeweils einzeln angezeigt werden, um den Benutzer beim Client 110 zu beruhigen, daß das System weiterhin arbeitet. Alternativ kann die ganze Bitmap unter Verwendung einer ähnlichen Technik atomar angezeigt werden, wenn eine schnelle Netzverbindung detektiert wird.
Die oben erörterte Technik des beweglichen mittleren Schätzwerts kann auch dazu verwendet werden, seit langem bestehende Overscroll-Probleme bei einer Applikation zu mildern, die auf einem schnellen Server ausgeführt und auf einem relativ langsamen Client angezeigt wird. Das Overscroll-Problem tritt beispielsweise dann auf, wenn ein Benutzer des Client 110 etwa durch mehrfaches Anklicken des Scroll-Balkens (oder Ziehen des Scroll-Balkens) mit einer Maus 126 mehrere Scroll-Befehle initiiert. Wenn die Scroll-Befehle zu dem schnellen Server gesendet werden, führt der Server 150 die Scroll-Operationen aus und schickt die assoziierten Daten schneller zurück, als der langsame Client 110 (oder das langsame Netz 140) die Ergebnisse auf seinem Anzeigeschirm 128 anzeigt. Wenn der Benutzer beim Client 110 schließlich die gewünschte Schirmposition sieht und das Scrollen stoppen möchte (durch Stoppen der Mausklicks und/oder das Ziehen des Scroll-Balkens), läuft die Anzeige folglich über die gewünschte Schirmposition weiter. Dieser Overscroll-Zustand tritt auf, weil der schnelle Server 150 die Scroll-Befehle bereits verarbeitet und die entsprechenden Daten zurück zum Client 110 übertragen hat, aber die Daten bei dem langsamen Client in die Warteschlange eingereiht und noch nicht ganz verarbeitet worden sind.
Durch die Erfindung wird dieses Overscroll-Problem gemildert, indem die Häufigkeit seines Auftretens reduziert wird. Insbesondere taktet die Erfindung periodisch ausgewählte Scroll-Ereignisse beim Server 150 (durch Scrollen des Rahmenpuffers) und beim Client 110 (über die oben erörterten Stopwatch-Befehle), um einen sich bewegenden mittleren Schätzwert ihre jeweiligen Geschwindigkeiten zu berechnen. Auf diese Weise schätzt der Server-Agent 160, wie lang ein bestimmtes Scroll-Ereignis zur Verarbeitung am Server 150 benötigt (Geschwindigkeit mal die Anzahl der involvierten Pixel) und was erwartet wird, wie lange der Client 110 benötigt, und wenn die erwartete Verarbeitungszeit beim Client 110 größer ist als die des Servers 150, dann wird die Serververarbeitung um das entsprechende Zeitdifferential unterbrochen, um den Client 110 und den Server 150 im wesentlichen synchron zu halten. Dieser Ansatz führt zu viel weniger Overscrolls aufgrund der Zeitverzögerung zwischen dem Client 110 und dem Server 150 im Vergleich zu der Anzahl der Overscrolls, die auftreten, wenn dieser Ansatz nicht implementiert wird.
Zusätzlich zu der Verarbeitung von Bitdaten kann die vorliegende Erfindung auch eine Textkette, die auf dem Server 150 erzeugt wird, zu dem Display 128 des entfernten Client 110 verschieben. Unter Bezugnahme auf 6 führt der Server 150 das Applikationsprogramm 158 aus, das eine Textfolge erzeugt, die zu dem Client 110 verschoben werden muß. Der Server-Agent 160 fängt die von dem Applikationsprogramm 158 zu dem Server-Betriebssystem 156 gesendeten Befehle ab, die sich auf die Textfolge beziehen, und bewirkt, daß ein Displaytreiber 612 des Server-Agent 160 textbezogene Informationen verarbeitet und eine Reihe von Protokollbefehlen 614 zu dem Client-Agent 118 überträgt zur Anzeige einer Textfolge 416 auf dem Client-Display 128. Beispielsweise führt die Applikation 158 Prozeduraufrufe aus, die die Textfarbe und die Hintergrundfarbe einstellen (hier „Hello!"). Die Ausführung der TextOut-Prozedur 618 durch die Applikation 158 löst eine Ausführung der DrvTextOut-Prozedur 620 auf dem Displaytreiber 612 aus. Wie gezeigt definiert die DrvTextOut-Prozedur 620 die Beschneidungsregion, das begrenzende Rechteck und den Textmodus (einschließlich Hintergrund und Textfarbe) durch Ausführen einer Sequenz entsprechender Prozeduren.
Das Ausführen solcher Prozeduren bewirkt, daß der Displaytreiber 612 die entsprechenden Daten- und Protokollbefehle (wie etwa eine Teilmenge jener in Tabelle 1 bereitgestellten) zu dem Client-Agent 118 sendet. Die Protokollbefehle werden von dem Client-Agent 118 empfangen und verarbeitet, der Prozeduren 614 ausführt, die die Beschneidungsregion, das begrenzende Rechteck, den Textmodus und die mit jedem anzuzeigenden Textzeichen assoziierte Glyphe spezifizieren. Man beachte, daß das mit einem Glyphenobjekt assoziierte Protokoll nicht nur die Glyphenbitmap selbst codiert, sondern auch ihre relativen Positionierungsinformationen. Der Server 150 kann auch andere Protokollbefehle an den Client-Agent 118 senden, die den Client-Agent 118 anweisen, die assoziierten Glyphen im flüchtigen Speicher 114 und/oder in der persistenten Speicherung 120 zu speichern, wie oben beschrieben. Der Client-Agent 118 erzeugt eine Bitmap, die der Größe des begrenzenden Rechtecks entspricht, das die Textfolge umgibt, und setzt die relativen Positionen jeder Glyphe an ihre ordnungsgemäße Position innerhalb des begrenzenden Rechtecks. Nachdem die letzte Glyphe empfangen und ihre Position gesetzt worden ist, weist der Client-Agent 118 das Client-Betriebssystem 116 an, die Bitmap auf dem Displayschirm 128 des Client 110 zu zeichnen bzw. wiederzugeben.
Die vorliegende Erfindung unterstützt außerdem mehrere verschiedene Beschreibungen von Wegen (eine Menge von Linien oder Kurven, die als Teil der Beschreibung eine Linienzeichenoperation oder im Fall eines geschlossenen Wegs zum Beschreiben einer Region verwendet werden) einschließlich Ellipsen, Bezier-Kurven, Segmente, Streifen und Stile. Segmente beziehen sich auf Liniensegmente, die bei Kombinierung einen Weg bilden. Analog können Segmente weiterhin in Streifen zerlegt werden, die Teile des Linien-Segments sind (entsprechend einer Reihe von aufeinanderfolgenden Pixeln), die die gleichen Winkelcharakteristiken aufweisen. Die zum Darstellen von beispielsweise Streifen verwendete Codiertechnik verwendet relative Ortsinformationen und quantisierte Winkel, um aufeinanderfolgende Streifen zu charakterisieren, insbesondere Liniensegmente, was nicht nur die Menge graphischer Liniendaten minimiert, die codiert werden muß, sondern auch zu einer wiederholbareren Sequenz von Daten führt, die effizienter komprimiert werden kann. Die Zunahme bei der Wiederholbarkeit wird insbesondere dann verbessert, wenn Streifen dargestellt werden, die eine Gestalt wie etwa ein Rechteck oder einen Kreis bilden. Das für Streifen verwendete Protokoll ermöglicht es dem Client-Agent 118 auch, einen Weg unabhängig und ohne Kenntnis des Algorithmus präzise zu reproduzieren, der von dem Server-Agent 160 zum Konvertieren des Wegs in eine Sequenz von Pixeln verwendet wird.
Unter Bezugnahme auf das nichteinschränkende Beispiel in 7A umfaßt ein Weg 700 zwei Liniensegmente 710, 720, die perfekt linear erscheinen. Der Fachmann erkennt jedoch, daß Liniensegmente, die nicht perfekt horizontal, vertikal oder unter einer 45°-Diagonalen verlaufen, durch eine entsprechende Serie von Streifen approximiert werden müssen, wenn der Weg 700 auf einem Displayschirm 128 angezeigt wird (1). Diese Approximierung ist notwendig, weil die individuellen Pixel auf dem Displayschirm 128 von höchstens 8 anderen Pixeln umgeben sind, die entweder perfekt horizontal, vertikal oder unter einer 45°-Diagonalen relativ zueinander verlaufen, und deshalb müssen alle Liniensegmente 710, 720, die in einem anderen Gesamtwinkel liegen, durch eine Reihe von Streifen approximiert werden. Dementsprechend und unter Bezugnahme auf den beispielhaften Weg 700 von 7B umfaßt das Segment 710 vier Streifen 712, 714, 716, 718, wobei die (durch quadratische Blöcke dargestellten) individuellen Pixel jedes Streifens 712, 714, 716, 718 unter 45°-Diagonalen relativ zueinander organisiert sind, und Segment 720 besteht aus fünf Streifen 722, 724, 726, 728, 730, wobei die individuellen Pixel jedes Streifens 722, 724, 726, 728, 730 relativ zueinander horizontal organisiert sind.
Bei einer Ausführungsform und unter Bezugnahme auf 7B und 8A zerlegt der Server-Agent 160 den Weg 700 in Liniensegmente 710, 720 mit jeweils einer bestimmten Länge und einem bestimmten Winkel (Schritt 810). Dann wird ein Array von Liniensegmenten gebildet, um quantisierte Segmentinformationen (hier im weiteren als ein quantisierter Winkel oder „QA" bezeichnet) für jedes Liniensegment 710, 720 zu speichern (Schritt 820). Unter Bezugnahme auch auf 8B bestimmt der Server-Agent 160, anstatt den mit einem bestimmten Segment 710, 720 assoziierten absoluten Winkel zu berechnen, statt dessen, in welchem der 16 quantisierten Winkel 880 der absolute Winkel liegt. Diese Quantisierungstechnik bestimmt, in welchem 16tel des Umfangs der Endpunkt für ein Liniensegment liegt, das in der Mitte eines Kreises beginnt (ein Radius). Diese Informationen können als der ohne mit einem Vorzeichen versehene Deltawert von dem letzten in diesem Kontext spezifizierten Segment ausgedrückt werden (mod 16, initialisiert auf 0). Diese Technik führt zu einer wiederholbareren Sequenz (als wenn der absolute Winkel verwendet wurde), insbesondere wenn die Segmente eine Gestalt wie etwa ein Rechteck oder einen Kreis bilden.
Der Server-Agent 160 zerlegt dann jedes Liniensegment 710, 720 in 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 zum Aufbrechen des Wegs 700 in ein Array von Streifen der Windows-NT-Algorithmus bLine verwendet. Der NT-Algorithmus bestimmt den quantisierten Winkel jedes Streifens und Segments, so daß hinsichtlich Segmenten oder Streifen, die auf einer Grenze zwischen quantisierten Winkelregionen liegen, keine Doppeldeutigkeit besteht. Der NT-Algorithmus dreht eine nach oben verlaufende Linie, so daß die Linie immer nach unten verläuft (der y-Wert nimmt immer zu) und setzt das Flag_FL_FLIP_V. Analog wird eine nach links verlaufende Linie horizontal gedreht, so daß sie immer nach rechts verläuft (der x-Wert nimmt immer zu), und setzt das Flag FL_FLIP_H. Dadurch fällt das von diesem Algorithmus ausgegebene Array von Streifen in einen einzigen Quadranten. Bei dieser besonderen Ausführungsform hebt der Server-Agent 160 die Drehoperation des NT-Algorithmus auf, so daß das Array von Streifen in ihre vorherigen/ursprünglichen quantisierten Winkel zurückgedreht werden, um sicherzustellen, daß der Endpunkt eines vorhergehenden Streifens und der Startpunkt des nächsten nachfolgenden Streifens zusammenfallen, um zu vermeiden, daß die Startkoordinate des nächsten nachfolgenden Streifens gesendet werden muß.
Der Server-Agent 160 codiert dann die Beginnkoordinate des Wegs 700 zusammen mit den quantisierten Winkeldaten in dem Liniensegmentarray und Pixellängendaten in dem Streifenlängenarray, 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 danach werden die komprimierten Graphikliniendaten zur Codierung und weiteren Verarbeitung zum Client-Agent 118 übertragen (Schritt 870).
Unter Bezugnahme auf die veranschaulichende Darstellung in 9 und die quantisierten Winkelinformationen von 10 umfaßt das Liniensegment 710 vier innerhalb eines quantisierten Winkels 1 positionierte Streifen 712, 714, 716, 718. Die Beginnkoordinate des Wegs 700, die als Teil der komprimierten Graphikliniendaten vom Server-Agent 160 zum Client-Agent 118 übertragen wird, entspricht dem ersten Pixel im Streifen 712 (am Ursprung von 880 positioniert). Die Graphikliniendaten enthalten weiterhin die Pixellänge jedes Streifens 712, 714, 716, 718 im Segment 710. Da das Segment 710 keiner perfekten Horizontalen, Vertikalen oder 45°-Diagonalen entspricht, wird jeder nachfolgende Streifen 714, 716 und 718 im Segment 710 um einen bestimmten Deltawert justiert, wie in 10 angedeutet, um den Gesamtwinkel des Segments 710 ordnungsgemäß zu approximieren. Bei dem vorliegenden Beispiel zeigt der Client-Agent 118 den Streifen 714 mit im wesentlichen dem gleichen x-Wert und einem zunehmenden y-Wert an, um von dem letzten Punkt in dem vorausgegangenen Streifen 712 zu dem Beginnpunkt in dem nächsten nachfolgenden Streifen 714 zu kommen. Dieser Prozeß wird für jeden Streifen im Segment 710 sowie für die Streifen in Segment 720, die innerhalb von QA 15 positioniert sind, wiederholt.
Dementsprechend und bei einer Ausführungsform umfaßt der von der vorliegenden Erfindung erzeugte Protokollstrom bei der Verarbeitung von Streifen die Startposition des Wegs, (gegebenenfalls) einen Index entsprechend einer Speicherstelle im flüchtigen Speicher 114 des Client (1), der möglicherweise bereits einen zu einem gewissen früheren Zeitpunkt in der Client-Server-Sitzung übertragenen bestimmten Streifen speichert, die Anzahl der Segmente in dem Weg, den quantisierten Winkel jedes Segments (anhand dessen die in 10 reflektierten Deltawerte bestimmt werden), die Länge jedes Streifens zusammen mit bestimmten Steuerinformationen und quantisierte Winkel-Delta-Informationen, die zu dem quantisierten Winkel eines ersten oder vorausgegangenen Segments addiert werden, um den Client-Agent 118 über den quantisierten Winkel der nachfolgenden Segmente zu informieren. Auf diese Weise wird durch die Erfindung vermieden, daß Koordinaten und Absolutwinkelinformationen für jeden Streifen in dem Weg gesendet werden müssen. Weiterhin erleichtert die oben erörterte Streifenverarbeitungstechnik die effiziente Kompression von Graphikliniendaten durch wirksames Einsetzen der Wiederholungshäufigkeit der Daten in dem unkomprimierten Protokollstrom.
Die vorliegende Erfindung kann auch auf Bitmaps angewendet werden, die in einer Auf-Schirm-Oberfläche angezeigt werden, sowie auf Bitmaps in einer Außerschirm-Oberfläche (z.B., die im Speicher eines Videodisplayadapters und/oder in einem zuvor zugewiesenen Abschnitt des flüchtigen Speichers 114 des Client gespeichert sind, die von einer Graphikkonvertierungssammlung bearbeitet werden). Außerschirm-Oberflächen werden häufig durch Applikationen wie etwa Microsoft Word gebildet, die Bitmaps auf die Außerschirm-Oberfläche schreiben, bis die Oberfläche vollständig ist, wobei dann die Außerschirm-Oberfläche auf dem Displayschirm 128 des Client 110 in endgültiger Form als eine Auf-Schirm-Oberfläche angezeigt wird. Deshalb bilden oftmals die Außerschirm-Oberflächen die Quelle für Auf-Schirm-Oberflächen.
Bei einer Ausführungsform und unter Bezugnahme auf Außerschirm-Oberflächen informiert der Client-Agent 118 den Server-Agent 160 über die für Außerschirm-Oberflächen verfügbare Menge an lokalem flüchtigem Speicher 114, so daß der Server-Agent 160 keine Außerschirm-Oberfläche bildet, die größer ist als der verfügbare Speicher des Client. Der Server-Agent 160 bildet danach eine Außerschirm-Oberfläche und überträgt sie an den Client-Agent 118 mit Anweisungen, die Oberfläche in seinem flüchtigen Speicher 114 zu speichern. Der Client-Agent 118 wählt einen bestimmten Abschnitt seines flüchtigen Speichers 114 aus und weist ihn der Oberfläche zu und speichert die Oberfläche darin. Jede Außerschirm-Oberfläche weist eine Menge assoziierte Attribute auf, wie etwa einen Identifizierer, der die Oberfläche, das Pixelformat, die Abmessungen, die Zeichenattribute, den Protokollzustand usw. eindeutig identifiziert.
Bei einer Ausführungsform kann der Server-Agent 160, damit der flüchtige Speicher 114 des Client effizienter genutzt wird, Befehle an den Client-Agent 118 ausgeben, die anweisen, daß bestimmte Operationen nur auf die Außerschirm-Oberfläche ausgeführt werden, wenn die Außerschirm-Oberfläche mit der Auf-Schirm-Oberfläche interagiert (wenn z.B. die Auf-Schirm-Oberfläche mit Bitmapdaten von der Außerschirm-Oberfläche aktualisiert wird). Wenn die einzige Interaktion zwischen der Auf-Schirm-Oberfläche und der Außerschirm-Oberfläche eine letzte Kopie auf dem Schirm ist, dann können die Operationen auf die Auf-Schirm-Oberfläche ausgerichtet werden und somit die Menge an Bitmapdaten reduzieren, die über das Netz 140 übertragen werden müssen. Alternativ kann die Quelle der Auf-Schirm-Oberfläche eingeschränkt werden, so daß sie entweder einer entfernt beim Server 150 gespeicherten Außerschirm-Oberfläche oder einer lokal beim Client 110 gespeicherten Außerschirm-Oberfläche entspricht. Zu typischen Operationen auf die Außerschirm-Oberfläche, die von dem Server-Agent 160 angefordert werden, zählen das Aktualisieren der Bitmap in der Außerschirm-Oberfläche mit aktualisiertem Text, einer aktualisierten Linie oder anderen aktualisierten Daten.
Bei einer Ausführungsform und unter Bezugnahme auf 11 fängt der Server-Agent 160 alle zu dem Server-Betriebssystem 156 hergestellten Anrufe ab, die die Erzeugung einer Außerschirm-Oberfläche betreffen, und der Server-Agent 160 bildet eine Duplikatkopie der Oberfläche und speichert sie zusammen mit ihren Attributen in dem lokalen Speicher des Servers. Der Server-Agent 160 gibt dann einen Befehl an den Client-Agent 118 aus, die Außerschirm-Oberfläche im flüchtigen Speicher 114 des Client zu bilden (Schritt 1102). Der Befehl wird von einer codierten Darstellung der Außerschirm-Oberfläche begleitet, wenn dies der erste Fall der Außerschirm-Oberfläche ist, oder von einem Index oder einem Fuzzy-Schlüssel, wenn die Außerschirm-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 von den Index-/Fuzzy-Schlüssel-Indicia oder codierten Oberfläche identifizierten Graphikdaten in die Außerschirm-Oberfläche des Client zu integrieren (Schritt 1106). Der Client-Agent 118 reagiert auf die Anweisungen des Server-Agent durch Kopieren der identifizierten Oberfläche/Bitmap auf die Außerschirm-Oberfläche des Client (Schritt 1108). Wenn ein von dem Server-Agent 160 ausgegebener BITBLT-Befehl beispielsweise keine Bitmap in der Außerschirm-Oberfläche des Client bildet, wie etwa wenn ein Speicherzuweisungsfehler auftritt, sendet der Client-Agent 118 einen C2S_OSS_Error-Befehl an den Server-Agent 160, der den Fehlerzustand anzeigt (Schritt 1110). Als Reaktion auf den Fehlerzustand verwendet der Server-Agent 160 seine lokale Kopie der Außerschirm-Oberfläche als die Quelle zum Aktualisieren der Außerschirm-Oberfläche des Client. Der Client-Agent 118 aktualisiert mit den von der lokalen Kopie des Servers empfangenen Informationen die Außerschirm-Oberfläche auf dem Client 110 und korrigiert etwaige korrumpierte/schmutzige Regionen der Außerschirm-Oberfläche. Wenn ein Fehlerzustand angetroffen wird, überträgt alternativ der Server-Agent 160 seine lokale/Duplikatkopie der Außerschirm-Oberfläche (Schritt 1112) zum Client-Agent 118 und weist den Client-Agent 118 an, die Duplikatoberfläche als die Quelle zum Aktualisieren der Auf-Schirm-Oberfläche zu verwenden und die korrumpierte Außerschirm-Oberfläche beim Client zu verwerfen (Schritt 1114).
Wenngleich die vorliegende Erfindung unter Bezugnahme auf spezifische Details beschrieben worden ist, ist nicht beabsichtigt, daß solche Details als Beschränkungen hinsichtlich des Schutzbereichs der Erfindung angesehen werden sollten, mit Ausnahme dessen und in dem Ausmaß, daß sie in den beiliegenden Ansprüchen enthalten sind.

Claims

Verfahren zum Fernsteuern durch einen Server (150), in einem über ein Kommunikationsnetz (140) an den Server angekoppelten Client (110) eine Außerschirm-Oberfläche zu bilden, wobei das Verfahren im Server (150) durchgeführt wird und die folgenden Schritte umfaßt: Anweisen (1102) des Client, eine erste Speicherregion für eine Zuteilung zu der Außerschirm-Oberfläche zu wählen, wobei die erste Speicherregion einem an den Client (110) angekoppelten Speicher (114) entspricht; Senden (1104) von Indicia der graphischen Daten zu dem Client; und Anweisen (1106) des Client, die den Indicia zugeordneten graphischen Daten zu einer bestimmten Speicherstelle in der ersten Speicherregion zu kopieren.
Verfahren nach Anspruch 1, weiterhin mit dem folgenden Schritt: Spezifizieren mehrerer, der Außerschirm-Oberfläche zugeordneter Attribute.
Verfahren nach Anspruch 1 oder Anspruch 2, wobei die Indicia der graphischen Daten einem Fuzzy-Schlüssel (419) entsprechen, wobei der Fuzzy-Schlüssel (419) eine Speicherstelle der graphischen Daten in einem an den Client (1100) angekoppelten persistenten Speicher (120) identifiziert.
Verfahren nach Anspruch 1 oder Anspruch 2, wobei die Indicia der graphischen Daten einem Index (416) entsprechen, wobei der Index (416) eine Speicherstelle der graphischen Daten in einem an den Client (1100) angekoppelten Cache-Speicher identifiziert.
Verfahren nach einem der vorhergehenden Ansprüche, weiterhin mit dem folgenden Schritt: Anweisen (1108) des Client (110), eine dem Client zugeordnete Auf-Schirm-Oberfläche unter Verwendung der kopierten graphischen Daten in der Außerschirm-Oberfläche zu aktualisieren.
Verfahren nach einem der vorhergehenden Ansprüche, weiterhin mit dem folgenden Schritt: Speichern eines Duplikats der Außerschirm-Oberfläche in einem an den Server angekoppelten Speicher.
Verfahren nach Anspruch 6, weiterhin mit den folgenden Schritten: nach Empfang einer Anzeige einer Fehlerbedingung, Senden (1112) mindestens eines Teils der Duplikat-Außerschirm-Oberfläche zu dem Client; und Anweisen des Client, den mindestens einen Teil der Duplikat-Außerschirm-Oberfläche zu einer dem Client zugeordneten Auf-Schirm-Oberfläche zu kopieren.
Verfahren nach einem der vorhergehenden Ansprüche, weiterhin mit den folgenden Schritten: a) Anweisen des Client, eine zweite Speicherregion zu wählen; und b) Anweisen des Client, die graphischen Daten zu einer bestimmten Speicherstelle in der zweiten Speicherregion zu kopieren, wobei Schritt a) als Reaktion auf den Empfang einer Anzeige einer Fehlerbedingung durchgeführt wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die graphischen Daten einer Bitmap entsprechen.
Verfahren nach einem der Ansprüche 1 bis 8, wobei die graphischen Daten einer Glyphe entsprechen.
Verfahren nach einem der Ansprüche 1 bis 8, wobei die graphischen Daten einem Streifen entsprechen.
System zum Fernsteuern durch einen Server (150), in einem über ein Kommunikationsnetz (140) an den Server angekoppelten Client (110) eine Außerschirm-Oberfläche zu bilden, wobei das System folgendes umfaßt: einen auf dem Client ausgeführten Client-Agent (118); eine an den Client-Agent angekoppelte erste Speicherregion; eine in der ersten Speicherregion gespeicherte Außerschirm-Oberfläche; einen auf dem Server (150) ausgeführten und an den Client-Agent (118) angekoppelten Server-Agent (160); und graphische Daten, wobei die graphischen Daten zugeordnete Indicia aufweisen und durch den Client gespeichert werden, und wobei der Server-Agent im Betrieb für folgendes ausgelegt ist: Senden von Indicia der graphischen Daten zu dem Client-Agent; und Anweisen des Client, die erste Speicherregion für eine Zuteilung zu der Außerschirm-Oberfläche zu wählen und die den Indicia zugeordneten graphischen Daten zu einer bestimmten Speicherstelle in der ersten Speicherregion zu kopieren.
System nach Anspruch 12, wobei die Indicia der graphischen Daten einem Fuzzy-Schlüssel (419) entsprechen, wobei der Fuzzy-Schlüssel (419) eine Speicherstelle der graphischen Daten in einem an den Client angekoppelten persistenten Speicher (120) identifiziert.
System nach Anspruch 12, wobei die Indicia der graphischen Daten einem Index (416) entsprechen, wobei der Index (416) eine Speicherstelle der graphischen Daten in einem an den Client angekoppelten Cache-Speicher identifiziert.
System nach Anspruch 12, 13 oder 14, wobei der Server-Agent im Betrieb dafür ausgelegt ist, Attribute der Außerschirm-Oberfläche zu spezifizieren.
System nach einem der Ansprüche 12 bis 15, weiterhin mit einem in einem an den Server-Agent angekoppelten Speicher gespeicherten Duplikat der Außerschirm-Oberfläche.
System nach Anspruch 16, weiterhin umfassend: eine an den Client-Agent angekoppelte Auf-Schirm-Oberfläche, wobei der Client-Agent im Betrieb für folgendes ausgelegt ist: Aktualisieren der Auf-Schirm-Oberfläche unter Verwendung der Außerschirm-Oberfläche und Verwerfen der in der ersten Speicherregion gespeicherten Außerschirm-Oberfläche bei Auftreten einer Fehlerbedingung.
System nach einem der Ansprüche 12 bis 17, wobei die graphischen Daten einer Bitmap entsprechen.
System nach einem der Ansprüche 12 bis 17, wobei die graphischen Daten einer Glyphe entsprechen.
System nach einem der Ansprüche 12 bis 17, wobei die graphischen Daten einem Streifen entsprechen.