DLL 注入/IPC 问题答案

【问题标题】：DLL Injection/IPC questionDLL 注入/IPC 问题
【发布时间】：2009-10-21 14:19:18
【问题描述】：

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

我的问题是：

我已经完成了 DLL 注入，但我对 Windows 编程并不十分熟悉。使用子代将生成的数百万个文件 io 报告回调到父构建过程的最佳/最快方法是什么？我曾考虑让它们写入非阻塞套接字，但一直想知道管道/共享内存或 COM 是否会更好？

【问题讨论】：

您是否考虑过使用诸如 incredibuild 之类的商业工具？考虑到您描述的解决方案的复杂性，它肯定会更便宜、更快

标签： c++ winapi dll shared-libraries

【解决方案1】：

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

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

【讨论】：

我怀疑你就在这里，从每个子进程中，我真的只想传回所有读/写文件的列表，而不是它们本身的实际事件。也许通过 Windows 消息发送的列表将是解决方案。
也许——再一次，对列表进行排序和散列（并且只发送散列）会更多地减少数据......

【解决方案2】：

如果您停留在 Windows 世界中（您的机器都不是 linux 或其他），命名管道是一个不错的选择，因为它速度很快并且可以跨机器边界访问。我认为共享内存已经出局了，因为它不能跨越机器边界。分布式 com 允许在 IDL 中制定合同，但我认为通过管道的 XML 消息也可以。 xml 消息具有完全独立于通道工作的好处。如果您以后需要 linux，您可以切换到 tcp/ip 传输并发送您的 xml 消息。

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

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

如果你在同一台机器上，只需要发送一些状态信息，你可以通过RegisterWindowMessage()注册一个windows消息，通过SendMessage()发送消息

【讨论】：

编程 RPC 并不是很困难——它只是可怕地记录不足。上面只有几本第三方书籍，而且都绝版了。 MSDN 只有几篇文章几乎没有顺便提及。
嗯，虽然我的系统是分布式的，但它不是。在每台机器上运行的从站将负责整理所有文件事件，将通过网络发送回由“作业”读取/写入的文件列表。 Windows 消息传递可能是赢家。我不喜欢 XML，因为对这么多消息的所有解析可能会变得混乱。换个角度来看，一个大型项目的一个链接可以生成 50 万条输入/输出消息。

【解决方案3】：

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

【讨论】：

嗯，我只想非常简短地保留这些消息，我认为数据库解决方案可能有点矫枉过正。

【解决方案4】：

对于验证构建中使用的文件的任务来说，这听起来有点过头了。怎么样，只扫描构建文件？还是捕获构建工具的输出？

【讨论】：

嗯，不是真的，显然我已经扫描了构建文件，因为我是构建工具。我的工具确实提供了扫描编译器等输出的功能，但并非所有工具都提供如此方便的输出，我想要一个通用的解决方案。