Unix Stream Bus

"Unix is all pipes and pipes are easy. The rest is just common sense." - aep
  1. Introduction
  2. Getting started
  3. Specification
  4. Implementations
  5. Can I send you a patch?
  6. Compared to (dbus|zmq)?

Whats ubus?

A ubus is a unix domain socket (AF_UNIX and SOCK_STREAM).
Nothing special, you could just open it with netcat or socat.
The cool part is actually how the ubus spec allows you to communicate with another app in a standard way.
It's a full fledged Inter-Process Communication system, except it's not built on crap like corba.

So, err ... what?

ls /var/ubus/ shows you a list of system daemons that offer one or multiple ubus.
ls ~/.ubus/ does the same for stuff that you run as a regular user. Chat clients for example.
Let's for a second assume you use weechat with ubus.pl, so that you have a bus ~/.ubus/weechat/pv.signal
That's a signal, so you can just go ahead and listen to it. You can use any unix socket implementation, like socat, netcat, whatever, but for now we'll use "ubus-connect weechat/pv.signal".
Now, if someone sends you a private message, you'll get stuff like:
    aep     hi! lol
Well, aep sent you a message. Now you can just go and build your favorite notification tool that listens to that signal. Or have two listen to it, or three, or a lot! If you are wondering how the heck the nick and message are seperated, we'll get to that later in the specification. It's dead simple. (hint: its tab)
You can also sort of "call" a method of an application, much like the big RPCs do, except this one is just trivial:
$ echo "hi" | ubus-connect test/catb
  1   hi
So, what this does is actually just open a pipe and write hi to it. The service on the other end throws it back with a line number attached (this is cat -b). I'd like to point out, again, that any unix socket implementation works.
$ echo "hi" | socat STDIO UNIX-CONNECT:~/.ubus/test/catb
  1   hi
Same thing!

So what do I need to create a bus?

Your choice really. All you need is a unix domain socket implementation and the spec. Almost any language I can think of, has it.

There are also readily available implementations which you can choose from.

Offer buses from shellscript?

Sure,if you have a shell like zsh, you could just implement it in pure shell. I recommend using the "ubus" binary from the reference implementation. It allows opening, closing, connecting, etc from one fd, so its easier to handle in shell.

Is ubus network transparent?

Because ubus is just pipes, anything that can bridge pipes between machines works.
    echo "hi, i'm from outer space" |  ssh user@othermachine ubus-connect ~/.ubus/amvient/notify.method
No kidding, it's that simple.

So, gimme the spec already

Here goes: Ubus specification
If you have trouble reading that, see the reference implementation. Or bother me on irc (thats "aep" on oftc or freenode)

You said, reference implementation?

Projects using Ubus

Can I send you a patch?


How does it compare to D-Bus?

Ubus was invented to replace the tiny fraction of D-Bus that actually solve a problem.
It is, like D-Bus, a unified message exchange between processes, using human readable names and structures.
Everything else is intentionally left out and patches to add it will not be accepted.

If you want to have a biased list of differences, here goes:

How does it compare to ZeroMQ?

In short, zeromq is an amazing system for building distributed applications, but it is not an IPC.
Surprisingly it has a lot of similarities with ubus, such as "Just sockets on steroids", or the non-need of a broker, without either project having known the other
It rather belongs in the same category as JMQ, because it solves the same problem (but in a much more elegant way),
as a consequence it adds alot of features that you will need in distributed applications, and does not care about being carrier neutral.
At the same time it is missing features that you need when not all of the communication nodes are from the same vendor
Major technical differences would be:

Wtf, socket per method? Fd limit anyone?

Do you seriously need more than 1024 methods? Well then spawn another process and rewire. On the other hand, I think more then 20 methods is already a slightly unusual design.
The claim that using one socket per method is bloat, is also rather short sighted. This is not TPC. AF_UNIX is cheap, and switching between fds is the same complexity as switching on a prepended message id. Connecting is more expensive then opening a virtual channel on an established connection, thats true, but even then that will hardly become a bottleneck. Instead, other RPC implementations use virtual channels or message ids because there is no sane way to connect ports to names.