How might i do these IPC techinques?

Question

I remember back in the day while using C and win32 i had a number of IPC techniques. So far i haven't ran into any of them in .NET or seen them outside of C so i thought i ask how might i do these inter-process communication techniques?

1. Shared/Global memory. Simply allocate ram that can be change by another process without any signal.

2. Window message. I remember using SendMessage and using WM_USER + N and told another app when i touched shared memory, ask it to change files or settings and sometimes told other app that i typed in some keystrokes to act as a macro because i sometimes feel lazy.

3. Dynamic Data Exchange. I tried but never could get this to work. From what i remember (warning this could be completely wrong) you register yourself to a global message or event and another app (usually yours) would send message and the two or so apps can communicated to each other, post message and you can have integration between two apps this way. I'm very interested to know what replaced this.

There are also named pipes which i know are still used and seen. And i remember people recommending sockets for IPC but i never liked to do that and i know that still exist and can be used if i need.

What else did i miss and what replaced this techniques? I know there are global mutex which is cool. I'm still looking for a modern way to send messages between two apps (point 2). I always wondered if there was some kind of FIFO queue that wasn't in a pipe. Like a windows message except i can push data (like 1k) instead of sending msgs and allocating global memory each time.

-edit- bump. this thread is still relevant to me at the moment.

Answer 1

In .NET you can use:

1. Named pipes
2. Memory mapped files
3. WCF

Shared/global memory are not easily achievable in .NET, you'd have to do interop to Win32 calls and pin managed memory to avoid it being moved by the GC.

Window messages obviously only work when you have windows, either visible or hidden. This technique should not be used by the .NET applications.

DDE - don't use.

Answer 2

Even though you are aware of sockets, but don't really like it, I do recall reading somewhere that on Windows a socket through localhost does have a shortcut path, and may be optimized to the level of a single memory copy. However, for the life of me I can't find where I read that so maybe someone else can link to the source.

The downside of this is I do believe you have to have an active network code to establish the connection, but it won't actually use the entire TCP/IP stack once established.

Also a note for the post by Andrei, I tested Memory Mapped Files (which native is only added in .net 4.0 if memory serves) and I was having some trouble with it. It will likely work, but there isn't much documentation, and you still sort of need to write out how the two application synchronize read's and writes, whether it be a semaphore for notification, or a tight loop looking at a location in the file.

Personally, on the APP I'm developing i'm using sockets through localhost, and so far have not encountered any massive performance or security issues. But it will come back to what are you're design goals and security requirements.