C++ DLL注入/IPC问题

我正在开发一个构建工具，它可以启动数千个进程（编译、链接等）。它还将可执行文件分发到远程机器，以便可以跨100台从机运行构建。我正在实现DLL注入以监视构建过程的子进程，这样我就可以看到它们打开/关闭了我期望它们打开/关闭的资源。这样我就可以判断我的用户是否没有正确指定依赖项信息

我的问题是:

---

我已经让DLL注入工作，但我不太熟悉windows编程。使用子级将生成的数百万文件io报告回调父级生成过程的最佳/最快方法是什么？我曾经考虑过让他们写一个非阻塞套接字，但是我一直在想也许管道/共享内存或者COM会更好吗？

如果你呆在windows世界（没有一台机器是linux或其他什么），命名管道是一个好选择，因为它速度快，可以跨机器边界访问。我认为共享内存已经过时了，因为它无法跨越机器边界。分布式com允许在IDL中制定契约，但我认为通过管道的XML消息也可以。xml消息具有完全独立于通道工作的优点。如果以后需要linux，您可以切换到tcp/ip传输并发送xml消息

一些附加技术具有局限性：

另一个被遗忘但热门的候选对象是RPC（远程过程调用）。许多windows服务都依赖于此。但我认为很难编程RPC

---

如果您在同一台计算机上，只需要发送一些状态信息，您可以通过RegisterWindowMessage（）注册windows消息并发送消息vie SendMessage（）

除了thomas的所有建议之外，您还可以使用一个公共数据库来存储结果。如果速度太慢，请使用一个更现代（和快速）的键/值数据库（如tokyo cabinet/memcachedb/etc）

首先，因为您显然是在处理机器之间的通信，而不仅仅是在一台机器内，所以我会立即排除共享内存

---

我会认真考虑尽量减少数据量，而不是担心发送数据的速度。我不会发送数以百万计的文件I/O报告，而是将几千字节的数据（或按该顺序排列的数据）批处理在一起，然后发送该数据包的散列。通过仔细选择数据包大小，您应该能够将数据传输减少到只需使用您认为最方便的任何方法即可，而不是试图选择最快的方法。

对于验证生成中使用的文件的任务来说，这听起来有点过分了。只是扫描构建文件怎么样？或者从构建工具中获取输出？

对RPC进行编程并不十分困难，只是文档太少。关于它的第三方书籍很少，而且都已经绝版了。MSDN只有几篇文章很少提及它。嗯，虽然我的系统是分布式的，但它的这一部分不是。每台机器上运行的从机将负责整理所有文件事件，并通过网络将“作业”读取/写入的文件列表发回。Windows messaging可能是赢家。我不喜欢XML，因为这么多消息的解析可能会变得混乱。从长远来看，一个大型项目的一个链接可以生成500k的输入/输出消息。嗯，我只想简单地保留这些消息，我认为db解决方案可能有点过头了。我怀疑你就在这里，从每个子进程中，我只想传回所有读/写文件的列表，而不是它们自己的实际事件。也许通过windows消息发送的列表就是解决方案。也许——再说一次，对列表进行排序和散列（只发送散列）会大大减少数据量……您是否考虑过使用商业工具，如IncredBuild？考虑到您所描述的解决方案的复杂性，它肯定会更便宜、更快。嗯，不是真的，显然我已经扫描了构建文件，因为我是构建工具。我的工具确实提供了扫描编译器等输出的功能，但并非所有工具都提供如此方便的输出，我需要一个通用的解决方案。