Freigeben über


RPC-NDR-Formatzeichenfolgen

NDR Engine: 32-Bit-Dolmetscher

In diesem Dokument werden die Formatzeichenfolgendeskriptoren beschrieben, die manchmal als MOPs bezeichnet werden, für das 32-Bit-NDR-Modul. In diesem Abschnitt werden Änderungen beschrieben, die mit der Entwicklung der –Oi-Dolmetscher in die -Oif Dolmetscherschicht sowie Ergänzungen im Zusammenhang mit Rohren und asynchroner Unterstützung verbunden sind.

In diesem Dokument werden die aktuelle Microsoft Interface Definition Language (MIDL)-Technologie aus der Modulperspektive und das aktuelle NDR-Modul beschrieben.

Überblick

Das NDR-Modul ist das Marshallingmodul der Remote Procedure Call (RPC) und DCOM-Komponenten. Er behandelt alle stubbezogenen Probleme eines Remoteanrufs. Als Prozess wird die NDR-Marshalling durch den C-Code von MIDL generierten Stubs, einem MIDL JIT-Typ-Generator oder von Stubs gesteuert, die von anderen Tools generiert oder manuell geschrieben wurden. Wiederum steuert das NDR-Modul die zugrunde liegende Laufzeit (DCOM oder RPC), die mit bestimmten Transporten kommuniziert.

Das ursprüngliche Ziel des Entwurfs war es, basierend auf den vom MIDL-Compiler bereitgestellten Informationen ein Werkzeug für effektives Marshalling für beliebige Daten bereitzustellen. Die in diesem Dokument beschriebenen Formatzeichenfolgen – und tatsächlich alle vom Compiler für den NDR-Modulverbrauch generierten Informationen – wurden immer als interne Schnittstelle zwischen dem Compiler und dem Modul betrachtet. Ebenso sind Schnittstellen, die dem Modul zur Behandlung von Laufzeitproblemen zur Verfügung stehen, hauptsächlich intern (einige Ausnahmen sind auf der RPC-Laufzeitseite vorhanden, und einige DCOM-Schnittstellen, die vom Modul verwendet werden, sind extern).

Zwei typische Ansätze zum Marshalling waren seit jeher inline und datengesteuerte (interpretierte) Technologie. MIDL unterstützt sowohl durch seine -Os als auch –Oi* Schalter in seinen C-generierten Stubs. Darüber hinaus kann MIDL die TLB-Bibliotheken generieren, die vom oleautomation-Paket verwendet werden. Dementsprechend besteht eine Perspektive der Inneren des Motors darin, dass es aus zwei Teilen besteht.

Der erste ist eine Reihe von Routinen, die Größenanpassung, Marshalling usw. behandeln, die typischen Datentypobjekte wie eine Struktur oder ein Array entsprechen. Diese Routinen sind für die Leistung fein abgestimmt; Sie versuchen z. B. in der Regel, Daten nach Möglichkeit zu blockieren. Dieser Teil wird häufig als kernes NDR-Modul bezeichnet.

Der zweite Teil besteht aus einem Dolmetscher und seinen verwandten Stücken. Der Dolmetscher verwendet Routinen aus dem Kernmodul NDR, als ob aus einer internen Bibliothek, um einen Remoteaufruf mit allen zugehörigen Argumenten gemarstet und ungemarstet auszuführen.

Das Kern-NDR-Modul wird auf ähnliche Weise verwendet, ob sie von Inline-Stubs oder vom Dolmetscher verwendet wird. Alle Kernmodulroutinen hängen vom Zustand ab, der von einer Stub-Nachrichtenstruktur übergeben wird. Die Struktur wird vom Inline-Stub oder vom Dolmetscher entsprechend eingerichtet. Im Laufe der Jahre wurde das Kernmodul in einem anderen Kontext verwendet; derzeit ist der Dolmetscher tatsächlich eine Reihe von verschiedenen Dolmetscherschleifen. Diese beziehen sich auf die alten und neuen (–Oi im Vergleich zu –Oif) Interpretern sowie schleifen im Zusammenhang mit der Daten serialisierung (Pickling), RPC async-Unterstützung und DCOM async-Unterstützung (RPC und DCOM haben unterschiedliche asynchrone Programmiermodelle).

Neben der Ergänzung neuer Features ist ein wichtiger Aspekt der NDR-Modulentwicklung ein allgemeiner Wandel im Ansatz von Dolmetschern. NDR version1.1 begann als Teil eines neuen MIDL 2.0-Ansatzes zum Marshallen, wobei die Inline-Stubs für Leistungsüberlegungen bevorzugt werden. Mit der neuesten Version von NDR wurde –Oif zum am häufigsten verwendeten Modus des Compilers, fast zum Ausschluss von Inline-Stubs.

Zeichenfolgenbeschreibungen im RPC-Format des NDR-Moduls werden in den folgenden Themen ausführlicher beschrieben: