Named pipes or TCP for client/server communication

My application supports multiple instances of the same server process (Windows Service), just like f.e. SQL Server.

The client/server communication will only take place in the same network.

I can use TCP, but then I have to configure separate IP ports for every server instance. I can however simply use named pipes so I don't have to think about port numbers and simply use the name of the server instance.

There will not be very frequent and/or large data client/server communication. It's some sort of a ERP application that will only communicate once per 30 seconds on average.

Also I want to prevent any client/server communication outside the network (intranet).

What is the wise choice here?

Update: Both client and server are written using .NET 4 and no thi开发者_如何转开发rd party client will be able to use the server.

---

I'm using .net 4.0 named pipes (System.IO.Pipes) in a couple of my personal projects and they are a pleasure to work with. You can use named pipes across the whole intranet and very performant so my personal advice would be to go with the named pipes.

Also the .net 4.0 named pipes clients utilizes the underlying WinAPI so you can also communicate with native apps from your .NET application.

---

It'll depend on client technology.

If both server and client are full .NET Framework, named pipes sounds fine.

But if some of clients could be anything that's not .NET Framework (Web client, Silverlight or something like that), named pipes will be an excess of pain as not all client technologies have any sort of networking connectivity or out-of-the-box API for doing anything in your mind.

Summary:

• Use named pipes if both client and server is using .NET Framework and it always will be this way and there's no plan to implement anything different than this scenario.

• Use TCP if you want to ensure your server can communicate with any kind of client technology.

Anyway, are you going to do so with WCF? Maybe using TCP or named pipes can be just a configuration thing. Check this MSDN article:

• http://msdn.microsoft.com/en-us/library/ms733769.aspx