IPC Mechanisms in C# - Usage and Best Practices

Question

I have used IPC in win32 code a while ago. [Critical sections, events & semaphores]

How is the scene in .NET enviroment? Are there any tutorial explaining all av

Answer 1

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

Answer 2

I tend to use named pipes or Unix sockets (depending on whether I'm targetting MS.NET or Mono -- I have a class that abstracts it away) since it's easy to use, portable, and allows me to easily interoperate with unmanaged code. That said, if you're only dealing with managed code, go with WCF or remoting -- the latter if you need Mono support, since their WCF support simply isn't there yet.

Answer 3

There is also .NET Remoting, which I found quite cool, but I guess they are obsoleting it now that they have WCF.

Answer 4

I would recommend using Memory Mapped Files if you need to use on the machine domain not communication through network. See the following link.

http://techmikael.blogspot.com/2010/02/blazing-fast-ipc-in-net-4-wcf-vs.html

Answer 5

It sounds as though you're interested in synchronization techniques rather than communication. If so, you might like to start here, or perhaps this more concise overview.

Answer 6

Apart from the obvious (WCF), there is a ZeroMQ binding for C#/CLR which is pretty good:

http://www.zeromq.org/bindings:clr

Does message-oriented IPC, pub/sub and various other strategies with much less code and config than WCF.

It's also at least an order of magnitude faster than anything else and has less latency if you require low latency comms.

With respects to semaphores, locks, mutexes etc. If you share by communicating rather than communicate by sharing, you'll have a whole load less hassle than the traditional paradigm.