-
Gebiet der
Erfindung
-
Die
vorliegende Erfindung bezieht sich auf Programmfernaufrufe über ein
verteiltes Netzwerk von potentiell heterogenen Computern, und bezieht sich
insbesondere auf Serialisieren (Marshalling) und Deserialisieren
(Unmarshalling) von Zeigern von beliebiger Größe, die nicht einer On-Wire-Datendarstellung
entsprechen, in einem Reader-Makes-Right-Protokoll eines Programmfernaufrufs.
-
Hintergund und Zusammenfassung
der Erfindung
-
Das
Microsoft Distributed Component Object Model (DCOM) liefert eine
Programmfernaufruf- (Remote Procedure Call, RPC) Ferneinrichtung
(im Folgenden: „DCOM
RPC Remoting Facility"),
die transparente Schnittstellen-Funktionsaufrufe über Grenzen
von Prozess und Maschine (d. h. Computer) erlaubt (siehe z. B. Brockschmidt,
Inside OLE, 2nd edition 277-338 (1995)). Um es klar zu machen, liefert die
DCOM RPC Remoting Facility Serialisierungs-Code (Marshaling Code,
bezeichnet als „Proxy") innerhalb des Prozesses
eines Client-Programms
oder einer Komponente (der „Client"), der den Schnittstellenaufruf
an eine außerhalb
des Prozesses liegende Komponente oder an eine auf einem entfernten
Computer liegende Komponente (die „Serverkomponente") durchführt, und
die auch Deserialisierungs-Code liefert (Unmarshaling Code, bezeichnet
als „Stub") im Prozess der
Serverkomponente. Der Proxy empfängt
den In-Prozess-Schnittstellenaufruf
des Clients und serialisiert alle für den Aufruf benötigten Daten
(z. B. Argumente und Speicherdaten) in einen Puffer zum Transfer
zu dem Stub über
einen Kommunikationskanal (dem „RPC-Kanal") zwischen dem Client und Server-Prozessen oder
Maschinen. Der Stub deserialisiert die Daten aus dem Puffer des
Prozesses und der Maschine der Serverkomponente und ruft den Schnittstellenaufruf direkt
auf der Serverkomponente auf. Der Stub serialisiert auch jeden Ergebnis-Wert
und „Ausgabe-" Parameter, der von
dem Schnittstellenaufruf zum Transfer zu dem Proxy und zum Deserialisieren
durch den Proxy zum Weiterleiten zu dem Client zurückgegeben
wird. Dieser Programmfernaufruf ist für den Client und die Server-Komponente
in der Weise transparent, dass die DCOM RPC Remoting Facility automatisch
den Proxy, den Stub und den RPC-Kanal zum
Serialisieren des Schnittstellenaufrufs über Prozess- und Maschinengrenzen
hinweg bereitstellt, so dass der Client und die Serverkomponente
den Schnittstellenaufruf durchführen
können,
als wenn beide sich auf demselben Computer und in demselben Prozess
befinden würden.
-
Die
DCOM RPC Remoting Facility erzeugt automatisch den Proxy und Stub
mit Serialisierungs-Code, der für
eine gegebene Schnittstelle einer Serverkomponente geeignet ist
und auf einer Textbeschreibung der Schnittstelle basiert (einschließlich jeder
von der Schnittstelle verwendeten Datenstruktur). Die Schnittstellenbeschreibung
wird von dem Entwickler der Serverkomponente in der Microsoft Interface
Description Language (MIDL) geschrieben. MIDL basiert auf einem
Industriestandard, der RPC-Schnittstellensprache, die als Open Software
Foundation Distributed Computing Environment Interface Definition
Language (OSF DCE IDL) bezeichnet wird. Die DCOM RPC Remoting Facility
umfasst einen MIDL Compiler, der den richtigen Serialisierungs-Code
für den
Proxy und den Stub aus der MIDL-Beschreibung der aufgerufenen Schnittstelle erzeugt.
-
Der
Serialisierungs- und Deserialisierungs-Code, der von dem MIDL Compiler
für die
Proxies und Stubs erzeugt wurde, tauscht Daten in einem Reader-Makes-Right-Protokoll aus.
In einem Reader-Makes-Right-Protokoll (auch bekannt als „Server-Makes-Right") schreiben der Proxy
und Stub Daten in einen RPC-Puffer (z. B. der Proxy während des
ersten Aufrufs oder der Stub für
Antwortdaten) in einer multikanonischen Darstellung (was bedeutet, dass
die Darstellung mehrere Datenformate unterstützt) unter Verwendung von jedem
für den
Schreiber geeigneten Datenformat, was typischerweise das Datenformat
des Computers ist, auf dem sich der Schreiber befindet. Der Code
am anderen Ende, der die Daten aus dem RPC-Puffer liest (z. B. der
Stub während
des ersten Aufrufs oder der Proxy für Antwortdaten) ist dann dafür verantwortlich,
die Daten aus dem RPC-Puffer in das native Datenformat des Computers
des Lesers zu konvertieren. Im Falle eines RPC-Aufrufes zwischen
Prozessen auf einem selben Computer oder zwischen zwei homogenen Computern
(z. B. zwei Computern mit 32-bit Intel Micoprozessoren, auf denen
Microsoft WINDOWS läuft)
haben sowohl der Leser als auch der Schreiber dasselbe Datenformat,
und deshalb ist im Allgemeinen keine Konversion notwendig. Im Falle
eines RPC-Aufrufs zwischen heterogenen Computern, wird die Konversion
nur auf der Leseseite von jedem Austausch durchgeführt. Im
Gegensatz dazu konvertiert der in den RPC-Puffer Schreibende in
einem Writer-Makes-Right-Protokoll die Daten, die in den RPC-Puffer
serialisiert werden, aus seinem nativen Datenformat in ein neutrales
oder Plattformunabhängiges
Datenformat, und der Leser konvertiert die Daten aus dem RPC-Puffer immer aus
dem neutralen Format in das native Datenformat des Computers des
Lesers. Das Reader-Makes-Right-RPC-Protokoll ist deshalb gewöhnlich effizienter,
da Konversionen des Datenformats auf einer oder beiden Seiten des RPC-Aufrufs vermieden
werden.
-
Die
Proxies und Stubs der DCOM RPC Einrichtungen verwenden den Industriestandard
DCE Network Data Representation (NDR) als die multikanonische Darstellung
des RPC-Puffers auf der Verbindung (d. h. zur Übertragung zwischen dem Proxy und
dem Stub). Gemäß der NDR-Darstellung
markieren der Proxy und der Stub die RPC-Pufferdaten mit dem ausgewählten Datenformat
der RPC-Pufferdaten,
indem sie einen Header mit Markierungen (Flags) aufnehmen, die Merkmale
des gewählten
Datenformats angeben. Zum Beispiel setzen der Proxy und Stub Header-Markierungen,
die große/kleine Byte-Folge
(ENDIAN), ASCII/EBCDIC, Abweichungen in der Gleitkommadarstellung
usw. angeben. Dies ermöglicht
dem Leser des RPC-Puffers, das Datenformat der RPC- Pufferdaten festzustellen
und Übersetzungen
in das native Datenformat des Lesers durchzuführen, falls benötigt.
-
Die
NDR-Darstellung hat den Nachteil, dass sie nur Datenformate mit
32-bit Zeigern unterstützt. Diese
Beschränkung
begrenzt die DCOM RPC Remoting Facility auf Datenformate der Verbindung
mit ausschließlich
32-bit Zeigern. Das native Datenformat mehrerer Computerplattformen
verwendet allerdings andere als 32-bit Zeigergrößen. Zum Beispiel verwenden
einige ältere
Computer (z. B. mit 16-bit
Intel Microprozessoren) 16-bit Zeiger, während Computer einer neueren
Generation jetzt eingeführt
werden, die 64-bit Zeigergrößen (z.
B. Computer, die auf dem DEC Alpha Prozessor beruhen) verwenden.
Es wird erwartet, dass in der Zukunft Computerplattformen mit anderen
als 32-bit Zeigergrößen, z.
B. 128-bit Zeiger, eingeführt
werden. Eine effektive Plattform-übergreifende RPC Facility liefert
allerdings wünschenswerterweise
Interoperabilität
in einer heterogenen Computerumgebung, die Computer umfasst, deren
natives Datenformat Zeigergrößen aufweist,
die anders sind als 32-bit. Dementsprechend gibt es ein Problem
der Interoperabilität
der RPC Remoting Facility mit Computern, deren natürliches
Datenformat Zeigergößen aufweist,
die nicht der „On-the-Wire"-(Verbindungs-) Darstellung
entsprechen. Dieses Problem wird im Folgenden als das nicht-konforme Zeigergrößenproblem
bezeichnet.
-
Eine
weitere Einschränkung
in dieser Umgebung ist es, dass die DCOM RPC Remoting Facility bereits
als Mechanismus zur Kommunikation in vielen verteilten Netzwerkinstallationen
eingesetzt wird. Es ist deshalb wünschenswert, die RPC Facility,
die auf existierenden Computern in diesen Umgebungen bereits installiert
ist, nicht zu verändern,
wenn Computer mit Zeigergrößen, die
nicht zur „On-the-Wire" Darstellung konform
sind, hinzugefügt
werden.
-
Zusätzliche
Einschränkungen
zu einer effektiven Lösung
des nicht-konformen Zeigergrößenproblems
ergeben sich daraus, dass die optimierte Leistung des Reader-Makes-Right-Protokolls
vorzugsweise beibehalten wird. Vorzugsweise ma ximiert die Lösung auch
die Beibehaltung des Codes, minimiert Designänderungen und verändert die
Benutzerschnittstelle der existierenden eingesetzten RPC Facility
nicht.
-
Die
DCOM RPC Remoting Facility umfasst einen nicht-konformen Code-Pfad,
in dem MIDL Compiler zum Erzeugen von Serialisierungs-/Deserialisierungs-Code
(d. h. Proxies und Stubs), die für
einen Computer mit einem nativen Datenformat für eine 16-bit Zeigergröße spezifisch
sind (d. h. eine Computerplattform, die das Microsoft WINDOWS 3.x Betriebssystem
einsetzt, die eine 16-bit Zeigergröße auf einem Intel Microprozessor
aufweist). Dieser nicht-konforme Code-Pfad ist spezifisch für Serialisieren
und Deserialisieren des 16-bit Datenformats von WINDOWS in die RPC-Puffer
mit NDR-Darstellung und verarbeitet keine anderen nicht-konformen Zeigergrößen. Die
vorliegende Erfindung liefert eine generische Lösung für das nicht-konforme Zeigergrößenproblem,
die Serialisieren und Deserialisieren in den RPC-Puffer von Zeigern
beliebiger Größe unterstützt, die
nicht der On-Wire-Datendarstellung entsprechen. Die RPC Facility
der Erfindung umfasst einen Compiler für eine Schnittstellen-Beschreibungssprache
(IDL), die Serialisierungs- und Deserialisierungs-Code erzeugt (z.
B. Proxies und Stubs), um RPC-Pufferdaten in einer multikanonischen
Darstellung auf Basis eines Reader-Makes-Right-Protokolls zu schreiben.
Der IDL-Compiler umfasst zusätzlich Routinen,
um den Serialisierungs- und Deserialisierungs-Code in den Proxies
und Stubs zu erzeugen, um ein Serialisieren und Deserialisieren
von jeder beliebigen nicht-konformen Zeigergröße zu ermöglichen. Wenn der IDL-Compiler
auf einem Computer mit einem Datenformat mit einer nicht-konformen
Zeigergröße läuft, erzeugt
diese Routine automatisch den Serialisierungs- und Deserialierungs-Code,
um jeden Zeiger geeignet zu übersetzen,
der in die multikanonische Darstellung in einen RPC-Puffer serialisiert
wird.
-
In Übereinstimmung
mit einem Aspekt der Erfindung stellt die IDL Compilerroutine fest,
ob die Daten, die in den RPC-Puffer serialisiert werden, eine komplexe
Struktur besitzen, deren Größe im Speicher
nicht dieselbe wie die in der multika nonischen Darstellung ist.
In dem Fall, in dem der IDL-Compiler auf einem Computer läuft, dessen
Datenformat eine nicht-konforme Zeigergröße aufweist, besitzen alle Daten,
die Zeiger enthalten, eine komplexe Struktur. Der IDL-Compiler erzeugt
dann den Serialisierungs-/Deserialisierungs-Code des Proxys und Stubs,
um die Größe der Zeiger
in der Struktur an eine Größe anzupassen,
die von dem multikanonischen Format erlaubt wird, während sie
in den RPC-Puffer serialisiert werden, und sie an die nicht-konforme
Zeigergröße anzupassen,
wenn sie aus dem RPC-Puffer deserialisiert werden.
-
Weitere
Merkmale und Vorteile der Erfindung werden aus der folgenden detaillierten
Beschreibung einer veranschaulichenden Ausführungsform deutlich, die mit
Bezug auf die beigefügten
Zeichnungen fortschreitet.
-
Kurze Beschreibung
der Zeichnungen
-
1 ist
ein Blockdiagramm eines Computersystems, das verwendet werden kann,
um ein Verfahren und eine Vorrichtung zu implementieren, das die
Erfindung zum Serialisieren und Deserialisieren von nicht-konformen
Zeigergrößen implementiert.
-
2 ist
ein Blockdiagramm einer standardmäßigen Serialisierungs-Architektur der DCOM
RPC Remoting Facility.
-
3 ist
ein Blockdiagramm einer beispielhaften Datenstruktur eines Zeigerfeldes,
die durch die DCOM RPC Remoting Facility von 2 serialisiert
werden sollen.
-
4 ist
ein Blockdiagram einer multikanonischen Datendarstellung (z. B.
NDR) der Datenstruktur des Zeigerfeldes von 3, so wie
es in einen RPC-Puffer durch die DCOM RPC von 2 serialisiert
wird.
-
5 ist
ein Blockdiagramm, das die Serialisierung der beispielhaften Datenstruktur
eines Zeigerfeldes von 3 in den RPC-Puffer in einem
Fall darstellt, in dem die Zeigergröße der On-Wire-multikanonischen
Datendarstellung entspricht.
-
6 ist
ein Blockdiagramm, das die Deserialisierung der beispielhaften Datenstruktur
eines Zeigerfeldes aus dem RPC-Puffer von 4 in einen Speicher
eines Zielcomputers darstellt, der eine Zeigergröße hat, die der multikanonischen
Datendarstellung entspricht.
-
7 ist
ein Blockdiagramm, das die Deserialisierung der beispielhaften Datenstruktur
eines Zeigerfeldes aus dem RPC-Puffer von 4 in den Speicher
eines Zielcomputers mit einer nicht-konformen Zeigergröße darstellt.
-
8 ist
eine Liste mit Pseudo-Code eines Makros zum Serialisieren von generischen
Zeigern mit nicht-konformer Größe gemäß der Erfindung
in der dargestellten Serialisierungsarchitektur von 2.
-
9 ist
eine Liste mit Pseudo-Code der Vereinbarung einer Datenstruktur,
die Serialisieren von generischen Zeigern mit nicht-konformer Größe gemäß der Erfindung
unterstützt,
die in der Serialisierungsarchitektur von 2 dargestellt
ist.
-
10 ist
eine Liste mit Pseudo-Code einer MIDL-Compiler Routine, um Größen von
Datentypen zum Serialisieren von generischen Zeigern mit nicht-konformer
Größe gemäß der Erfindung
festzusetzen, wie in der Serialisierungsarchitektur von 2 dargestellt
ist.
-
11 ist
eine Liste von Pseudo-Code einer MIDL-Compiler Routine zum Feststellen,
ob eine Datenstruktur komplex ist, zum Serialisieren von generi schen
Zeigern mit nicht-konformer Größe gemäß der Erfindung,
die in der Serialisierungsarchitektur von 2 dargestellt
ist.
-
12 ist
eine Liste mit Pseudo-Code einer Serialisierungs-Routine, um generische
Zeiger mit nicht-konformer Größe entsprechend
der Erfindung zu serialisieren, die in der Serialisierungsarchitektur von 2 dargestellt
ist.
-
13 ist
eine Liste mit Pseudo-Code einer Deserialisierungs-Routine, um ein
komplexes Feld zu deserialisieren, das generische Zeiger mit nicht-konformer Größe entsprechend
der Erfindung enthält,
wie es in der Serialisierungsarchitektur von 2 dargestellt
ist.
-
Detaillierte
Beschreibung der dargestellten Ausführungsformen
-
Die
vorliegende Erfindung ist auf ein Verfahren und System zum Serialisieren
von generischen Zeigern mit nicht konformer Größe gerichtet. In einer hier
dargestellten Ausführungsform
ist die Erfindung in einer Serialisierungsarchitektur 100 (2)
für komponentenbasierten
Programmfernaufruf (Remote Procedure Call, RPC) enthalten, die einen
Teil eines Objektmodells oder -Systems für ein verteiltes Netzwerk von
Computern bildet, das den Titel „Microsoft Distributed Component
Object Model" (DCOM) trägt und von
der Microsoft Corporation aus Redmond, Washington, vermarktet wird.
Kurz gesagt, liefert diese Software transparente Programmfernaufrufe über ein
verteiltes Netzwerk von potentiell heterogenen Computern. Genauer
gesagt liefert die DCOM RPC Serialisierungsarchitektur 100 ein
automatisches Serialisieren von Schnittstellen-Funktionsaufrufen über die
Grenzen von Prozess- und Maschinengrenzen hinweg, wobei die DCE
NDR multikanonische On-Wire-Datendarstellung und ein Reader-Makes-Right-Serialisierungs-Protokoll
verwendet wird.
-
Beispielhafte Ausführungsumgebung
-
Mit 1 und
der folgenden Erörterung
ist es beabsichtigt, eine kurze, allgemeine Beschreibung einer geeigneten
Computerumgebung zu liefern, in der die Erfindung implementiert
werden kann. Während
die Erfindung im allgemeinen Kontext von Computer-ausführbaren
Anweisungen eines Computerprogramms beschrieben wird, das auf einem
Personal Computer läuft,
werden Fachleute erkennen, dass die Erfindung auch in Kombination
mit anderen Programmmodulen implementiert werden kann. Programmmodule
umfassen im Allgemeinen Routinen, Programme, Komponenten, Datenstrukturen
usw., die bestimmte Aufgaben ausführen oder bestimmte abstrakte
Datentypen implementieren. Darüber
hinaus ist es für
Fachleute klar, dass die Erfindung mit anderen Konfigurationen von
Computersystemen ausgeführt
werden kann, die tragbare Geräte,
Multiprozessor-systeme,
Mikroprozessor-basierte oder programmierbare Unterhaltungselektronik,
Minicomputer, Mainframe-Computer und Ähnliches umfasst. Die dargestellte
Ausführungsform
der Erfindung wird auch in verteilten Computerumgebungen angewandt, in
denen Aufgaben durch Verarbeitungsgeräte an anderen Orten durchgeführt werden,
die durch ein Kommunikationsnetzwerk verbunden sind. Einige Ausführungsformen
der Erfindung können
aber auch auf unabhängigen
Computern durchgeführt
werden. In einer verteilten Computerumgebung können Programmmodule sowohl
in lokalen als auch an anderen Orten befindlichen Speichergeräten befinden.
-
Mit
Bezug auf 1 umfasst ein beispielhaftes
System zur Implementierung der Erfindung einen konventionellen Personal
Computer 20, der eine Verarbeitungseinheit 21,
einen Systemspeicher 22 und einen Systembus 23 umfasst,
der verschiedene Systemkomponenten miteinander verbindet, einschließlich dem
Systemspeicher mit der Verarbeitungseinheit 21. Die Verarbeitungseinheit
kann irgendeine von verschiedenen kommerziell verfügbaren Prozessoren
sein, einschließlich
Intel X 86, Pentium und kompatible Mikroprozessoren von Intel und
anderen, einschließlich.
Cyrix, AMD und Nexgen; Alpha von Digital, MIPS von MIPS Technology,
NEC, IDT, Siemens und anderen, und der PowerPC von IBM und Motorola.
Duale Mikroprozessoren und andere Multiprozessor-Architekturen können auch
als Verarbeitungseinheit 21 verwendet werden.
-
Der
Systembus kann irgendeiner von verschiedenen Typen einer Busstruktur
sein, einschließlich
einem Speicherbus oder Speichercontroller, einem peripheren Bus
und einem lokalen Bus, der irgendeine einer Vielzahl von konventionellen
Busarchitekturen verwendet, wie etwa PCI, AGP, VESA, Microchannel,
ISA und EISA, um nur einige zu nennen. Der Systemspeicher umfasst
Read Only Memory (ROM) 24 und Random Access Memory (RAM) 25. Ein
Basic Input/Output System (BIOS) ist in ROM 24 gespeichert
und enthält
die Basisroutinen zur Unterstützung
des Transfers von Information zwischen Elementen innerhalb des Personal
Computers 20, wie etwa während des Hochfahrens.
-
Der
Personal Computer 20 umfasst weiterhin ein Festplattenlaufwerk 27,
ein magnetisches Diskettenlaufwerk 28, z. B. zum Lesen
von und Schreiben auf eine entfernbare Diskette 29, und
ein optisches Laufwerk 30, z. B. zum Lesen einer CD-ROM 31 oder zum
Lesen von oder Schreiben auf andere optische Medien. Das Festplattenlaufwerk 27,
magnetisches Diskettenlaufwerk 28 und optisches Laufwerk 30 sind jeweils
mit dem Systembus 23 durch ein Festplattenlaufwerk-Interface 32,
ein magnetisches Diskettenlaufwerk-Interface 33 und ein
optisches Laufwerk-Interface 34 mit dem Systembus 23 verbunden.
Die Laufwerke und ihre zugeordneten Computer-lesbaren Medien liefern
nicht-flüchtiges
Speichern von Daten, Datenstrukturen, Computer-ausführbaren
Anweisungen usw. für
den Personal Computer 20. Obwohl sich die Beschreibung
der Computer-lesbaren Medien oben auf eine Festplatte, eine entfernbare magnetische
Diskette und eine CD bezieht, sollte es Fachleuten klar sein, dass
andere Typen von Medien, die von einem Computer gelesen werden können, wie
etwa magnetische Kassetten, Flash-Memory-Karten, digitale Video-Discs,
Bernoulli-Cartridges und ähnliches
ebenso in der beispielhaften Betriebsumgebung verwendet werden können.
-
In
den Laufwerken und RAM 25 können mehrere Progammmodule
gespeichert werden, einschließlich
einem Betriebssystem 35, einem oder mehreren Anwendungsprogammen 36,
anderen Progammmodulen 37 und Progammdaten 38.
-
Ein
Nutzer kann Kommandos und Informationen in den Personal Computer 20 mit
einem Keyboard 40 und einem Zeigegerät wie etwa einer Maus 42 eingeben.
Andere Eingabegeräte
(nicht gezeigt) können
ein Mikrofon, Joystick, Game Pad oder Satellitenschüssel, Scanner
oder ähnliches
umfassen. Diese und andere Eingabegeräte sind mit der Verarbeitungseinheit 21 oft
durch ein serielles Interface 46 verbunden, das an. den
Systembus angeschlossen ist, das aber durch andere Schnittstellen
wie etwa einem Parallelanschluss, Spieleanschluss (Game Port) oder
einem Universal Serial Bus (USB) verbunden sein kann. Ein Monitor 47 oder
andere Typen von Wiedergabegeräten
sind auch mit dem Systembus 23 über eine Schnittstelle, wie
z. B. einem Videoadapter 48, angeschlossen. Zusätzlich zu
dem Monitor umfassen Personal Computer typischerweise andere periphere
Ausgabegeräte
(nicht gezeigt), wie etwa Lautsprecher und Drucker.
-
Der
Personal Computer 20 kann in einer vernetzten Umgebung
arbeiten, die logische Verbindungen zu einem oder mehreren entfernten
Computern, wie etwa einem entfernten Computer 49 benutzt.
Der entfernte Computer 49 kann ein Server, ein Router, ein
gleichrangiges Gerät
oder ein anderer gewöhnlicher
Netzwerkknoten sein und umfasst typischerweise viele oder alle der
Elemente, die mit Bezug auf den Personal Computer 20 beschrieben
wurden, obwohl nur ein Speichergerät 50 in 1 dargestellt wurde.
Die in 1 dargestellten logischen Verbindungen umfassen
ein lokales Netzwerk (Local Area Network, LAN) 51 und ein
weiträumiges
Netzwerk (Wide Area Network, WAN) 52. Solche Netzwerkumgebungen
sind alltäglich
in Büros,
unternehmensweiten Computernetzwerken, Intranets und dem Internet.
-
Wenn
der Personal Computer 20 in einer LAN-Netzwerkumgebung
verwendet wird, ist er mit dem lokalen Netzwerk 51 durch
eine Netzwerk-Schnittstelle oder -Adapter 53 verbunden. Wenn
der Personal Computer in einer WAN-Netzwerkumgebung verwendet wird, umfasst
er typischerweise ein Modem 54 oder andere Mittel zum Herstellen von
Kommunikation über
das großräumige Netzwerk 52,
wie z. B. das Internet. Das Modem 54, das ein internes
oder externes sein kann, ist mit dem Systembus 23 über eine
serielle Schnittstelle des Anschlusses 46 verbunden. In
einer vernetzten Umgebung können
Programmmodule, die mit Bezug auf den Personal. Computer 20 dargestellt
sind, oder Teile davon in dem entfernten Speichergerät gespeichert werden.
Es sollte klar sein, dass die gezeigten Netzwerkverbindungen nur
beispielhaft sind und dass andere Mittel zum Herstellen einer Kommunikationsverbindung
zwischen den Computern verwendet werden können.
-
In Übereinstimmung
mit der Praxis von Fachleuten der Computerprogrammierung wird die
vorliegende Erfindung unten mit Bezug auf Vorgänge und symbolische Darstellungen
von Abläufen
beschrieben, die durch den Personal Computer 20 durchgeführt werden,
soweit nicht anders angegeben. Solche Vorgänge und Abläufe werden manchmal als von
einem Computer ausgeführt
bezeichnet. Es sollte deshalb klar sein, dass die Vorgänge und
symbolisch dargestellten Abläufe
die Manipulation von elektrischen Signalen, die Daten darstellen,
durch die Verarbeitungseinheit 21 umfassen, die eine resultierende
Transformation oder Reduktion der elektrischen Signaldarstellung
verursacht, sowie die Verwaltung von Datenbits an Speicherorten
in dem Speichersystem (einschließlich dem Systemspeicher 22,
Festplattenlaufwerk 27, Floppy Discs 29 und CD-ROMs 31),
um damit die Abläufe
des Computersystems zu rekonfigurieren oder auf andere Weise zu ändern, sowie
sonstige Verarbeitung von Signalen. Die Speicherorte, in denen die
Daten-Bits verwaltet werden, sind physikalische Orte mit bestimmten
elektrischen, magnetischen oder optischen Eigenschaften, die den Daten-Bits
entsprechen.
-
Überblick von DCOM RPC Remoting
(Fernzugriff auf Daten)
-
Mit
Bezug auf 2 liefert die DCOM RPC Serialisierungsarchitektur 100 einen
Compiler 102 für die
Microsoft Interface Description Language (MIDL) und Laufzeitdienste
für System-RPC
(„System
RPC") 104.
Die Architektur 100 baut auf Microsoft's Component Object Model (COM) auf,
die eine binäre
Struktur für
objektorientierte Komponenten definiert, und zusammen mit Microsoft's Object Linking
and Embedding (OLE), Distributed Component Object Model (DCOM) und ähnlichen
Technologien ein System für interoperable
Komponenten liefert, die aus verschiedenen Quellen integriert werden
können,
um Software-Applikationen
zu bilden. COM, OLE, DCOM und ähnliche
Technologien sind Fachleuten aus vielen weit verbreiteten Publikationen
bekannt, wie etwa Brockschmidt, Inside OLE, 2nd Edition (1995),
und Chappell, Understanding ActiveX und OLE, (1996), die beide von
Microsoft Press erhältlich
sind.
-
Als
Antwort auf die Anfrage eines Clients 108 (der eine COM
Komponente oder ein anderes Software-Programm sein kann), einen
Schnittstellenzeiger zu einer Out-off-Process-Komponente oder einer Komponente
eines entfernten Servers 110 zu übertragen, veranlasst der System-RPC 104 den MIDL-Compiler 102,
Code zum Serialisieren und Deserialisieren von Daten zwischen Prozessen 112, 113 zu
erzeugen, in denen die Client- und Server-Komponenten ablaufen.
Der Code zum Serialisieren und Deserialisieren auf der Client-Seite
(bezeichnet als „Facelet", auch als eine COM-Komponente
implementiert) ist in einem Proxy 116 enthalten, der prozessintern
mit dem Client läuft.
Der MIDL-Compiler 102 konstruiert den Proxy 116,
um eine selbe Schnittstellenstruktur wie die angeforderte Schnittstelle
der Server-Komponente 110 zu unterstützen. Der Client kann dann
dieses Interface auf dem Proxy 116 direkt als einen prozessinternen
Aufruf aufrufen, um mit der Serverkomponente 110 zu interagieren.
Der Proxy 116 antwortet auf solche Aufrufe, indem er die
notwendigen Daten (z. B. Aufrufparameter und ähnliche Datenstrukturen im
Adressraum des Client-Prozesses im Speicher) in einen RPC-Puffer
hinein serialisiert (ein Beispiel dafür wird unten beschrieben und ist
in 4 dargestellt).
-
Der
von dem MIDL-Compiler 102 erzeugte Code zum Serialisieren
und Deserialisieren auf der Serverseite (bezeichnet als ein „Stublet", und auch als eine
COM-Komponente implementiert)
ist in einem Stub 118 enthalten, der prozessintern mit
der Serverkomponente 110 läuft (die sich auf einem selben
Computer wie der Client oder auf einem davon entfernten Computer
befinden kann). Der Stub 118 bewältigt direkte Interaktion mit
der Serverkomponente 110, indem die von dem Proxy 116 in
den Adressraum des Serverkomponentenprozesses gesandten Daten deserialisiert
werden und indem der geeignete Schnittstellen-Funktionsaufruf aufgerufen wird,
den der Client ursprünglich
auf dem Proxy 116 aufgerufen hatte. Der Stub serialisiert
weiterhin einen Antwortwert, Ausgabeparameter und ähnliche
Datenstrukturen aus dem Adressraum des Serverprozesses zum Rücktransfer
zu dem Clientprozess 112.
-
Die
zu serialisierenden Daten an jedem Ende des RPC-Aufrufs sind aus
einer Beschreibung (IDL-Text) 120 der gegenständlichen
Schnittstelle der Serverkomponente bekannt, die von dem Entwickler der
Serverkomponente in der Microsoft Interface Description Language
(MIDL) geliefert wird. Basierend auf dieser Beschreibung erzeugt
der MIDL-Compiler 102 den geeigneten Code (das Facelet
und Stublet) in dem Proxy 116 und Stub 118, um
die notwendigen Daten zwischen den Prozessen 112-113 zu
serialisieren und deserialisieren.
-
Der
System-RPC 104 liefert einen RPC-Kanal 124-125 an
jeden der Client- und Serverprozesse 112-113,
die der Proxy und Stub zur Kommunikation verwenden (d. h. zum Weitergeben
des RPC-Puffers). Der RPC-Kanal ist ein Objekt aus der COM-Bibliothek,
der Details des zugrunde liegenden Transports zwischen Prozessen
oder in einem Netzwerk (zwischen Computern) einkapselt. Der RPC-Kanal verwendet
COM-Systemdienste für
Kommunikation zwischen Prozessen auf derselben Maschine (angezeigt
bei 130) und verwendet Netzwerk-Transport- Progammierschnittstellen 132 des
Computersystems für
Kommunikation über
Maschinengenzen hinweg.
-
Die
DCOM RPC Serialisierungsarchitektur 100 (die die Serialisierungsmerkmale
der vorliegenden Erfindung für
generische Zeiger von nicht-konformer Größe nicht enthält) ist
gut bekannt, und weitere Details können aus überall erhältlichen Publikationen entnommen
werden, wie z. B. Brockschmidt, Inside OLE, 2nd Edition, 277-338
(1995), u. a. Das Serialisieren von generischen Zeigern nicht-konformer Größe gemäß der Erfindung
verbessert die gezeigte DCOM RPC Serialisierungsarchitektur 100, um
die Architektur für
plattformübergeifende
Interoperabilität
mit Computern, die beliebige Zeigergößen aufweisen, zu erweitern.
-
Beispiel einer Serialisierung
einer nicht-konformen Zeigergröße
-
Mit
Bezug auf 3-8 zeigt
das folgende Beispiel ein Serialisieren einer beispielhaften Datenstruktur 150 in
der gezeigten DCOM RPC Serialisierungsarchitektur 100 (2)
in Fällen,
die konforme und nicht-konforme Datenformate von Zeigergößen auf
der Client- und der Serverseite umfassen. Die beispielhafte Datenstruktur 150 ist
ein einfaches Feld von Zeigern auf Long Integers (d. h. 4 Byte oder 32-bit
Integer-Werte), wie es durch die folgende Deklaration in der Progammiersprache
C dargestellt werden kann.
long*array[2];
-
Die
beispielhafte Datenstruktur 150 dieses Beispiels hat im
Speicher eine Anordnung wie in 3 gezeigt,
in der Speicherorte 152-153 (z. B. im RAM-Speicher 25 des
Computers, auf dem sich der Client 108 von 2 befindet)
jeweils 32-bit Zeiger enthalten, die jeweils Speicherorte 156-157 referenzieren.
Die Speicherorte 156-157 enthalten wiederum zwei Long Integer-Werte
(bezeichnet A und B in 3). Das entspricht den folgenden
Anweisungen in der Progammiersprache C.
*(array[0] = A; *(array[1])
= B;
-
In
der dargestellten Serialisierungsarchitektur 100 von 2 muss
der Proxy 116 (oder Stub 118, abhängig davon,
ob die Datenstruktur als ein Eingabeparameter oder Ausgabeparameter
des Schnittstellen-Funktionsaufrufs serialisiert wird) sowohl die
Zeiger in dem Feld als auch die zwei Integer-Werte A und B, auf
die die Zeiger verweisen, in einen RPC-Puffer 160 (4)
zum Transport zu dem entgegen gesetzten Prozess 112-113 serialisiert
werden. In Übereinstimmung
mit der NDR multikanonischen Darstellung werden die Pointer (array[0]
und array[1]) als Flags (Flag 0 und Flag 1) in den RPC Puffer 160 serialisiert,
die angeben, ob der jeweilige Zeiger tatsächlich einen Wert im Speicher
referenziert (d. h., ob der Zeiger NULL oder nicht-NULL beträgt). Da
Daten aus dem RPC-Puffer auf deterministische Weise serialisiert
und deserialisiert werden, basierend auf der MIDL-Beschreibung der
Schnittstelle der gegenständlichen
Serverkomponente, ist dieses Flag ausreichend zum Deserialisieren
von Code auf der anderen Seite, um zu rekonstruieren, welcher der
Datenwerte in dem RPC-Puffer, der dem Flag folgt, von jedem Pointer
referenziert wird. Entsprechend der NDR multikanonischen Darstellung beträgt die Größe des Flags
für jeden
Zeiger 32-bit. Die beispielshafte Datenstruktur 150 kann
deshalb in den RPC-Puffer 160 in der in 4 gezeigten
Darstellung serialisiert werden, der aus zwei 32-bit Flags an Pufferorten 162-163 für die zwei
Feldzeiger besteht, die von den long-Integer-Werten A und B bei Pufferorten 164-165 mit
einer Summe von 16 Bytes gefolgt werden.
-
In
einem Fall, wo die Zeigergröße des natürlichen
Datenformats des Serialisierungsprozesses 32-bit beträgt, kann
der Proxy (oder Stub) der die beispielhafte Datenstruktur 150 serialisiert,
das Serialisieren mit einer einfachen Blockkopie des Zeigerfeldes
(d. h. array[0] und array[1] an Speicherorten 152-153)
in die Pufferorte 162-163 bewirken, wie in 5 gezeigt.
-
Die
Werte der Zeiger fungieren deshalb als Flags, die einen NULL- oder
nicht-NULL-Zeiger
bezeichnen (ein Flag, dessen Wert Null ist, bezeichnet einen NULL-Zeiger,
während
ein nicht-Null-Flag einen nicht-NULL-Zeiger bezeichnet). Die Integerwerte A
und B an den Speicherorten 156 und 157, die von den
Zeigern referenziert werden, werden einzeln in die Pufferorte 164-165 kopiert.
-
In
einem in 6 dargestellten Fall, in dem das
Datenformat des Serialisierungsprozesses eine andere Zeigergröße als 32-bit
hat (d. h., der Fall eines Datenformats mit einer Zeigergröße, die
nicht der multikanonischen On-Wire-Darstellung entspricht), kann der Serialisierungscode
in dem Proxy 116 (2) oder
Stub 118 (2) allerdings nicht einfach
blind das Zeigerfeld aus dem Adressraum des Prozesses in den RPC-Puffer 160 kopieren.
Stattdessen werden die Zeiger einzeln aus ihren Speicherorten 152' und 153' in den RPC-Puffer 160 serialisiert (d.
h., der Serialisierungscode setzt 32-bit NULL/non-NULL Flags in
die Speicherorte 162-163, je nachdem, ob die 64-bit
Feldzeiger NULL oder nicht betragen). Zum Beispiel, wenn die Feldzeiger
(array[0] und array[1]) eine Größe von 64-bit
haben, überprüft der Serialisierungscode
einzeln, ob jeder Pointer NULL beträgt und setzt das entsprechende Flag
in den RPC-Puffer dementsprechend. Die Integerwerte A und B werden
auch einzeln in die Pufferorte 164-165 kopiert.
-
In
dem Zielprozess auf der anderen Seite des RPC wird der RPC-Puffer 160 deserialisiert,
um die beispielhafte Datenstruktur 150 in dem Adressraum
des Zielprozesses in dem natürlichen
Datenformat des Zielprozesses zu platzieren. Falls möglich, wird
die Deserialisierungsprozedur optimiert durch gleichzeitiges Kopieren
(d. h. Kopieren von Blocks) von Gruppen der Datenelemente in dem
RPC-Puffer in einen neu zugewiesenen Puffer in den Adressraum des
Zielprozesses, oder durch Deserialisieren der Datenelemente an derselben
Stelle in dem RPC-Puffer (der selbst in den Adressraum des Zielprozesses durch
den Netzwerktransport 132 und den System-RPC 104 von 2 transferiert
wird). Allerdings gibt es Fälle,
in denen diese Optimierungen nicht durchgeführt werden können. Ein
Feld, das weder an derselben Stelle in dem RPC-Puffer deserialisiert noch
blockkopiert werden kann, wie etwa aufgrund der Notwendigkeit, die
Größe der Zeiger
zu verän dern,
wird hier als ein komplexes Feld bezeichnet. Insbesondere, in einem
in 7 gezeigten Fall, in dem der Zielprozess auf einem
32-bit Computer läuft und
deshalb ein natives Datenformat mit einer 32-bit Zeigergröße hat (d.
h., einer NDR-konformen
Zeigergröße) kann
der Deserialisierungscode den transferierten RPC-Puffer 160 in dem Adressraum
des Zielprozesses wieder verwenden und die Datenelemente an derselben
Stelle deserialisieren. Der Deserialisierungscode in dem Proxy oder
Stub durchquert den RPC-Puffer und fixiert jeden Zeiger in der Datenstruktur,
um das richtige Datenelement zu referenzieren. In diesem Beispiel
wird die Adresse des Pufferortes 164, die den Long Integer
A enthält,
in den Pufferort 162 platziert, und die Adresse des Pufferortes 165,
die den Long Integer B enthält,
wird in den Pufferort 162 platziert. Die beispielhafte
Datenstruktur 150 wird deshalb in dem Adressraum des Zielprozesses
wieder hergestellt, wobei die Zeiger array[0] und array[1] ihre
jeweiligen Long Integer-Werte A und B richtig referenzieren.
-
8 stellt
einen Fall dar, in dem der Zielprozess auf einem Computer mit einem
Datenformat mit einer nicht-konformen Zeigergröße abläuft (insbesondere einer Größe größer als
das und durch das NDR multikanonische Format unterstützte Format, wie
etwa 64-bit). In diesem Fall kann die beispielhafte Datenstruktur 150 nicht
einfach am selben Ort in den RPC-Puffer wie in 7 serialisiert
werden, weil zusätzlicher
Platz benötigt
wird, um die größeren Zeiger unterzubringen.
Dementsprechend weist der Deserialisierungscode in dem Proxy oder
Stub einen neuen Puffer 170 mit einer geeigneten Größe zu, um
die größeren Zeiger
unterzubringen. Der Serialisierungscode kopiert dann die Datenwerte
in den neuen Puffer (wie benötigt)
und fixiert die Zeiger, so dass sie ihre jeweiligen Datenelement
referenzieren. In diesem Falle weist der Deserialisierungscode 16 Bytes für den neuen
Puffer 170 zu, damit er die zwei 64-bit Zeiger an den Pufferorten 172-173 unterbringen kann,
und setzt dann die Adressen der Speicherorte 164-165,
die die Long Integers A und B enthalten, in die neuen Pufferorte 172-173 der
zwei Zeiger. Dies erzeugt die beispielhafte Datenstruktur eines
Zeigerfeldes im Adress raum des Zielprozesses, wobei die Zeiger geeignete
Größen für das native
Datenformat des Computers aufweisen, auf dem der Prozess läuft.
-
Generische
nicht-konforme Zeigergößen-Serialisierung
-
In Übereinstimmung
mit der Erfindung enthält
die gezeigte Serialisierungsarchitektur 100 (2)
Programmcode, um generisch jede beliebige nicht-konforme Zeigergröße zu serialisieren
und deserialisieren. Dieser Programmcode zum generischen Serialisieren
von nicht-konformen Zeigergrößen kann übersetzt
werden, um auf einer Computerplattform mit einem Datenformat mit
einer beliebigen nicht-konformen Zeigergröße zu laufen, wobei ein Compiler
entsprechend einem Industriestandard (z. B. einem Compiler für die Programmiersprache
C) für diese
Plattform verwendet wird. Diese Programmcode zum generischen Serialisieren
von nicht-konformen Zeigergrößen, der
auf der Computerplattform läuft,
wird dann in der gezeigten Serialisierungsarchitektur 100 ablaufen,
um die Zeiger beliebiger Größe in die
NDR-multikanonische Darstellung in den RPC-Puffer (z. B. RPC-Puffer 160 von 4)
richtig zu serialisieren und deserialisieren. Der generische Programmcode
zum Serialisieren von nicht-konformen Zeigergrößen passt die beliebige nicht-konforme
Größe an, indem
einfach auf die neue Computerplattform übersetzt wird, ohne dabei irgendeinen Code
für eine
spezifische Zeigergröße schreiben oder
umschreiben zu müssen.
Die dargestellte Serialisierungsarchitektur 100 kann deshalb
RPC-Interoperabilität
in einer verteilten Umgebung von heterogenen Computern liefern,
einschließlich
gegenwärtig verfügbarer und
zukünftiger
Computerplattformen mit Datenformaten von nicht-konformen Zeigergrößen (z.
B. gegenwärtige
64-bit Computerplattformen, wie etwa der DEC-Alpha, als auch zukünftige Computerplattformen,
die irgendeine nicht-konforme Zeigergröße verwenden). Weiterhin kann
die dargestellte Serialisierungsarchitektur deshalb leicht und schnell in
diesen neuen Computerplattformen von verschiedenen, beliebigen nicht-konformen
Zeigergrößen eingesetzt
werden, sowie diese Computerplattformen eingeführt werden.
-
Wenn
die dargestellte Serialisierungsarchitektur 100, die den
generischen Programmcode zum Serialisieren von nicht-konformen Zeigergrößen enthält, auf
eine Computerplattform übersetzt
wird, wird der Programmcode zum generischen Serialisieren von nicht-konformen
Zeigergrößen auf
die spezifische Zeigergröße des Datenformats
der Computerplattform konfiguriert, indem das folgende Konstrukt einer
Programmiersprache verwendet wird (z. B. in einem Header-File des
Quellcodes der gezeigten Serialisierungsarchitektur):
MemorySize
= sizeof(void*);
-
Dieses
Programmiersprachenkonstrukt legt fest, dass die Programmkonstante,
MemorySize die Zeigergröße des nativen
Datenformats der Computerplattform angibt und von Routinen in dem
Code zum generischen Serialisieren von nicht-konformen Zeigergrößen verwendet wird, um Zeiger
dieser Zeigergröße richtig
zu serialisieren und deserialisieren. Das Konstrukt entspricht dem
Programmiersprachenstandard ANSI C und wird im Allgemeinen durch Compiler
unterstützt,
die diesem Industriestandard entsprechen. Der Programmcode zum generischen Serialisieren
von nicht-konformen Zeigergrößen konfiguriert
sich deshalb selbst, um die bestimmte Zeigergröße der Computerplattform zu
serialisieren und deserialisieren, ohne dass dazu ein Entwickler
Serialisierungscode für
eine bestimmte nicht-konforme Zeigergröße schreiben muss.
-
Mit
Bezug auf 9-14 enthält der Code
zum generischen Serialisieren von nicht-konformen Zeigergrößen Routinen,
um Daten zu serialisieren und deserialisieren, die Zeiger der nicht-konformen
Zeigergröße enthalten,
wie sie von dem obigen Konstrukt während der Übersetzung auf die Ziel-Computerplattform
festgelegt wurde.
-
Diese
Routinen umfassen Routinen in dem MIDL-Compiler 102 (2),
dem Proxy 116 (2) und dem Stub 118 (2),
die von dem MIDL-Compiler 102 erzeugt wurden, wie auch
die Makros und Datenstrukturen, die mit dem MIDL- Compiler 102 verknüpft sind.
Kommentare, die in die Routinen in 9-14 eingefügt sind,
geben Vergleiche zu entsprechenden Routinen der früheren Microsoft DCOM
RPC Serialisierungsarchitektur an, die nur mit konformen Zeigern
umgehen oder für
eine nicht-konforme Zeigergröße spezifisch
sind.
-
Insbesondere
stellt 9 ein Makro dar, das in der gezeigten Serialisierungsarchitektur 100 verwendet
wird, um den RPC-Puffer für
eine beliebige Zeigergröße richtig
anzupassen, z. B. die Zeigergröße der Computerplattform,
wie sie von dem obigen Konstrukt beim Übersetzen der Serialisierungsarchitektur
auf die Computerplattform festgelegt wurde.
-
10 zeigt
eine Datenstruktur zum Speichern von Zeigerwerten, die während des
Deserialisierens in dem von dem MIDL-Compiler erzeugten Stub 118 (2)
verwendet wird, und die generische nicht-konforme Zeigergrößen aufnimmt.
-
11 zeigt
eine Routine in dem MIDL-Compiler 102, die die Wire-Größe und Größe im Speicher
von jedem dem MIDL-Compiler bekannten Basisdatentyp festlegt. Die
Routine verwendet eine generische Case-Anweisung, um den Datentyp der
Zeigergröße im Speicher
festzulegen und die beliebige Zeigergröße der Computerplattform anzugeben,
die das oben erörterte
Programmiersprachenkonstrukt verwendet. Der von dem MIDL-Compiler erzeugte
Serialisierungs- und Deserialisierungscode kann dann das geeignete
Serialisieren und Deserialisieren durchführen, basierend auf dem festgelegten Datentyp.
-
12 zeigt
eine Routine in dem MIDL-Compiler 102 zum Feststellen,
ob die Datenstrukturen, die für
eine bestimmte Schnittstelle serialisiert werden sollen, komplex
sind oder nicht. In dem Falle, in dem die Computerplattform eine
nicht-konforme Zeigergröße aufweist
und die Daten, die für eine
Schnittstelle serialisiert werden sollen, einen nicht-Null Zeiger
aufweisen, dann weicht die Größe der Daten
im Speicher von der in dem RPC-Puffer ab und die Datenstruktur wird
als komplex angesehen. In dem gezeigten MIDL-Compiler 102 überprüft die Routi ne,
ob die Daten einen Zeiger enthalten. Wenn die Zeigergröße der Computerplattform
nicht konform ist (sie weicht von der On-Wire-Größe ab, wie sie in der in 11 gezeigte
Routine festgelegt wurde), dann behandelt die Routine die zu serialisierenden
Daten als komplex (was Größenänderungen und/oder
ein individuelle Kopieren erfordert).
-
13 zeigt
eine Routine in dem von dem MIDL-Compiler erzeugten Proxy 116 oder
Stub 118 zum Serialisieren einer beliebigen nicht-konformen Zeigergröße. Für eine komplexe
Struktur (wie sie etwa von der Routine von 12 festgestellt
wurde) serialisiert die Routine einzeln die Zeiger aus der Datenstruktur
im Speicher in den RPC-Puffer, ähnlich dem
Beispiel zum Serialisieren von nicht-konformen Zeigern, das in 6 gezeigt
ist. Die Routine schreitet durch die Datenstruktur im Speicher in
Inkrementen der beliebigen Zeigergröße des Datenformats der Computerplattform
fort, und durch den RPC-Puffer in Inkrementen von 4 Bytes (entsprechend
der NDR-Darstellung).
-
14 zeigt
eine MIDL-erzeugte Routine zum Deserialisieren einer beliebigen
Zeigergröße. Die
Routine reserviert einen Puffer geeigneter Größe, um Zeiger der beliebigen
Zeigergröße aufzunehmen,
und fixiert die Zeigerwerte zum Referenzieren der richtigen Datenwerte,
die in den RPC-Puffer serialisiert wurden, ähnlich zu dem Deserialisierungs-Beispiel
von nicht-konformen Zeigern, das in 8 gezeigt
ist.
-
Die
oben erörterten
Routinen zum Serialisieren und Deserialisieren für komplexe Strukturen bilden
deshalb einen separaten Codepfad zum Serialisieren und Deserialisieren
von Daten, die Zeiger mit nicht-konformer Größe enthalten. In der gezeigten Ausführungsform
ist dieser Codepfad generisch zum Serialisieren und Deserialisieren
von jeder beliebigen nicht-konformen Zeigergröße, und ihm wird gefolgt zum
Serialisieren von Daten, die Zeiger enthalten, wenn das Datenformat
der bestimmten Computerplattform eine nicht-konforme Zeigergröße aufweist.
-
Nachdem
die Prinzipien unserer Erfindung beschrieben und gezeigt wurden
mit Bezug auf eine gezeigte Ausführungsform,
sollte es erkennbar sein, dass die gezeigte Ausführungsform in Anordnung und
Detail modifiziert werden kann, ohne von solchen Prinzipien abzuweichen.
Es sollte klar sein, dass die hierin beschriebenen Programme, Prozesse
oder Methoden nicht bezogen oder beschränkt sind auf irgendeinen bestimmten
Typ von Computervorrichtungen, soweit nicht anders angegeben. Verschiedene Typen
von allgemeinen oder spezialisierten Computervorrichtungen können verwendet
werden oder können
Abläufe
durchführen,
in Übereinstimmung mit
der hierin beschriebenen Lehre. Elemente der gezeigten Ausführungsform,
die in Software gezeigt wurden, können in Hardware implementiert
werden und umgekehrt.
-
Insbesondere
zeigen die in 9-14 dargestellten
Routinen die Implementierung des Codes zum generischen Serialisieren
von nicht-konformen Zeigergrößen. Es
sollte Fachleuten klar sein, dass weitere Routinen und Datenstrukturen
in der Serialisierungsarchitektur, die alle beliebigen nicht konformen
Zeigergrößen gemäß der Erfindung
aufnimmt, gebildet werden können,
indem ähnliche
Prinzipien angewendet werden.