在终端服务器会话中，某些标准 IPC 技术可能无法像在单用户环境中那样工作，因为所需的资源未虚拟化。
例如，TCP/IP 端口没有虚拟化，因此不同会话中的应用程序尝试侦听同一端口会导致端口冲突。
哪种 IPC 技术适用于在同一用户会话中运行的应用程序需要交互的终端服务器环境？
【问题讨论】：
标签： sockets ipc named-pipes terminal-services dde
消息可以正常工作。 DDE 也会，因为它是基于消息的。 Named pipes 不会，因为它们是每个系统而不是每个会话。您也可以考虑 COM 或 OLE。
【讨论】：
所有 IPC 都可以在 TS 环境中使用 - 您只需巧妙地命名对象即可获得所需的最终结果。使用套接字比较棘手，但可以做到。我在下面列出了一些方法。
对于可以命名的 IPC 对象（管道、事件、互斥体、内存映射文件等），将会话 ID 合并到对象名称中将实现所需的虚拟化。 要进一步锁定 IPC 对象，请使用对象的安全属性来阻止任何其他用户访问 IPC 对象的可能性。这可能是由于终端服务器上的错误或来自其他用户的恶意而意外发生的。
类似地在 IPC 对象的名称中使用登录用户的身份验证 ID。在 C++ 中，请参阅 GetTokenInformation 上的 MSDN，将 TokenStatistics 用于 TokenInformationClass。我确信有一个等效的.NET 方法。再次保护 IPC 对象。
如果您必须在 TS 上使用套接字（我个人会选择另一种方法在 TS 上的应用程序之间进行通信），请使用端口号。选择一个基本端口号并添加会话号以获取用于会话的端口。为了确保正确的应用程序正在通信，请在传输数据之前使用身份验证方法和/或握手。理论上会话最多可以编号为 65535，因此当您使用 2000 的基本端口号并且会话您的应用程序在会话 65500 中运行时，您可能会遇到问题。 如果您真的想使用套接字，那么代理服务可能会有所帮助。
【讨论】：