Communication between processes

Question

I'm looking for some data to help me decide which would be the better/faster for communication between two independent processes on Linux:

• TCP
• Named Pipes

Which is worse: the system overhead for the pipes or the tcp stack overhead?

---

Updated exact requirements:

• only local IPC needed
• will mostly be a lot of short messages
• no cross-platform needed, only Linux

Answer 1

I think the pipes will be a little lighter, but I'm just guessing.

But since pipes are a local thing, there's probably a lot less complicated code involved.

Other people might tell you to try and measure both to find out. It's hard to go wrong with this answer, but you may not be willing to invest the time. That would leave you hoping my guess is correct ;)

Answer 2

In the past I've used local domain sockets for that sort of thing. My library determined whether the other process was local to the system or remote and used TCP/IP for remote communication and local domain sockets for local communication. The nice thing about this technique is that local/remote connections are transparent to the rest of the application.

Local domain sockets use the same mechanism as pipes for communication and don't have the TCP/IP stack overhead.

Answer 3

There will be more overhead using TCP - that will involve breaking the data up into packets, calculating checksums and handling acknowledgement, none of which is necessary when communicating between two processes on the same machine. Using a pipe will just copy the data into and out of a buffer.

Answer 4

I don't really think you should worry about the overhead (which will be ridiculously low). Did you make sure using profiling tools that the bottleneck of your application is likely to be TCP overhead?

Anyways as Carl Smotricz said, I would go with sockets because it will be really trivial to separate the applications in the future.

Answer 5

I discussed this in an answer to a previous post. I had to compare socket, pipe, and shared memory communications. Pipes were definitely faster than sockets (maybe by a factor of 2 if I recall correctly ... I can check those numbers when I return to work). But those measurements were just for the pure communication. If the communication is a very small part of the overall work, then the difference will be negligible between the two types of communication.

Edit Here are some numbers from the test I did a few years ago. Your mileage may vary (particularly if I made stupid programming errors). In this specific test, a "client" and "server" on the same machine echoed 100 bytes of data back and forth. It made 10,000 requests. In the document I wrote up, I did not indicate the specs of the machine, so it is only the relative speeds that may be of any value. But for the curious, the times given here are the average cost per request:

• TCP/IP: .067 ms
• Pipe with I/O Completion Ports: .042 ms
• Pipe with Overlapped I/O: .033 ms
• Shared Memory with Named Semaphore: .011 ms

Answer 6

Two things to consider:

1. Connection setup cost
2. Continuous Communication cost

On TCP:

(1) more costly - 3way handshake overhead required for (potentially) unreliable channel.

(2) more costly - IP level overhead (checksum etc.), TCP overhead (sequence number, acknowledgement, checksum etc.) pretty much all of which aren't necessary on the same machine because the channel is supposed to be reliable and not introduce network related impairments (e.g. packet reordering).

But I would still go with TCP provided it makes sense (i.e. depends on the situation) because of its ubiquity (read: easy cross-platform support) and the overhead shouldn't be a problem in most cases (read: profile, don't do premature optimization).

Updated: if cross-platform support isn't required and the accent is on performance, then go with named/domain pipes as I am pretty sure the platform developers will have optimize-out the unnecessary functionality deemed required for handling network level impairments.

Answer 7

I don't know if this suites you, but a very common way of IPC (interprocess communication) under linux is by using the shared memory. It's actually ultra fast (I didn't profiled this, but this is just shared data on RAM with strong processing around it).

The main problem around this approuch is the semaphore, you must build a little system around it so you must make sure a process is not writing at the same time the other one is trying to read.

A very simple starter tutorial is at here

This is not as portable as using sockets, but the concept would be the same, so if you're migrating this to Windows, you will just have to change the shared memory create/attach layer.

Answer 8

unix domain socket is a very goog compromise. Not the overhead of tcp, but more evolutive than the pipe solution. A point you did not consider is that socket are bidirectionnal, while named pipes are unidirectionnal.