Named pipes or TCP for client/server communication

5
votes

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 third party client will be able to use the server.

2
c#.netvb.nettcpnamed-pipes
Ease of choosing a name should not be the reason for preferring named pipes. How will the clients find out the name of the pipe? - Miserable Variable
Why not create an abstract transport framework and allow either named pipes or TCP to be used? SQL Server does exactly this. - Jonathan Dickinson
@Jonathan: Or use an existing one like WCF (which is part of .NET) - Stephan

2 Answers

4
votes

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.

2
votes

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: