RPC NDR 格式字符串

NDR 引擎:32 位解释器

本文档介绍 32 位 NDR 引擎的格式字符串描述符(有时称为 MOP)。 本部分介绍与从 –Oi 解释器到 –Oif 解释器层以及与管道和异步支持相关的新增内容相关的变化。

本文档从引擎的角度来看,介绍当前的Microsoft接口定义语言(MIDL)技术,以及当前的 NDR 引擎。

概述

NDR 引擎是远程过程调用 (RPC) 和 DCOM 组件的封送引擎。 它处理远程调用的所有存根相关问题。 在此过程中,NDR 封送处理由 MIDL 生成的存根、MIDL JIT 类型生成器或由其他工具或手动编写的存根中的 C 代码驱动。 反过来,NDR 引擎会驱动与特定传输通信的基础运行时(DCOM 或 RPC)。

设计的原始目标是根据 MIDL 编译器提供的信息,提供一个工具,用于有效封送任意数据。 本文档中描述的格式字符串(事实上,编译器生成用于 NDR 引擎消耗的所有信息)始终被视为编译器和引擎之间的内部接口。 同样,可用于处理运行时问题的引擎的接口也大多是内部的(RPC 运行时端存在一些异常,引擎使用的一些 DCOM 接口是外部的)。

封送处理两种典型的方法一直是内联和数据驱动的(解释)技术。 MIDL 通过其 –Os–Oi* 开关在其 C 生成的存根中支持这两种开关。 此外,MIDL 还可以生成 oleautomation 包使用的 TLB 库。 因此,引擎内部的一个视角是它由两个部分组成。

第一个例程是一组处理大小调整、封送等的例程,这些例程对应于结构或数组等典型数据类型对象。 这些例程针对性能进行了微调;例如,它们通常会尽可能尝试阻止复制数据。 此部分通常称为核心 NDR 引擎。

第二部分由解释器及其相关部分组成。 解释器使用核心 NDR 引擎中的例程,就像来自内部库一样,以便执行远程调用,并根据需要封送和取消封送所有参数。

核心 NDR 引擎以类似的方式使用,无论是从内联存根还是从解释器使用。 所有核心引擎例程都取决于存根消息结构传入的状态。 结构由内联存根或解释器适当设置。 多年来,核心引擎一直在不同的环境中使用:目前,解释器实际上是一组不同的解释器循环。 这些与旧和新版本(–Oi–Oif) 解释器以及与数据序列化(选取)、RPC 异步支持和 DCOM 异步支持相关的循环(RPC 和 DCOM 具有不同的异步编程模型)。

除了新增新功能之外,NDR 引擎演变的一个重要方面是解释器方法的一般转变。 NDR 版本 1.1 开始是新的 MIDL 2.0 封送方法的一部分,内联存根是性能注意事项的首选。 随着 NDR 的最新版本,–Oif 已成为编译器最常用的模式,几乎可以排除内联存根。

RPC NDR 引擎格式字符串描述符在以下主题中进行了更详细的描述: