Geek Answers Handbook

Named pipes or TCP for client / server communication

My application supports multiple instances of the same server process (Windows service) as fe SQL Server does.

Client / server communications will only run on the same network.

I can use TCP, but then I need to configure separate IP ports for each server instance. However, I can just use named pipes, so I don’t need to think about port numbers and just use the server instance name.

There will not be very frequent and / or large client / server data transfers. This is a kind of ERP application that will only communicate once in 30 seconds on average.

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

What is the wise choice here?

Update. Both clients and servers are written using .NET 4, and a third-party client cannot use the server.

+4
source share
2 answers

I use .net 4.0 named pipes ( System.IO.Pipes ) in several of my personal projects, and they enjoy working with. You can use named pipes throughout the intranet and very efficiently, so my personal advice would be to go with named pipes.

In addition, .net 4.0 clients with pipe names use the base WinAPI, so you can also communicate with native applications from your .NET application.

+3
source

It depends on the technology of the client.

If both the server and the client are full .NET Framework, the named pipes sound great.

But if some clients may be something that is not the .NET Framework (web client, Silverlight or something like that), the named channels will be redundant, since not all client technologies have any network connection or outside An API for doing something in your mind.

Summary:

  • Use named pipes if both the client and server use the .NET Framework, and that will always be the case, and there is no plan to implement anything other than this scenario.

  • Use TCP if you want your server to communicate with any client technology.

Anyway, are you going to do this with WCF? Perhaps using TCP or named pipes might just be a configuration item. Check out this MSDN article:

+2
source

More articles:


All Articles