Unix Stream Bus
"Unix is all pipes and pipes are easy. The rest is just common sense." - aep
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.
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.
You can also sort of "call" a method of an application, much like the big
RPCs do, except this one is just trivial:
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
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)
$ echo "hi" | ubus-connect test/catb
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
$ echo "hi" | socat STDIO UNIX-CONNECT:~/.ubus/test/catb
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.
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
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.
If you have trouble reading that, see the
reference implementation. Or bother me on irc (thats "aep" on oftc or
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,
In short, zeromq is an amazing system for building distributed applications, but it is not an IPC.
- No obscure implementation. It's just a pipe.
- No system daemon. Buses are taken care of by their owners.
- No xml. You can parse rmi with a shell script.
- No werd-kit. Because a bus is a file, standard unix permissions work fine.
- No strong signatures (one could argue that is a disadvantage)
- No dependencies. Not even to libubus.
- No application specific network bridge. It's a pipe + it can pipe over ssh = win
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:
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.
- Neutral. Ubus does not add framing, because it doesn't use a fragmenting carrier.
- Async. Ubus does never expect messages in a particular order, and never does any routing behind the scenes.
- Human readable names. Ubus uses human readable and explorable names through files
- Portability. ZeroMQ is much more portable than ubus.
- Security. Ubus has builtin security through unix permissions. Zmq relies on app specific security.
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.