Compartilhar via

Cadeias de caracteres de formato RPC NDR

  • Artigo

Mecanismo NDR: Interpretador de 32 bits

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

Este documento descreve a tecnologia MIDL (Linguagem de Definição de Interface da Microsoft) atual da perspectiva do mecanismo e o mecanismo NDR atual.

Visão geral

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

O objetivo original do design era fornecer uma ferramenta para marshaling efetivo de 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 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 do RPC e algumas interfaces DCOM usadas pelo mecanismo são externas).

Duas abordagens típicas para marshaling sempre foram embutidas e baseadas em dados (interpretadas). O MIDL dá suporte a ambos por meio de suas opções –Os e –Oi* em seus stubs gerados por C. Além disso, MIDL pode gerar as bibliotecas TLB usadas pelo pacote de oleautomation. Portanto, uma perspectiva dos internos do mecanismo é que ele consiste em duas partes.

O primeiro é um conjunto de rotinas que lidam com dimensionamento, marshaling e assim por diante, correspondentes a objetos típicos do tipo de dados, como uma estrutura ou uma matriz. Essas rotinas são ajustadas para desempenho; por exemplo, eles normalmente tentam bloquear dados de cópia sempre que possível. Essa parte geralmente é conhecida como o mecanismo NDR principal.

A segunda parte consiste em um interpretador e suas peças relacionadas. O interpretador usa rotinas do mecanismo NDR principal, como se fosse de uma biblioteca interna, a fim de executar uma chamada remota com todos os seus argumentos em marshaled e não-marsalizados, conforme apropriado.

O mecanismo NDR principal é usado de maneira semelhante, seja usado de stubs embutidos ou do interpretador. Todas as rotinas principais do mecanismo dependem do estado passado por uma estrutura de mensagens stub. A estrutura é configurada adequadamente pelo stub embutido ou pelo interpretador. Ao longo dos anos, o mecanismo principal foi usado em um contexto diferente; atualmente, o interpretador é, na verdade, um conjunto de vários loops de interpretador distintos. Elas estão relacionadas aos interpretados antigos e novos (–Oi versus –Oif), bem como a loops relacionados à serialização de dados (pickling), suporte assíncrono RPC e suporte assíncrono DCOM (RPC e DCOM têm modelos de programação assíncronos diferentes).

Além da adição de novos recursos, um aspecto importante da evolução do mecanismo NDR é uma mudança geral na abordagem para interpretadores. O NDR versão 1.1 começou como parte de uma nova abordagem midl 2.0 para marshaling, com os stubs embutidos sendo preferenciais para considerações de desempenho. Com a versão mais recente do NDR, –Oif tornou-se o modo mais amplamente usado do compilador, quase à exclusão de stubs embutidos.

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