Ipc Mechanisms in C# - Usage and Best Practices

IPC Mechanisms in C# - Usage and Best Practices

Most recent Microsoft's stuff in IPC is Windows Communication Foundation. Actually there is nothing new in the lower level (tcp, upd, named pipes etc) But WCF simplifies IPC development greatly.

Useful resource:

• Interprocess Communication with WCF on Dr. Dobb's portal
• WCF Communication Options in the .NET Framework 3.5

and of course MSDN on WCF

C# IPC Recommendations and comparisons

.NET Remoting is just the feature of .NET 2.0 - a set of techniques and libraries that simplifies the usage of common inter-process commutication ways (Named pipes, network sockets, HTTP post/get queries)

In .NET 3.0 it is WCF.

So the lyrics, as for you: use TCP sockets between machines on the secured LAN, use HTTP (Soap, WebMethods, or just HTTP) on the Internet and IPC on one machine to communicate processes (client and server)
The platform you choose (.NET 2.0 Remoting or .NET 3.0 WCF) - it's up to you.

P.S.: I use .NET 2.0 Remoting framework still.

internal communication between a .net and C++ application

There are many mechanisms you can use to do this.

This article enumerates the common ways to accomplish interprocess communication on the windows platform. Most if not all are possible form both C# and C++ (though I would hate to see you use DDE from C#, though it has apparently been done).

Service - App Communication. Best method?

See this SO question:

C# IPC Best Practises

You almost certainly want to use WCF. This replaces other .Net technologies such as remoting. Also, if you use WCF:

• Other clients could also subscribe to that status information in the future.
• The service listening to status updates could be run on another physical box if you needed to scale out.

C# Eventing across IPC

Back in the bad old days of Windows API programming, we'd sometimes use RegisterWindowMessage to register a unique message ID that (presumably) only our window knew how to handle. We could then trigger that window from another application by calling PostMessage with a window handle of HWND_BROADCAST, and the msg parameter being that unique message value. That works great if everything you want to share between the processes can fit into two DWORD values (wparam and lparam). Sharing more data can be done if you allocate global memory and pass a reference as one of the parameters.

That should still be possible with .NET. Certainly there's no trouble calling PostMessage. As for handling the message in the UI code, you have to override the Form's WndProc. See How do I send/receive windows messages between VB6 and c#? for an example.

You could do something with named events, although that would only notify the UI that some change had occurred. It wouldn't actually tell you what happened. I suppose, if there's only a small set of possible events, you could have multiple events, but that gets complicated pretty quickly.

You could go the named event route and use shared memory (memory mapped file) to share the state.

Or, you could set up sockets, named pipes, TcpListener/TcpClient, or even a UdpClient. All should work, with varying degrees of complexity and/or reliability.

---

Related Topics