C# - Wcf - Inter-Process Communication

C# - WCF - inter-process communication

Use the NetNamedPipeBinding for inter-process communication on the same machine. Use the NetTcpBinding if you are crossing machine boundaries. I've found this flow chart helpful.

WCF Binding Selection Flow Chart.

WCF - Fastest interprocess communication

As you have noted, the NetNamedPipeBinding binding is optimised for same-machine communication:

Provides a secure and reliable binding
that is optimized for on-machine
communication.

Ref. : System-Provided Bindings

In chapter one of Juval Lowy's book, "Programming WCF Services", he provides a useful decision-activity diagram for choosing the right binding:

"The first question you should ask
yourself is whether your service needs
to interact with non-WCF clients. If
the answer is yes, and if the client
is a legacy MSMQ client, choose the
MsmqIntegrationBinding that enables
your service to interoperate over MSMQ
with such a client. If you need to
interoperate with a non-WCF client and
that client expects basic web service
protocol (ASMX web services), choose
the BasicHttpBinding, which exposes
your WCF service to the outside world
as if it were an ASMX web service
(that is, a WSI-basic profile). The
downside is that you cannot take
advantage of most of the modern WS-*
protocols. However, if the non-WCF
client can understand these standards,
choose one of the WS bindings, such as
WSHttpBinding,
WSFederationHttpBinding, or
WSDualHttpBinding. If you can assume
that the client is a WCF client, yet
it requires offline or disconnected
interaction, choose the NetMsmqBinding
that uses MSMQ for transporting the
messages. If the client requires
connected communication, but could be
calling across machine boundaries,
choose the NetTcpBinding that
communicates over TCP. If the client
is on the same machine as the service,
choose the NetNamedPipeBinding that
uses named pipes to maximize
performance. You may fine-tune binding
selections based on additional
criteria such as the need for
callbacks (WSDualHttpBinding) or
federated security
(WSFederationHttpBinding)."

wcf implementation for interprocess communication

The problem with this approach is that your service needs to connect to the client as a host.

A better option would probably be to setup a WCF Callback when you first startup the client. The service can then use the callback for service to client notifications. For details, see this MSDN article which shows using WCF callbacks.

Inter-Process communication options

Named pipes are one of the fastest way to do IPC (inter-process communication) on the same machine. The have existed for a long while (was NT4 the first OS?) and not specific for WCF.

I would however not use WCF/Named pipes through ASP.NET as IIS do not use named pipes for it's communication. that means that your app will close if IIS have not received HTTP requests for a while.

How you should host your IPC depends on the type of application. If you want to always have your server running you should host it in a windows service. Otherwise you could just include it in your desktop app.

You do not necessarily have to use WCF, you can use named pipes directly (look at the link in the beginning of my message). It all depends on how complex your communication is.



Related Topics



Leave a reply



Submit