Partilhar via

Strings de formato NDR RPC

Mecanismo NDR: Interpretador de 32 bits

Este documento descreve os descritores de cadeia de caracteres de formato, às vezes referidos como MOPs, para o mecanismo de notificação de falha na entrega de 32 bits. Esta seção descreve as mudanças associadas à evolução do interpretador –Oi para a camada interpretador –Oif, bem como adições relacionadas a tubos e suporte assíncrono.

Este documento descreve a tecnologia atual Microsoft Interface Definition Language (MIDL) da perspetiva do mecanismo e o mecanismo de notificação de falha na entrega atual.

Visão geral

O mecanismo NDR é o mecanismo de empacotamento dos componentes RPC (Remote Procedure Call) e DCOM. Ele lida com todos os problemas relacionados a stub de uma chamada remota. Como um processo, o marshaling NDR é conduzido pelo código C de stubs gerados por MIDL, um gerador do tipo JIT MIDL, ou por stubs gerados por outras ferramentas ou escritos manualmente. Por sua vez, o mecanismo NDR aciona o tempo de execução subjacente (DCOM ou RPC) que se comunica com transportes específicos.

O objetivo original do projeto era fornecer uma ferramenta para o marshaling eficaz para dados arbitrários, com base nas informações fornecidas pelo compilador MIDL. As cadeias de caracteres de formato descritas neste documento — e de fato todas as informações geradas pelo compilador para consumo do mecanismo de NDR — sempre foram consideradas uma interface interna entre o compilador e o mecanismo. Da mesma forma, as interfaces disponíveis para o mecanismo para lidar com problemas de tempo de execução também são principalmente internas (algumas exceções existem no lado do tempo de execução RPC e algumas interfaces DCOM usadas pelo mecanismo são externas).

Duas abordagens típicas de marshaling sempre foram a tecnologia em linha e orientada por dados (interpretada). O MIDL suporta tanto através de seus switches –Os quanto –Oi* em seus stubs gerados por C. Além disso, o MIDL pode gerar as bibliotecas TLB usadas pelo pacote oleautomation. Assim, uma perspetiva dos componentes internos do motor é que ele consiste em duas partes.

O primeiro é um conjunto de rotinas que lidam com dimensionamento, empacotamento e assim por diante, correspondendo a objetos típicos de tipo de dados, como uma estrutura ou uma matriz. Estas rotinas são ajustadas para o desempenho; Por exemplo, eles normalmente tentam bloquear a cópia de dados sempre que possível. Esta parte é muitas vezes referida como o motor NDR principal.

A segunda parte é composta por um intérprete e suas peças relacionadas. O intérprete usa rotinas do mecanismo de NDR principal, como se fosse de uma biblioteca interna, para executar uma chamada remota com todos os seus argumentos empacotados e desempacotados, conforme apropriado.

O mecanismo NDR principal é usado de maneira semelhante, seja usado a partir de stubs em linha ou do intérprete. Todas as rotinas principais do motor dependem do estado transmitido por uma estrutura de mensagem de stub. A estrutura é configurada adequadamente pelo esboço em linha ou pelo intérprete. Ao longo dos anos, o motor central foi usado em um contexto diferente; Atualmente, o intérprete é, na verdade, um conjunto de vários loops distintos de intérpretes. Estes estão relacionados com os antigos e novos interpretadores (–Oi versus –Oif), bem como com loops relacionados com serialização de dados (pickling), suporte assíncrono RPC e suporte assíncrono DCOM (RPC e DCOM têm diferentes modelos de programação assíncrona).

Além da adição de novos recursos, um aspeto importante da evolução do motor NDR é uma mudança geral na abordagem aos intérpretes. A NDR versão 1.1 começou como parte de uma nova abordagem MIDL 2.0 para marshaling, com os stubs em linha sendo preferidos por considerações de desempenho. Com a versão mais recente do NDR, –Oif tornou-se o modo mais utilizado do compilador, quase excluindo os stubs em linha.

Os descritores de cadeia de caracteres no formato do mecanismo NDR RPC são descritos com mais detalhes nos seguintes tópicos:

 

 

  • Last updated on