Need help designing an inter-process comm layer

Question

Hello everyone,

I have several process in my system that need to communicate with each other.

Some of the processes need to pass chunks of data 60 times per second continuously, and some are very sporadic.

Most of the processes are in C#, one is C++.

All running on the same windows 7 machine.

Right now each process has it's own different comm implentation (pipes, events and sockets). I'm looking to unify into one communication layer.

• How would you implement this?
• Maybe some kind of broadcast with the intended receiver as header?
• What method of process communication would you choose?

Thanks,

SW

Answer 1

I'm using a WCF service to communicate between .Net processes and .Net and Java processes. I found WCF a very easy way to achieve this purpose.

Answer 2

Take a look at MSMQ. It's socket-based and quite fast. This article describes how to use it from C++: http://msdn.microsoft.com/en-us/library/ms811055.aspx.

You also didn't mention whether your communication is synchronous or asynchronous (does the writer have to wait for a response from the reader?). Do you have multiple writers and readers? Is it a constant 60Hz or does it come in bunches with breathing room where readers can catch up to writers?

A database table can also be used as a queue, and has the advantage of persisting the messages if the system crashes. A low-overhead embedded engine like Sqlite is well-suited for this.

Answer 3

I would suggest using ICE, which supports remote objects and message passing. It will have no problem meeting your rates and bandwidth needs. It's also cross platform and supports languages other then just C# or C++, giving you more languages choices for other components.

Answer 4

Note that messaging middleware solutions (like WCF and ICE) are powerful engines giving you features like reliable message delivery, control over message ordering, distributed (multi-machine) capability etc.

They are also relatively complex and may involve a degree of 'framework' learning.

If your application currently works reliably today, it might be an idea to introduce whatever messaging solution you select for your next new functionality initially and prove it there first. You could then retrofit to your existing processes (if...) and when necessary.