Simplest way to establish an IPC mechanism in C++

Question

1.00/5 (1 vote)

See more:

Between different types of IPC mechanisms in Linux for local host, what's the most efficient way in terms of data exchange speed and code simplicity in C++?

Is it D-Bus or UDP sockets or other mechanisms i.e. Sys-v, signals or pipes? And why?

Posted 27-Mar-14 3:26am

Mr.HA-AS

Add a Solution

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Albert Holguin · Accepted Answer · 2014-03-27T05:18:00

Solution 2

With IPC, there really is no "best" option. They all have positive and negative aspects.

For example, fastest would probably be something like shared memory, but it's not all that practical outside of a single system framework and any solution is also not likely to be cross-platform. Using sockets, it doesn't matter where the two (or more) pieces are located or the host OS, but there will be some overhead processing that's done by the OS, so it's naturally slower (by comparison).

Even within each IPC type, there's different subtypes that will have pros/cons. For example, you mentioned UDP. Well, UDP will be faster than TCP but has no guarantee of delivery (or order of delivery). So if you MUST have each packet delivered, UDP is a bit impractical. You could build a check system in at the application layer, but at that point you start to replicate TCP.

One example of systems that use shared data are virtual simulators. They must work as close to real-time as possible, otherwise the experience will lag, so they have to use the fastest IPC available, whereas streaming music can get away with TCP/IP, because the sampling rates of music can usually be low enough to be transmitted with all the beneficial guarantees of TCP/IP. On the other hand, a lot of video teleconferencing is done with UDP, because they don't care if a packet or two are dropped as long as most make it.

To summarize, look at your application and define what are your system top priorities and what are things you can live without, then look at your IPC options and see what fits closest to what you need.

Posted 27-Mar-14 5:18am

Albert Holguin

Comments

Mr.HA-AS 27-Mar-14 12:04pm

Thanks a lot for your answer. But what do you mean by outside of a single system framework?
In my program, I mainly use the Boost library ,and they have an IPC library, which depends on the Shared memory mechanism. so do you recommend me to use it as a solution to the below case?

Currently in my design I have singleton process at sometime this process will send a notification to a certain number of processes to send back their data to it. The singleton process will have to wait until all the data have been collected from different processes. So it's many to one commmunication.

Later at some time, the singleton process will receive some data over a TCP connection, then it has to divide these data and distribute each portion to its corresponding process. So I have one two many communication.

The most important and critical thing, is to exchange the data in a fast way between the processes on the same platform, and without losing any in-flight data " The amount of data is not so big", and I want to have the minimum possible overhead.

I think, I should use some kind of message bus. But I know the message bus will add some overhead in terms of processing and delay, correct or not?

Albert Holguin 27-Mar-14 16:08pm

There would still be a lot of questions... would all of your clients get all of the same data or use different streams? ...what are the data rates we're talking about? Some think real-time voice rates are high, but that's actually slow by today's standards, so it really depends on how much data you're moving.

Typically I would recommend to use sockets when possible because they're probably the most flexible IPC option available today, however, they're not nearly the fastest. If you're dealing with a high-volume of data at high-rates, then the overhead of sockets starts to become an issue (you also have to keep in mind that the network stack is a shared system resource). In that case, you have to look at faster options.

Mr.HA-AS 27-Mar-14 17:03pm

For my case the data rate is moderate. Regarding your suggestion, if I want to use sockets, I might have a lot of processes talking to the singleton process. The number of processes is dynamic. So If I want to use Message Bus, I don't have to care about adding or removing a process, whereas for the sockets, each time I add a new process I need to establish p2p connection, correct?

Albert Holguin 27-Mar-14 17:17pm

You would need a new connection every time (unless you use connection-less transfers, but then you lose some of the benefits of sockets). I'm not sure I know what you mean when you say "message bus". Typically any messaging system will require a messaging marshaling system (i.e. something that does the actual message transfers). In Windows messaging, that's just the Windows kernel. Not sure if that's the type of messaging you're referring to. Sockets can actually serve in a similar fashion if configured properly, for example... if all clients are accessing the same data, you could use multicasting, where everyone interested in the data joins the multicast group and receives the datagrams (packets).

Albert Holguin 27-Mar-14 17:20pm

Messaging also has it's pros/cons... for example, to use windows messaging, you need a window, you can't message to an application that doesn't have a window (although the window can be invisible), and of course, the messaging is that case is Windows specific and cannot be used in any other OS.

Mr.HA-AS 27-Mar-14 17:39pm

The message bus is a mechanism for IPC, you can check the following site from Microsoft about the mechanism it self:
http://msdn.microsoft.com/en-us/library/ff647328.aspx

For Linux implementation, you can check "D-Bus".
And there's a popular solution zeroMQ which contains bindings for different languages.

I agree with you regarding the multicasting, it's a good solution.

Albert Holguin 27-Mar-14 18:03pm

You do realize that in the MS link you provided it says (i.e. no longer supported):
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Mr.HA-AS 27-Mar-14 18:25pm

Yeah, I know. But the rest like zeroMQ, are going on solutions. For example zeroMQ is being used in CERN.
Also message bus mechanism is being adapted by different companies like AllJoyn for IoT.

Albert Holguin 28-Mar-14 17:34pm

Personally, I wouldn't use a solution that will require a third party daemon if you don't have to.

Sergey Alexandrovich Kryukov · Accepted Answer · 2014-03-27T04:01:00

Solution 1

The attempt of comparison would be incorrect by definition. What is "most efficient", how would you define it? Say, sending the signal and handling it would probably be the fastest, but through the sockets you can send and receive some data…

—SA

Posted 27-Mar-14 4:01am

Sergey Alexandrovich Kryukov