IPC messagequeues: msgrcv vs pipessockets ACE

Salut Matt,

You can't really tell before your experiment it, actually. The performance of an IPC (latency, bandwith) largely depends on the underlying kernel implementation, and the results varies from systems to systems.

I suggest to run some benchmarks first on your target system(s) in order to make a clear statement. Ideas how to write such a benchmark can be found in Stevens, UNIX Network Programming, Vol 2 (Interprocess communication), 2nd Edition, Appendix A pp 457-499, ISBN 0-13-081081-9

As quoted by Donald Knuth "premature optimization is the root of all evil.". Choose rather the IPC that makes the program simpler. Get a working program first. Optimize only if your performance requirements are not met. Of course, if you're dealing with a big project, you might want to consider agile methodology like prototyping and test driven development. Obviously, you don't want to wait 3 years the code, to finally realized that - gee - the solution is not efficient enough.

If traditional IPC (socket, fifo, message queue) fails, then you can always roll own your own IPC using shared memory. Shared memory is the fastest form of IPC available. But this implies to take care about things that usually the kernel does for you (like synchronization etc.)

Ah - and a last note about System V message queue. This is a not well recognized fact, but implementation having the so called MSGTQL limits (AFAIK, only Linux and AIX doesn't have such a limit) are subject to a Denial of Service attack. Any non root users of the system may eventually block your server.

HTH, Loic.