Sockets vs named pipes for local IPC on Windows?

Question

Are there any reasons for favoring named pipes over sockets for local IPC (both using win-api), effectiveness-wize, resource-wize or otherwise, since both behave very much a

Answer 1

Some subtle differences:

Sockets won't work for local IPC if you don't have a functioning adapter. How common is it to have a PC without a functioning adapter? Well, I got bitten when somebody tried to demonstrate our software to a customer on a laptop that was not plugged in to a network or a power supply (so the OS disabled the network card to save power) and the wireless adapter was disabled (because the laptop user didn't use wireless). You can get around this by installing a loopback adapter but that's not ideal.

Firewall software can cause problems with establishing TCP/IP connections. It's not supposed to be an issue for local IPC, but I'm not convinced. Named pipes can have firewalls too.

You may have issues due to the privileges needed to create named pipes, or to create new instances of named pipes. For instance, I was running multiple servers using the same named pipe (probably not a good idea, but this was for testing) and some failed in CreateNamedPipe because the first server to create the pipe was running in Administrator mode (because it was launched from Visual Studio in Administrator mode) while the rest were launched from the command line with normal UAC level.

Although the article mentioned by Rubens is mostly about IPC over a network, it does make the point that "Local named pipes runs in kernel mode and is extremely fast".

Answer 2

Another solution you may want to consider is a named shared memory region. It is a little bit of work because you have to establish a flow control protocol yourself, but I have used this successfully in the past where speed was the most important thing.