Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<h2>Unix IPC</h2> <p>Here are the big seven:</p> <ol> <li><p><a href="http://en.wikipedia.org/wiki/Pipe_%28Unix%29" rel="noreferrer">Pipe</a></p> <p>Useful only among processes related as parent/child. Call <a href="http://linux.die.net/man/2/pipe" rel="noreferrer"><code>pipe(2)</code></a> and <a href="http://linux.die.net/man/2/fork" rel="noreferrer"><code>fork(2)</code></a>. Unidirectional.</p></li> <li><p><a href="http://en.wikipedia.org/wiki/Named_pipe" rel="noreferrer">FIFO</a>, or named pipe</p> <p>Two unrelated processes can use FIFO unlike plain pipe. Call <a href="http://linux.die.net/man/3/mkfifo" rel="noreferrer"><code>mkfifo(3)</code></a>. Unidirectional.</p></li> <li><p><a href="http://en.wikipedia.org/wiki/Internet_socket" rel="noreferrer">Socket</a> and <a href="http://en.wikipedia.org/wiki/Unix_domain_sockets" rel="noreferrer">Unix Domain Socket</a></p> <p>Bidirectional. Meant for network communication, but can be used locally too. Can be used for different protocol. There's no message boundary for TCP. Call <a href="http://linux.die.net/man/2/socket" rel="noreferrer"><code>socket(2)</code></a>.</p></li> <li><p><a href="http://en.wikipedia.org/wiki/Message_queue" rel="noreferrer">Message Queue</a></p> <p>OS maintains discrete message. See <a href="http://opengroup.org/onlinepubs/007908799/xsh/sysmsg.h.html" rel="noreferrer">sys/msg.h</a>.</p></li> <li><p><a href="http://en.wikipedia.org/wiki/Signal_%28computing%29" rel="noreferrer">Signal</a></p> <p>Signal sends an integer to another process. Doesn't mesh well with multi-threads. Call <a href="http://linux.die.net/man/2/kill" rel="noreferrer"><code>kill(2)</code></a>.</p></li> <li><p><a href="http://en.wikipedia.org/wiki/Semaphore_%28programming%29" rel="noreferrer">Semaphore</a></p> <p>A synchronization mechanism for multi processes or threads, similar to a queue of people waiting for bathroom. See <a href="http://www.opengroup.org/onlinepubs/7990989775/xsh/syssem.h.html" rel="noreferrer">sys/sem.h</a>.</p></li> <li><p><a href="http://en.wikipedia.org/wiki/Shared_memory" rel="noreferrer">Shared memory</a></p> <p>Do your own concurrency control. Call <a href="http://linux.die.net/man/2/shmget" rel="noreferrer"><code>shmget(2)</code></a>.</p></li> </ol> <h2>Message Boundary issue</h2> <p>One determining factor when choosing one method over the other is the message boundary issue. You may expect "messages" to be discrete from each other, but it's not for byte streams like TCP or Pipe.</p> <p>Consider a pair of echo client and server. The client sends string, the server receives it and sends it right back. Suppose the client sends "Hello", "Hello", and "How about an answer?".</p> <p>With byte stream protocols, the server can receive as "Hell", "oHelloHow", and " about an answer?"; or more realistically "HelloHelloHow about an answer?". The server has no clue where the message boundary is.</p> <p>An age old trick is to limit the message length to <code>CHAR_MAX</code> or <code>UINT_MAX</code> and agree to send the message length first in <code>char</code> or <code>uint</code>. So, if you are at the receiving side, you have to read the message length first. This also implies that only one thread should be doing the message reading at a time.</p> <p>With discrete protocols like UDP or message queues, you don't have to worry about this issue, but programmatically byte streams are easier to deal with because they behave like files and stdin/out.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload