55

I have used IPC in Win32 code a while ago - critical sections, events, and semaphores.

How is the scene in the .NET environment? Are there any tutorial explaining all available options and when to use and why?

Pang
  • 8,605
  • 144
  • 77
  • 113
prakash
  • 55,001
  • 25
  • 87
  • 114
  • 1
    What do you need to do? If you need to synchronize access to some external resource, you can use a Mutex to implement cross-process synchronization. – Oliver Hanappi Feb 22 '10 at 15:41
  • 10
    +1. Thanks god. This is the first instance of questions with "Best Practices" flavor which is not marked as non-constructive/off-topic [that I have ever seen] !! – F.I.V Jul 26 '15 at 10:25

6 Answers6

31

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:

and of course MSDN on WCF

aku
  • 115,356
  • 31
  • 164
  • 200
12

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.

Deleted
  • 4,368
  • 1
  • 18
  • 17
  • 5
    **"share by communicating rather than communicate by sharing"** This should be recited every day by anyone who is doing concurrent programming. – Matt Klein Sep 02 '15 at 20:50
  • 5
    What does this mean? – Believe2014 Jun 11 '17 at 03:58
  • I take it to mean that instead of sharing resources and having each program try to claim it at will, you should have programs talk directly to each other with IPC. In the first scenario, your programs "communicate" by locking a shared resource. In the second, they communicate through some protocol to coordinate usage of the shared resource. – jmathew Jun 27 '17 at 17:55
  • http://zguide.zeromq.org/page:all#Unicast-Transports `The inter-process ipc transport is disconnected, like tcp. It has one limitation: it does not yet work on Windows.` Soooo actually not really IPC for windows right? Which still might be quite common when the C# tag was added. – Samuel May 28 '19 at 12:29
  • You _could_ use the local loopback adaptor with ZeroMQ. Performance will obviously depend on the adaptor implementation though. However, I don't like the semantics of hitting the network stack (albeit a virtual interface) when your intention is not communication over a network. Personally for IPC on the same machine I think using pipes is the best solution. The .NET Standard implementation is rock solid and totally portable. Mapped memory solutions may offer the best performance, but rolling your own is complex and synchronisation is error prone. _"share by communicating"_ :) – 0b101010 Jun 26 '20 at 15:49
10

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.

Serafina Brocious
  • 29,643
  • 11
  • 85
  • 111
  • 3
    While this may have been the case in Sep 2008 (when this comment was made), it's 2011 and WCF on Mono is quite mature now. See the [Mono WCF Development page](http://www.mono-project.com/WCF) and judge for yourself. – Brent Matzelle Jun 03 '11 at 14:54
7

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

Demir
  • 1,532
  • 27
  • 37
  • A list of .NET local Machine APIs: http://weblogs.asp.net/ricardoperes/local-machine-interprocess-communication-with-net – Ricardo Peres Oct 16 '15 at 13:22
3

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

ibz
  • 38,044
  • 21
  • 65
  • 83
  • Has Microsoft ever actually said that? – Mark Aug 18 '09 at 14:37
  • 9
    They have: "This topic is specific to a legacy technology that is retained for backward compatibility with existing applications and is not recommended for new development. Distributed applications should now be developed using the Windows Communication Foundation (WCF)." from http://msdn.microsoft.com/en-us/library/kwdt6w2k.aspx – Lucas Jun 19 '10 at 03:01
  • I have worked with Remoting for years.. For small-scale applications, ( e.g. passing up to 1k small objects ) it is very straight-forward and efficient. Above that limit, No! It really sucks. You have to zip data before sending and this adds extra overhead ( CPU usage ). I had a very frustrating memory with the issue. – Behzad Sedighzadeh Jun 19 '19 at 20:05
3

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.

Tim Cooper
  • 144,163
  • 35
  • 302
  • 261
Kent Boogaart
  • 165,446
  • 34
  • 376
  • 376