Menu
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 alike (and likely to be abstracted by a similiar interface anyway), in an application that is likely to already use sockets for network purposes anyway?
I can name at least the addressing issue: port numbers for sockets against filenames for pipes. Also, named pipes (AFAIK) won't alert the firewall (block/unblock dialog), although blocked applications can still communicate via sockets locally. Anything else to take into account?
In the case of using sockets, are there any winsock settings/flags that are recomended when using sockets locally?
1000
So, in relative terms, named pipes are approximately 30% faster than UNIX sockets with a block size of 100 bytes. When we compare the biggest block size of 1 Mbyte, the fastest IPC method was the UNIX socket, and the slowest was the anonymous pipe.
Sockets are used like pipes in many ways but, unlike pipes, they can be used across networks. Sockets allow unrelated processes on different computers on a network to exchange data through a channel, using ordinary read() and write() system calls. We call this remote interprocess communication.
Both are inter-process communication facilities. Sockets, also known as UNIX sockets, have the same programming interface and behaviour as network sockets, whereas named pipes, also known as FIFOs, behave like unnamed pipes.
A named pipe is a named, one-way or duplex pipe for communication between the pipe server and one or more pipe clients. All instances of a named pipe share the same pipe name, but each instance has its own buffers and handles, and provides a separate conduit for client/server communication.
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".
54
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.
33
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
