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 –Oi para a camada do 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 de 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 realizar 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 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 do RPC e algumas interfaces DCOM usadas pelo mecanismo são externas).

Duas abordagens típicas para marshaling sempre foram embutidas e controladas por 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. Assim, uma perspectiva dos internos do mecanismo é que ele consiste em duas partes.

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

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

O mecanismo NDR principal é usado de maneira semelhante, seja usado de stubs embutidos ou do interpretador. Todas as rotinas do mecanismo principal 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. Eles estão relacionados aos interpretadores 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 dos interpretadores. A 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 usado do compilador, quase à exclusão de stubs embutidos.

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