哪些进程间通信方法适用于终端服务器？
在终端服务器会话中，某些标准 IPC 技术可能无法像在单用户环境中那样工作，因为所需的资源未虚拟化。
例如，TCP/IP 端口不是虚拟化的，因此不同会话中的应用程序尝试侦听同一端口将导致端口冲突。
哪种 IPC 技术适用于在同一用户会话中运行的应用程序需要交互的终端服务器环境？
- 消息（WM_COPYDATA）？
- 命名管道？
- DDDE？
- 内存映射文件？
In a terminal server session, some standard IPC technologies might not work like in a single user environment, because the required resources are not virtualized.
For example, TCP/IP ports are not virtualized, so applications in different sessions which try to listen on the same port will cause a port conflict.
Which IPC technology will work in a terminal server environment where applications running in the same user session need to interact?
- Messages (WM_COPYDATA)?
- Named Pipes?
- DDE?
- Memory Mapped Files?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
消息将正常工作。 DDE 也会，因为它基于消息。 命名管道不会，因为它们是按-系统而不是每个会话。 您还可以考虑 COM 或 OLE。
Messages will work fine. DDE will too, since it is based on messages. Named pipes will not, since they are per-system and not per-session. You might also consider COM or OLE.
所有 IPC 都可以在 TS 环境中使用 - 您只需巧妙地命名对象即可实现所需的最终结果。 使用套接字比较棘手，但可以做到。 我在下面列出了一些方法。
对于可以命名的 IPC 对象（管道、事件、互斥体、内存映射文件等），将会话 ID 合并到对象名称中将实现所需的虚拟化。
要进一步锁定 IPC 对象，请使用对象的安全属性来阻止任何其他用户访问 IPC 对象的可能性。 这可能是由于终端服务器上的错误或其他用户的恶意行为而意外发生的。
同样，在 IPC 对象的名称中使用登录用户的身份验证 ID。 在 C++ 中，请参阅 MSDN 上的 GetTokenInformation 使用 TokenStatistics TokenInformation类。 我确信有一个等效的 .NET 方法。 再次保护 IPC 对象。
如果必须在 TS 上使用套接字（我个人会选择另一种方法在 TS 上的应用程序之间进行通信），则使用端口号。 选择一个基本端口号并添加会话号以获取用于会话的端口。 为了确保正确的应用程序正在通信，请在传输数据之前使用身份验证方法和/或握手。 理论上，会话编号最大为 65535，因此当您使用基本端口号（例如 2000）并且会话您的应用程序在会话 65500 中运行时，您可能会遇到困难。
如果您确实想使用套接字，那么代理服务可能会有所帮助。
All IPCs can be used in a TS environment - you just have to be clever in the naming of the objects to achieve the required end result. Using sockets is trickier but it can be done. I've listed a few methods below.
For IPC objects that can be named (Pipe, Event, Mutex, Memory Mapped File etc.) incorporating the session ID into the name of the object will achieve the virtualisation required.
To further lock down the IPC object use the object's security attributes to stop the possibility of any other user from accessing the IPC object. This could occur accidentally as a result of a bug or maliciously from another user on the terminal server.
Similarly use the logged on user's Authentication ID in the IPC object's name. In C++ see MSDN on GetTokenInformation use TokenStatistics for the TokenInformationClass. I'm sure there is an equivalent .NET method. Again secure the IPC object.
If you must use sockets on a TS (I personally would choose another method to communicate between applications on a TS) then use the port numbers. Pick a base port number and add the session number to get the port used for a session. To make sure that the correct applications are communicating use an authentication method and/or handshaking before transfering data. Theoretically sessions can be numbered up to 65535 so you may come unstuck when you use a base port number of say 2000 and session your application is run in session 65500.
If you really wanted to use sockets then maybe a broker service would help.