下面试图了解哪些技术适合特定的（如概述的）分布式/ RPC问题。 如果有什么不清楚的地方，我很乐意增加更多细节，但请在评论中请求这些内容，而不是在“回答”中。 谢谢。

首先我将描述目前的情况，然后跟随我们想要达到的目标和实际的问题。 尽pipe这是一个相当长的post来获得一些背景，但这个问题本身是相当短的（见最后）。

应用程序分割挑战

应用说明：

该应用程序允许用户configuration一些硬件设备（*），然后与这些设备进行通信，以控制和收集物理实验的测量通道。

（*）硬件设备包括温度传感器，压力传感器，电机等。通信范围从串口通信，TCP / UDP通信到与第三方插件卡的驱动程序接口。

• 软实时在Windows操作系统 – 要考虑什么？
• 在Windows XP中以微秒时间精度开发一个实时数据采集系统是可能的吗？
• Windows操作系统中（软实时）时序要求的限制
• 如何为Linux用户设置CAP_SYS_NICEfunction？
• 发送信息到一个ngnix从PHP在同一台服务器没有http

控制包括发送命令到各种硬件设备，根据它们支持的协议进行configuration。 测量涉及从这些设备（的一些）获取数据。

当客户要求更高采样率的渠道越来越多时，我们很难保持整体运转，我们必须跟上将所有设备获得的数据+时间戳记写入磁盘，显示一部分数据并保持不变系统正确响应。

现在的情况：

[ DisplayAndControl.exe ] || /\ || DLL Interface || || || Window Messages (SendMessage, PostMessage) || || \/ || [ ChannelManager.dll ] 

• ChannelManager.dll（Windows上的本机C ++ DLL）

  • pipe理n个数据通道（物理测量variables）
  • 每个通道保存一个具有高精度时间戳的任意数量的采样
  • 允许对通道进行分组，并将其持续更新或历史值（“测量”）写入磁盘
  • 通道计算（算术，积分，平均值等）
  • 与（实时）硬件设备接口以获取通道的时间戳和值
  • 从硬件获取值+时间戳，并保存在内部环形缓冲区中以存储通道

• DisplayAndControl.exe（Windows上的Native C ++ MFC应用程序）

  • 控制ChannelManager.dll的function（configuration通道和硬件设备）
  • 实时显示所有通道的当前值/时间戳/更改
  • 图表中的（组）通道的graphics值
  • 打印通道值的图表和表格

目前情况总结：

现在的应用程序已经有些模块化，（主要）可执行程序执行显示+交互，并且（几个之一）DLL执行数据pipe理（将实时数据保存到磁盘，与设备通信等）。 ）

从性能POV，沟通顺便说一句。 显示模块和数据pipe理模块在此刻是最佳性能的。

新情况：

 [ DisplayAndControl.exe ] || /\ || ? RPC/Messaging || || || ? RPC/Messaging || || \/ || [ ChannelManager.exe (same PC or another) ] 

预想的新形势总结：

出于可用性，性能和安全的原因，我们希望将这个Windows应用程序分成两个独立的应用程序，以便性能（和安全性）敏感的ChannelManager模块可以作为单独的进程在单独的Windows PC上运行。

另外 ，由于我们已经打算拆分它，我们将允许多个DisplayAndControl.exe应用程序连接到一个ChannelManager.exe。

现在有一个问题是我们应该用什么技术来促进交stream顺便说一句。 现在两个（或，而不是1 : small_n ）的应用程序。

性能很重要，因为很多数据都是按照顺序传播的。 这两个应用程序和延迟应该保持在最低限度。 它“只”需要在Windows上工作，但它应该只能从本地C ++使用，这使得所有纯粹的基于.NET的技术都没有吸引力。 （注意：将DisplayAndControl.exe部分移植到.NET / WPF中，但ChannelManager.exe应该保持纯原生状态，因为我们不希望.NET进程在这个进程中运行）。

关于延迟 ：从小延迟可接受的意义上说，我们达到一定程度的软实时性是重要的，但是出于可用性和安全性的原因，大延时和尤其变化的延时是不可接受的。 因此，任何有助于获得某种（软）实时行为的协议都将是首选。

我们看过的RPC技术：

• WCF（或.NET远程处理） – 只有dotnet，因此不具有吸引力。 业绩数字也不是很好。

• （D）COM-COM非常适合Windows RPC通信，但是一旦必须进行PC间通信，COM-COM就会崩溃，因为在企业ITnetworking中使用安全设置是非常可怕的。

• CORBA – 过去我们在CORBA通讯方面有很好的经验。 沟通很容易， 没有太多的基础设施开销; 它从C ++运行良好; 写一个.NET包装是很简单的。 CORBA的问题是在C ++中正确使用有些复杂（人们会花费大量的时间来追逐内存泄漏，特别是缺乏经验的C ++开发人员）。 对于每个开发人员和每个新开发人员来说，这也将是一个学习曲线，因为没有人期望人们现在“认识”CORBA。 另外，它可能不如我们想要的那样好，据我所知还没有现成的实时支持。

• 节俭 – 在我们的情况下仍然看起来不完整。

• ICE（来自ZeroC） – 我更喜欢ICE，而不是CORBA，毕竟它承诺是一个“更好的CORBA”，我认为它确实提供了。 但是，他们的许可政策是非常不理想的，因为他们不销售开发许可证，而只是每次安装许可证。 （那么这是他们告诉我们上次我们问到2009年底。）他们的许可政策还表明，任何可能有兴趣与我们的模块接口的第三方首先必须与ZeroC谈判许可合同。

• 打开MPI – 消息传递接口似乎是针对有很多客户“严重”分布的情况。 似乎不适合我们的问题。

• 使用TCP / UDP编写我们自己的通信层 – 噢，我的。 我宁愿不 ：-）

• Google协议缓冲区 – 不是 RPC技术。

• 分布式共享内存 – 好吧。 这是由几个开发者投入的， 我也不确定是否有一个工作实施，如果它适合我​​们的问题。

所以问题再次 – 在这种情况下你会更喜欢什么“RPC”式的技术？为什么？