Dela via

RPC NDR-formatsträngar

  • Artikel

NDR-motor: 32-bitars tolk

Det här dokumentet beskriver formatsträngsbeskrivningarna, som ibland kallas MOPs, för 32-bitars NDR-motorn. I det här avsnittet beskrivs ändringar som är associerade med utvecklingen från tolken –Oi till –Oif tolkskiktet, samt tillägg relaterade till rör och asynkront stöd.

Det här dokumentet beskriver aktuell MIDL-teknik (Microsoft Interface Definition Language) från motorperspektivet och den aktuella NDR-motorn.

Överblick

NDR-motorn är marskalkeringsmotorn för RPC- och DCOM-komponenterna (Remote Procedure Call). Den hanterar alla stub-relaterade problem med ett fjärrsamtal. Som en process drivs NDR-marshaling av C-koden från MIDL-genererade stubs, en MIDL JIT-typ generator, eller av stubs som genereras av andra verktyg eller skrivs manuellt. I sin tur styr NDR-motorn den underliggande körningstiden (DCOM eller RPC) som kommunicerar med specifika transporter.

Det ursprungliga målet med designen hade varit att tillhandahålla ett verktyg för effektiv marshaling för godtyckliga data, baserat på information från MIDL-kompilatorn. Formatsträngarna som beskrivs i det här dokumentet – och all information som genereras av kompilatorn för NDR-motorförbrukning – har alltid betraktats som ett internt gränssnitt mellan kompilatorn och motorn. På samma sätt är gränssnitt som är tillgängliga för motorn för att hantera körningsproblem också mestadels interna (vissa undantag finns på RPC-körningssidan och vissa DCOM-gränssnitt som används av motorn är externa).

Två typiska metoder för marskalkering har alltid varit infogad och datadriven (tolkad) teknik. MIDL stöder både sina -Os och -Oi* växlar i sina C-genererade stubs. Dessutom kan MIDL generera de TLB-bibliotek som används av oleautomation-paketet. Ett perspektiv på motorns inre är därför att den består av två delar.

Den första är en uppsättning rutiner som hanterar storleksändring, marshaling och så vidare, som motsvarar typiska datatypobjekt som en struktur eller en matris. Dessa rutiner är finjusterade för prestanda. De försöker till exempel vanligtvis blockera kopiering av data där det är möjligt. Den här delen kallas ofta för NDR-kärnmotorn.

Den andra delen består av en tolk och dess relaterade delar. Tolken använder rutiner från NDR-kärnmotorn, som från ett internt bibliotek, för att köra ett fjärranrop med alla sina argument konverterade och omarshalerade, efter behov.

NDR-kärnmotorn används på liknande sätt, oavsett om den används från infogade stubs eller från tolken. Alla kärnmotorrutiner beror på tillståndet som skickas in av en stub-meddelandestruktur. Strukturen konfigureras på lämpligt sätt av den infogade stuben eller av tolken. Under årens lopp hade kärnmotorn använts i ett annat sammanhang; för närvarande är tolken faktiskt en uppsättning med flera distinkta tolkslingor. Dessa är relaterade till de gamla och nya tolkarna (–Oi kontra –Oif) samt för loopar relaterade till dataserialisering (pickling), stöd för RPC-asynkron synkronisering och stöd för DCOM-asynkrona (RPC och DCOM har olika asynkrona programmeringsmodeller).

Förutom att lägga till nya funktioner är en viktig aspekt av NDR-motorns utveckling en allmän förändring i tillvägagångssättet för tolkar. NDR version1.1 började som en del av en ny MIDL 2.0-metod för marskalkning, där inline stubs föredrogs för prestandaöverväganden. Med den senaste versionen av NDR har –Oif blivit kompilatorns mest använda läge, nästan med undantag för infogade stubs.

RPC NDR Engine-formatsträngbeskrivningar beskrivs mer detaljerat i följande avsnitt: