探讨一个新的两个进程间的通信和编程模型 (Windows)

本文探讨一个新的Windows上的两个UI进程间的通信和编程模型。

开门见山，下面是这个通信模型的梗概图：

这个模型的设计目标描述如下：

（1）发送数据接口：RpcSend, RpcPost

• RpcSend是同步接口，发送数据到目标fsm, 同时接收返回数据，其原型为

int RpcSend(const char* strFsmName, unsigned int uEvent, PBYTE pMsgData, int nMsgDataLen, PBYTE& pResultData, int& nResultDataLen);

参数说明：

strFsmName: 目标状态机名称

uEvent: 事件id

pMsgData: 待发送数据

nMsgDataLen: 数据长度

pResultData:应答数据

nResultDataLen: 应带数据长度

返回值是发送的数据长度。

• RpcPost 定义为发送数据到目标fsm，与RpcSend相比，它不能接收到对方的返回数据。

int RpcPost(const char* strFsmName, unsigned int uEvent, PBYTE pMsgData, int nMsgDataLen);

参数说明：

strFsmName: 目标状态机名称

uEvent: 事件id

pMsgData: 待发送数据

nMsgDataLen: 数据长度

返回值是发送的数据长度。

（2）接收数据在状态机的事件函数中处理，函数原型为：onEventProc。

（3）应用的逻辑在状态机模型FSM中完成实现。

（4）两端的Container的功能为通信适配和容器的工作。它可以独立运行在一个新线程中，也可附着在现有应用的UI线程中。hMainWnd是这个Container的主窗口，如果该Container附着在一个应用的窗口上，hMainWnd就是这个窗口句柄.

（5）Pipe完成IPC的进程间通信，监听接收到数据，并发送给窗口消息过程。

实际上，在应用结构中，需要多个状态机的组合才能实现一个完整的应用需求，这组状态机需要一个管理者(Fsm Manager)来作为他们的容器或通信的纽带。

Fsm Manager需要从Fsm继承而来，所以它实际上也是一个状态机，这样做的好处能够通过状态机的组合创造出极大的灵活性和方便，同时RpcPost和RpcSend同样适用于Fsm Manager，因为它就是状态机。

状态机是怎么启动的？ 我们需要一个Manifest.xml，这是一个配置文件，我们在其中配置需要启动的状态的名字和参数。Container在初始化的过程中，会把状态机启动。一般我们只需要设置一个需要启动的Fsm Manager，而其它的状态机，通过这个Fsm Manager完成启动。