Interprocess Communication for Windows in C# (.Net 2.0)

Interprocess communication for Windows in C# (.NET 2.0)

IPC in .Net can be achieved using:

WCF

using named pipes requires .Net 3.0 and above.

Code example

• The WCF class NetNamedPipeBinding can be used for interprocess communication on the same machine. The MSDN documentaion for this class includes a code sample covering this scenario http://msdn.microsoft.com/en-us/library/system.servicemodel.netnamedpipebinding.aspx

---

Remoting

The original IPC framework released with .Net 1.0. I believe remoting is no longer being actively developed, and you are encouraged to use WCF instead

Code example

Inter-process communication via Remoting - uses a tcp channel

Resources

• GenuineChannels, sell a remoting toolkit that includes a Shared Memory Channel. http://www.genuinechannels.com/Index.aspx
• Ingo Rammer, wrote the definitive .Net remoting book, Advanced .NET Remoting, Second Edition

---

Win32 RPC using csharptest-net RpcLibrary

I came across a project recently that has wrapped the Win32 RPC library and created a .net class library that can be used for local and remote RPC

Project home page: http://csharptest.net/projects/rpclibrary/

MSDN references:

• How rpc works: http://technet.microsoft.com/en-us/library/cc738291(v=ws.10).aspx
• RPC functions: http://msdn.microsoft.com/en-us/library/aa378623(v=VS.85).aspx

Also has a google protocol buffers rpc client that runs on top of the library: https://code.google.com/p/protobuf-csharp-rpc/

---

WM_COPYDATA

For completeness it's also possible to use the WIN32 method with the WM_COPYDATA message. I've used this method before in .Net 1.1 to create a single instance application opening multiple files from windows explorer.

Resources

• MSDN - WM_COPYDATA
• Code example
• PInvoke.net declaration

Sockets

Using a custom protocol (harder)

.Net 2.0 Windows Service Process Communication: Database or IPC?

On the contrary, using a database as your inter-process communication channel is a terrific practice due to the common requirement you mention at the end of your question:

It is VERY important that I'm
guaranteed that the items in the queue
will persist if the system crashes or
the services are shut down.

Just make sure that the flagging happens within the same transactional scope as any other data changes wrought by process A.

You might even consider breaking this into two services and using a MessageQueue between the logical processes A and B.

Best way for interprocess communication in two ways between a server and a client

If you don't know anything about communication, pick an off the shelf solution. A Bidirectional WCF channel is a good example. See What You Need To Know About One-Way Calls, Callbacks, And Events for a primer. Read WCF Overview (including all the links!) for an introduction into WCF.

If you are more versed into communications then you should had defined the problem more clearly:

• what authentication model is used? Kerberos, certificates, password, none?
• intranet or internet?
• who's doing the listenning? your own service, http.sys, WCF activation?
• and the most fundamental question: syncronous or asynchronous? And I do not mean asyn as an async API, but async as in queued message oriented protocol.

What is the best choice for .NET inter-process communication?

WCF is the best choice. It supports a number of different transport mechanisms (including Named Pipes) and can be completely configuration driven. I would highly recommend that you take a look at WCF.

Here is a blog that does a WCF vs Remoting performance comparison.

A quote from the blog:

The WCF and .NET Remoting are really comparable in performance. The differences are so small (measuring client latency) that it does not matter which one is a bit faster. WCF though has much better server throughput than .NET Remoting. If I would start completely new project I would chose the WCF. Anyway the WCF does much more than Remoting and for all those features I love it.

MSDN Section for WCF

Interprocess communication

After you create the pipe and have pipe handles, you read and write using the ReadFile and WriteFile APIs: see Named Pipe Client in MSDN for a code example.

---

However, I'm at loss exactly how to use them.

The "Named Pipe Client" section which I quoted above gives an example of how to use them.

For example, what are the types of all the arguments

The types of all the arguments are defined in MSDN: see ReadFile and WriteFile

how do I convert from a buffer of bytes which I presumably receive from the ReadFile method into a string and vice/versa?

You're sending the string using ASCIIEncoding, so you'll receive a string of non-Unicode characters.

You can convert that to a string, using the overload of the std::string constructor which takes a pointer to a character buffer plus a sencond parameter which specifies how many characters are in the buffer:

//chBuf and cbRead are as defined in the
//MSDN "Named Pipe Client" example code fragment
std::string received((const char*)chBuf, cbRead);

---

Related Topics