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

Question

I created Hindi font resource (Mangal face) through LWUIT.

I have developed a small application which displays Hindi font on two components, Label and Text area. (Both components are LWUIT components)

It displays properly in Text Area but not in Label.

It displays as letters separate and Matras separate, not as combined. (ex: क + । = का ).

Please give suggestions to my problem. Thanks in advance.

Solution 1

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

Solution 2

If it's on a single machine, Named Pipes gives you better performance and can be implemented with the remoting infrastructure as well as WCF. Or you can just directly use System.IO.Pipes.

Solution 3

If you mean inter-process communication, I used .NET Remoting without any problem so far. If the two processes are on the same machine, the communication is quite fast.

Named Pipes are definitely more efficient, but they require the design of at least a basic application protocol, which might not be feasible. Remoting allows you to invoke remote methods with ease .

Solution 4

Remoting in .NET Framework 2.0 provides the IPC channel for inter-process communication within the same machine.

Solution 5

If you are using the .NET Framework 3.0 or above, I would use WCF. Using WCF, you can use different bindings depeneding on the trade-off between performance/interop/etc. that you need.

If performance isn't critical and you need interop with other Web Service technologies, you will want to use the WS-HTTP binding. For your case, you can use WCF with either a net-tcp binding, or a named-pipe binding. Either should work.

My personal take is that the WCF approach is more clean as you can do Contract-Driven services and focus on messages, not objects (I'm making a generalization here based on the default programming models of WCF/.NET Remoting). I don't like sending objects across the wire because a lot of semantic information gets lost or is not clear. When all you are doing is sending a message like you are with WCF, it becomes easier to separate your concerns between communication and the classes/infrastructure that a single node is composed of.

View more solutions

Comments

[Kris Erickson]

Wow I just basically asked exatly the same question... stackoverflow.com/questions/84860/…

[aroon65]

WCF over named pipes allows this too. And you can just use the same contracts assembly in both processes.

[MarkJ]

Unlikely that they will enhance remoting. From someone on the remoting/WCF team: "there is very minimal development investment going into Remoting. WCF is the successor of Remoting." From here stackoverflow.com/questions/1294494/…

[MarkJ]

Further evidence in favour of remoting. From someone on the Microsoft remoting/WCF team: "there is very minimal development investment going into Remoting. WCF is the successor of Remoting." From here stackoverflow.com/questions/1294494/…

[Ricardo Peres]

A list of IPC APIs for .NET: weblogs.asp.net/ricardoperes/…