Ipc Performance: Named Pipe VS Socket

Performance of sockets vs pipes

Ken is right. Named pipes are definitely faster on Windows. On UNIX & Linux, you'd want a UDS or local pipe. Same thing, different name.

Anything other than sockets will be faster for local communication. This includes memory mapped files, local pipes, shared memory, COM, etc.

Named pipes vs. UDP for IPC on Windows

UDP packets even on localhost can be lost. Also, as UDP is datagram-based and has no guaranteed delivery, it's hard to transfer larger data blocks. Finally, UDP on localhost is sometimes blocked by browsers. In general, UDP is usually not even considered for single-computer IPC.

On Windows I recommend memory-mapped files + synchronization primitives as the fastest and probably the easiest method. Named pipes usually work well when you manage them to work, but I see lots of questions here regarding how to make the named pipes work at all (and I have yet to see a single complaint regarding MMFs).

We have a product, MsgConnect, which provides socket-, UDP- and MMF-based transports, suitable for IPC locally or across network, so I have practical experience with this topic. Named pipes were considered for support but then the idea was discarded in favor of other mechanisms.

IPC speed and compare

Been facing a similar question myself.

I've found the following pages helpful - IPC performance: Named Pipe vs Socket (in particular) and Sockets vs named pipes for local IPC on Windows?.

It sounds like the concensus is that shared memory is the way to go if you're really concerned about performance, but if the current system you have is a message queue it might be a rather... different structure. A socket and/or named pipe might be easier to implement, and if either meets your specs then you're done there.

Full duplex named pipe lockup when written to

when file created for synchronous I/O (flag FO_SYNCHRONOUS_IO present in FILE_OBJECT ) all I/O operations on file is serialized - new operation will be wait in I/O manager before passed to driver, until current(if exist) not complete. in concurrent can execute only single I/O request. if we do blocked read in dedicated thread - all another I/O request on this file will be blocked until read not complete. this related not only to write. even query file name/attributes will block here. as result render reading in separate not help here - we block on first write attemp. solution here use asynchronous files - this let any count of I/O operation execute in concurrent.

---

Related Topics