Hi!
I wanted to know the advantages / disadvantages of different IPC mechanims such as sockets, pipes (unnamed) , shared memory & message queues.
Pipes for example i hear are fast , but are difficult to debug as compared to sockets.
Can you guys please name some situations where one is prefered over the other?
Thanks!
That's a broad, open question - it almost sounds like an essay for homework.
Either way, if you have a look at the introduction to each section in Beej's guide to Unix IPC, that should give you a decent background in all the standard methods of IPC, and I'm sure you can "compare and contrast" (or whatever) in your own head.
Please come back if there are any specifics you'd like to know/aren't sure about.
LOL ! School ended about 3 years ago. I have been working with C++ for about 3 years; i am actually trying to gain knowledge of system programming by either R&D or by Q&A. I'll run through the beej's guide.... thanks!
The reason i asked is , the book i am refering explains each mechanism well, but it does not say when to prefer one over the other.....
God i wish school was still on 
Cheers!
---------- Post updated 06-20-10 at 05:13 AM ---------- Previous update was 06-19-10 at 12:21 PM ----------
So i did go through that article, picked up a book on my way home (UNIX Systems Programming: Communication, Concurrency and Threads). They both do a wonderful job of explaining each of the IPC mechaisms...setting up keys, calling ctl/op functions... & destroying them.... Yet there is no mention of any performance implication or suggestion of when each of these should be preferred. So i have to ask again... are there any specific subsets of problems where one should be preferred over another.... i.e. for example whats stopping one from using named pipes as opposed to message queues?
Well, let's take a look at some situations where these things are used...
Shared memory avoids having to write data into and read it back out of the kernel, making it a blindingly fast way to share the same data with swarms of processes. Since it's not arbitrated by the kernel, it's got race conditions and pitfalls, so isn't as easy as it looks; when solving a complex enough problem you might find you're writing your own sockets from scratch instead of anything faster. You see it in situations with very demanding performance requirements, like high-performance audio or video interfaces(X11 drivers, XSHM video, DirectX). Linux's modern pthreads implementation builds mutexes and the like out of atomic operations on shared memory.
Named pipes are kind of an old-fashioned hack kept for portability reasons. Their behavior can be a bit obscure when dealing with more than one reader and/or writer. Occasionally handy in the shell to bridge unbridgables, otherwise I don't see them get much serious use.
UNIX domain sockets are very often used for local client/server interfaces because they're network-like(one server, multiple clients) without the overhead of loopback networking. Big things like X11 and MySQL servers serve clients with UNIX domain sockets when possible. Lots of less demanding system daemons and controllers(system loggers, linux udev, linux acpid, linux's wpa authentication manager) also use UNIX domain sockets for their convenience of network-like connect/disconnect without the complication of actual networking. They can't do any kind of sharing or broadcast sending.
pthreads is a threading implementation but often called (and used as) IPC anyway. Some implementations do allow seperate processes to share mutexes etc(the current NPTL linux implementation), some don't(linux's old linuxthreads implementation). Its features are tightly defined, fairly portable, and somewhat limited, mostly restricted to control mechanisms, not communication structures. By and large its overhead is quite low, but implementations of course vary. For simple control of threads it's difficult to beat.
System V IPC seems a bit overbuilt. Unlike POSIX thread primitives, this API is geared towards communications between unrelated processes, and frilled with so many features it's hard to imagine it not having significant overhead(most objects semi-persistent and given their own owner/group/attributes set, mtimes kept for many kinds of things, sometimes even last-user-modified). It has some interesting and difficult-to-implement features(grouping several semaphore operations atomically) which would be useful if implemented brilliantly, but can stall and starve if done badly, and implementations do vary. Message queues I'm unfortunately quite unfamiliar with.
Thanks corona... that was a fantastic reply.
Cheers!