与系统／底层（如C++）进行数据交换的时候，会有一个托管和非托管数据相互转换的过程，就是所谓的
“数据封送”

之前说到了如何从C函数声明通过简单的查找替换生成一份C#的静态引用声明(C#与非托管——初体验)，因为只是简单说明，所以全部采用的是基础类型匹配和自动封送。自动封送虽然能省去我们不少编码时间，但如果不理解自动封送背后的实际行为，那就如同看魔术师的黑盒子，知其然不知其所以然。而且，自动封送也不是永远有效的万能药，因此这里记录一下封送相关的理解。

非基础类型在C#与Native代码交互时需要进行封送处理，一般的封送处理方式有内存拷贝、固定内存地址，总结如下：

  1. 针对string，可以使用Marshal.StringToHGlobalAnsi、Marshal.StringToHGlobalAuto、Marshal.StringToHGlobalUni把string封送到非托管函数，之后需要调用Marshal.FreeHGlobal释放内存；或者使用Marshal.PtrToStringAnsi、Marshal.PtrToStringAuto、Marshal.PtrToStringUni从非托管函数里面取出string。

  2. 针对byte[](或基础类型的数组)，可以使用Marshal.Copy从byte[]拷贝封送到非托管函数或者从非托管函数拷贝封送到byte[]。此外从byte[]封送到非托管函数还可以采取固定内存直接传送byte[]的原始地址(省去了申请内存和拷贝的开销，速度更快)，方法是使用GCHandle并指定GCHandleType.Pinned类型。

  3. 针对委托，可以使用Marshal.GetFunctionPointerForDelegate从delegate封送到非托管函数，或者使用Marshal.GetDelegateForFunctionPointer从非托管函数里面取出。和byte[]一样，在封送到非托管函数时需要确保GC不要回收委托(需要保持引用但不需要Pinned)。

  4. 针对结构体，可以在C#中按一样的顺序和对应的数据类型声明一个同样的struct(只能使用基础类型和固定长度的数组)，并且标记StructLayout的LayoutKind.Sequential属性，然后使用Marshal.StructureToPtr和Marshal.PtrToStructure进行封送。

  5. C#的对象不能在Native中进行处理，只能保存以待之后再传回给C#调用，保存的方式为C#用GCHandle引用对象，然后把GCHandle转成IntPtr，传给Native作为指针保存。

当C#声明的extern函数返回类型和参数类型中有托管类型时(如string、byte[]、委托等)，就会进行自动封送处理，因此可以省写大部分的封送代码。不过有几种情况还是需要手动进行封送的，如：

  1. string的编码是utf8之类的非ansi非utf16编码，则必须手动进行封送同时转换编码。

  2. 委托转换成函数指针的操作比较耗时，如果有频繁的对同一委托进行封送调用，则预存转换后的结果能够很显著的提升性能。

    备注：转自http://www.cnblogs.com/libla/p/4560148.html

*********************************************

COM 封送处理技术允许在一个进程中使用由另一个进程中的对象公开的接口。在封送处理中，COM 提供（或由接口实现者提供）具有以下功能的代码：将方法的参数压缩成可以在进程之间移动的格式，并在另一端将这些参数解压缩，可以在进程之间移动还包括可以通过线路到达其他计算机上运行的进程。同样，COM 必须对该调用的返回执行这些相同步骤。

注意  当对象提供的接口在与该对象相同的进程中使用时，通常不必进行封送处理。但是，线程之间可能需要进行封送处理。

03087bf40ad162d90faa7f3f11dfa9ec8a13cd49

补充：stub：存根

RPC（Remote Procedure Call Protocol）——远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。

RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。

有多种 RPC模式和执行。最初由 Sun 公司提出。IETF ONC 宪章重新修订了 Sun 版本，使得 ONC RPC 协议成为 IETF 标准协议。现在使用最普遍的模式和执行是开放式软件基础的分布式计算环境（DCE）。

运行时,一次客户机对服务器的RPC调用,其内部操作大致有如下十步：

1.调用客户端句柄；执行传送参数

2.调用本地系统内核发送网络消息

3.消息传送到远程主机

4.服务器句柄得到消息并取得参数

5.执行远程过程

6.执行的过程将结果返回服务器句柄

7.服务器句柄返回结果，调用远程系统内核

8.消息传回本地主机

9.客户句柄由内核接收消息

10.客户接收句柄返回的数据

RPC OVER HTTP

Microsoft RPC-over-HTTP 部署(RPC over HTTP)允许RPC客户端安全和有效地通过Internet 连接到RPC 服务器程序并执行远程过程调用。这是在一个名称为RPC-over-HTTP 代理，或简称为RPC 代理的中间件的帮助下完成的。

RPC 代理运行在IIS计算机上。它接受来自Internet 的RPC 请求，在这些请求上执行认证，检验和访问检查，如果请求通过所有的测试，RPC 代理将请求转发给执行真正处理的RPC 服务器。通过RPC over HTTP，RPC客户端不和服务器直接通信，它们使用RPC 代理作为中间件。


协议结构

编辑

远程过程调用（RPC）信息协议由两个不同结构组成：调用信息和答复信息。信息流程如下所示：

RPC：远程过程调用流程

RPC 调用信息：每条远程过程调用信息包括以下无符号整数字段，以独立识别远程过程：

程序号（Program number）

程序版本号（Program version number）

过程号（Procedure number）

RPC 调用信息主体形式如下：

struct call_body {

unsigned int rpcvers;

unsigned int prog;

unsigned int vers;

unsigned int proc;

opaque_auth cred;

opaque_auth verf;

1 parameter

2 parameter . . . }；

RPC 答复信息：RPC 协议的答复信息的改变取决于网络服务器对调用信息是接收还是拒绝。答复信息请求包括区别以下情形的各种信息：

RPC 成功执行调用信息。.

RPC 的远程实现不是协议第二版，返回 RPC 支持的最低和最高版本号。

在远程系统中，远程程序不可用。

远程程序不支持被请求的版本号。返回远程程序所支持的最低和最高版本号。

请求的过程号不存在。通常是呼叫方协议或程序差错。

RPC答复信息形式如下：

enum reply_stat stat

{MSG_ACCEPTED = 0,

MSG_DENIED = 1 }；


备注：摘自http://baike.baidu.com/link?url=hP3ZfSZ_AHSHIob-95djsjAQd24_W9bpvdDyig3FW8Q7_jlID9mSx1atviaJuYjniYyDa2-fPKneY0QmKy-q140Er94tbsMWsSW0wHp3wjj31RbpcPbXSKw-5bMpxXsL6VdsIFkPVGadUzqczOt_-uy_L4PLiw9podCMxW1RFquvtRO40g-LUt7W2kO4vl7K