Which Interprocess Communication methods work on a Terminal Server?

Question

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?

Answer 1

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.

Answer 2

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.