How to do interprocess connections between more than 2 apps?


#1

I just checked the InterprocessConnection class, but it seems to lack an important feature for me, namely the ability to send messages to as many listening processes as I want. Is this difficult to do?

The only quick solution i find is to use N pipes:

  • At start, each process first tries to open a pipe, going from myPipe0 to myPipeN (if myPipe0 cannot be opened, it tries myPipe1, then myPipe2, asf. until myPipeN).
  • When one of the processes wants to send a message to all other processes, it will send the same message to myPipe0 … myPipeN so all processes get it.

Is this a correct way of doing it? Is there a simpler/neater way?


#2

It’s quite a complex problem… I guess another approach would be to nominate one process as a hub, and have it route messages between all the others. But it’s all quite fiddly to get right.


#3

Perhaps the easiest way to do that is by using an InterprocessConnectionServer. When you open an app, it tries to connect to an existing socket, which will always fail for the first app you open. If it fails to connect, it should open an IPCServer that listens for clients to connect - this app acts as a kind of hub. The next app you open won’t fail to connect, so it can connect to the existing hub and won’t open an IPCServer itself. Every app that wants to send messages sends it only to the serer it is connected to and the server can broadcast incoming messages to all connected clients, that’s it.

There might be some problems, when the server is closed before the clients are closed. In this case, all apps get the connection lost message. Now every app should do the same as when it was opened: Try to connect, if it fails open an IPCServer. The first client app that gets the connection lost message should now be the IPCServer, while the other clients can connect again.

Maybe there are some special cases where you have to tweak this, but generally it should work like this.


#4

I have a suggestion on this :

As Julian suggested, you should have a single server, because then it would be easier to handle the server.

All the clients at start up should check if the server application is available in it’s required location and if it’s not running, if it is true for both. Then the client can launch server. Otherwise it can try to connect to the server/avoid connection.

If the server crashes when clients are still around, one of the client should try to launch the application. Server shouldn’t allow more than one instance.

But am not sure about handling things if the client and server are in different machine.


#5

The thing that’s really problematic in my case is that it needs to be really fast, to do some communication between the different processes (let’s say 10 transactions) should not require more than 1ms at most. I haven’t checked how fast it is with named pipes, but I wonder if they are good for more or less realtime purposes…


#6

Pipes might be quite quick for large transfers, but I wouldn’t expect them to be good for real-time work. You’d probably be better-off looking at a shared-memory solution.


#7

If you wanna try the shared memory solution, then check out the boost c++ library. I did something similar some weeks ago using the boost c++. It’s cross platform, free, well documented and works fine.


#8

Thanks, will have a look at Boost then!


#9

Actually, it worked pretty well using Boost C++'s interprocessing, thanks for the hint! I haven’t tried on OS X yet, though. Will post my results later!