I believe Q/Kdb+ to have the most natural implementation of IPC that I've seen, as long as you can keep all your gear inside Q.<p>To connect to another host you just do:<p><pre><code> remote:hopen `:server:port;
</code></pre>
The port number is specified with -p on the command line. To send messages:<p><pre><code> answer:remote "sum x"
</code></pre>
or if strings are repulsive to you you can pass in an expression like: answer:remote (`sum;x). `sum here is a symbol which is like a reference to a variable (or function). You can also pass a literal function for the remote host to execute, since they're just data.<p>You can also do asynchronous calls using the negative value of the handle (which is just a file descriptor int, wildly enough): neg[remote] (`incViews;`welcomepage;1)<p>Completely natural and simple. The only issue that I'm aware of is a 2gb limit for each message. Built-in functions can split your data into blocks to transmit large amounts.<p>The in-memory representation of data and the network representation are essentially the same. So there's no costly per-byte packing or unpacking going on, simply a memcpy(). In terms of performance and power use (environmental impact) this is a huge win.<p>It's trivial to expose data to the outside world by creating a web server. Simply define a function called .z.ph (or .z.pp for POST). This one evaluates the URL requested as a Q expression and returns the result as json.<p><pre><code> .z.ph:{.j.j value x 0}
</code></pre>
Being able to build services as simply as this allows you to begin to think about the microservice as the unit of program composition, rather than classes, functions, or modules. Microservices have their own issues, but that's a topic for a later rant.
Looks to me like DBus is actually pretty good and just needs some good implementations, some bug reports and some active contributors. I'm not super familiar with non-server applications in linux, but isn't DBus also in widespread use?<p>Most linux server apps I know communicate through the filesystem by leaving a .pid,.lock and/or a .sock somewhere and then setting up a custom channel using a handle to that. It feels kind of hacky, but at least you get to control the crappiness.
Encoding complex objects is just hard (in the sense that it's going to get ugly, complicated, and usually both); however, just getting framing right (i.e. ensuring that client and server agree on where messages/objects start and end) at least solves many security problems. A simple binary (tag-)length-value works, as do schemes based on <a href="http://cr.yp.to/proto/netstrings.txt" rel="nofollow">http://cr.yp.to/proto/netstrings.txt</a>.
gRPC is probably worth mentioning in this thread (new since the article), though I haven't used it yet and have no idea if it can satisfy his asynchronous requirement.<p>He considers using message queues and dismisses the idea because "you're still on your own in implementing an RPC mechanism on top of that. And for the purpose of building a simple RPC mechanism, I'm convinced that plain old UNIX sockets or TCP will do just fine.".<p>In my experience, getting an arbitrary sized message from A to B over a potentially unreliable network is the difficult bit and implementing a basic RPC mechanism is pretty easy. I did a project that required a lot of IPC and ended up using nanomsg (also not mentioned in the article.. it's very similar to zeromq) for [fast] reliable message delivery and wrote my own basic RPC layer on top of this (NanomsgRPC - currently C# only ..). This worked pretty well for me.<p>A note on nanomsg though: I wouldn't consider it stable enough for production use, but that said, it didn't give me any problems for what I used it for.
This is pretty much why Jordan Hubbard &co are bringing Mach IPC and other NeXT/Apple technologies to FreeBSD: <a href="http://youtu.be/49sPYHh473U" rel="nofollow">http://youtu.be/49sPYHh473U</a><p>It turns out that some of these problems already do have pretty decent solutions.