…a direct TCP socket is to a Hare, and in this race the hare wins every single time, at least if the racetrack is .NET 3.5. The siren song of Named Pipes is that your user doesn’t need to know a TCP/IP address to talk with your program, just the computer name and name of the pipe. We were developing a system with special PCs that had data collection hardware inside. We could name all of these computers the same and make life a little easier for the user (and more importantly the developer). Unfortunately, the performance of Named Pipes was less than half that about a direct TCP/IP socket.
The importance of Buffer Sizes
When I first noticed the speed problem with named pipes I wrote some TCP socket code. I initially used a 4K receive buffer and the performance was on par with what I was seeing with named pipes. Two Tortoises. Then a kind soul told me about the tcp monitoring and tweaking tool JPerf, which I promptly downloaded and installed on the client and server. It allowed me to quickly run some tests and prove that with my particular gigabit switch I could increase my received buffers up the 128K and improve the throughput from about 5% of 1 gigabit to over 95% of 1 gigabit! On the final system (which uses a different switch) I had to increase the buffers all the way to 1MByte to get the best performance. I then thought all I would need to do was increase the .NET named pipe receive buffer. Unfortunately, I never could find a way to do it. I asked for advice on the forums but the only helpful response I got indicated that there may be a fix in .NET 4.0 by using the NamedPipeClientStream’s CopyTo method. This method doesn’t exist in 3.5 and it’s not known if this can actually achieve the higher throughput seen by the lower level TCP socket. For now, the users will have to live with modifying the config file when the IP address of the computer changes.