如何在进程间通信中获取其他端点的进程ID答案

【问题标题】：How to get process id of other endpoint in inter-process communication如何在进程间通信中获取其他端点的进程ID
【发布时间】：2014-02-10 10:42:33
【问题描述】：

使用 Win32 C++ API，我想知道哪个IPC method 允许多进程通信中的任何端点，以获取与之通信的进程的 PID 或 HANDLE。换句话说，如果进程 A 从进程 B 获得消息：

通信的目的是简单的远程过程调用。但是，我不希望远程系统/主机上的进程调用本地主机上运行的进程提供的过程。

我当然找到了RPC documentation on MSDN。但是，我想知道是否有比 RPC 更好的方法来实现我想要的。或者，如果您认为 RPC 是可行的方法，您能告诉我为什么吗？如果您知道除 MSDN 之外还有其他值得学习的好的参考资料吗？

【问题讨论】：

它有什么帮助？如果端点在另一台计算机上，它根本不会帮助你..而且“句柄”仅在同一进程中有效......通常通过将 RPC 绑定到“127.0.0.1”来解决这个问题......
我想得到另一个进程的句柄，就像你通过OpenProcess API的返回值得到句柄一样。这个问题是从某种意义上说的，可能有另一个函数返回 HANDLE 而不需要 PID，例如仅基于 IPC 消息。
正如我所说：句柄是特定于进程的！你不能用来自不同进程的句柄做任何事情......
在我用进程 A 和 B 给出的示例中。我不想要 B 内部的 B 的 HANDLE（指针）。我想在 A 内部获取 B 的 HANDLE，就像我一样如果我有 B 的 PID 并在 A 内部进行以下调用，将从 A 内部获取它：HANDLE handleOfB = OpenProcess(PROCESS_VM_READ, FALSE, pibOfB).
也许你不想理解它... OpenProcess 没有得到一个句柄 from 进程 B；它在进程 A（仅在进程 A 中有效）中为 pidB 获取一个句柄！如果你确定你在同一台电脑上，为什么不通过PID？？？

【解决方案1】：

如果您只想将 RPC 限制在本地计算机上，那么您应该将您的 RPC 系统绑定到“127.0.0.1”。那么只有本地进程才能与这个端口通信！

【讨论】：

【解决方案2】：

如果您使用Named Pipes 实现自己的 RPC，您将能够使用服务器进程中的GetNamedPipeClientProcessId 来获取本地端点客户端进程的 PID。

编辑：如果您真的追求安全，第一条规则是“您不得编写自己的系统”。

【讨论】：

这可能是关于这个问题的答案，但是：如果存在安全问题，这应该通过安全限制而不是 PID 来解决……谁应该知道哪些 PID 是有效的应用程序？ ??如果有特殊的特权或用户，那毫无疑问...
@JochenKalmbach 我知道。只是回答问题。不过会编辑。
还有一个对应的GetNamedPipeServerProcessId ()函数。

【解决方案3】：

我不熟悉所有的方法，

对于 WM_COPYDATA 你有方法：

wParam
    A handle to the window passing the data.

所以你可以在上面使用GetWindowThreadProcessID，但是 WM_COPYDATA 是在单台电脑上使用的

要识别谁打开了给定的句柄，您必须使用一些低级技巧，例如 SysInternals 的 handle.exe 程序 (http://forum.sysinternals.com/topic18892.html)。

【讨论】：

我没有明确提及，但是我使用的进程没有windows。因此，我想我不能在我的情况下使用GetWindowThreadProcessID。就您对句柄枚举的其他建议而言，我担心进程可能会在“发送”消息之后立即将句柄释放到文件等共享资源。此外，我想知道发送消息的进程的 ID，在共享资源的情况下，您可能有超过 2 个进程拥有同一资源的句柄，对吧？
如果您在两个进程之间进行通信，那么在此通信中包含第三个进程将是错误的。这看起来就像您允许使用同名文件从任何其他应用程序与您的应用程序进行通信。如果您将共享内存用于 IPC，那么您必须再次为其命名，以便您的应用和第二个应用知道。
.... IPC 通常以一些握手开始，这是进程交换有关如何进行通信的信息的时刻，这可能包括文件/句柄的名称。因此，我真的没有理由检查远程应用程序的 PID，因为它可以使用您的协议轻松提供。
另外，那些用于查找句柄所有者的方法（来自 sysinternals）——我宁愿考虑用于调试目的。
当然，您可以有一个协议来指示 PID，但这样做的问题是恶意进程可能会指示其他一些不同于它自己的 PID。这就是为什么我在问题中明确提到协议不得涉及发送 PID。