11 ms·
Can someone please explain what's wrong with the classical UNIX sockets and pipes that they need to invent and (re)invent dbus, bonobo, now bus1?
by nixos 10y ago
Can someone please explain what's wrong with the classical UNIX sockets and pipes that they need to invent and (re)invent dbus, bonobo, now bus1?
- rodgerd 10y ago> what's wrong with the classical UNIX sockets Well, for starters they're a bolt-on that doesn't fit with the actual classic Unix philosophy.
- cyphar 10y agoYou couldn't send credentials nor file descriptors to other processes without UNIX sockets. I would argue that allowing for that kind of decoupling of permissions and file access is very much in the spirit of the UNIX philosophy. Quite frankly, there are some problems you simply wouldn't be able to solve without them (in runC, the underlying runtime that Docker wraps, we use them quite extensively).
- gens 10y agoYou can send fd's through UDS and they do expose a lot of info on the process on the other side. http://www.thomasstover.com/uds.html http://www.thomasstover.com/uds.html
- amscanne 10y agoAFAIK, there's no good way to "broadcast" messages without bouncing through a user space co-ordinator. The current primitives just don't match this kind of need. Presumably, this inefficiency could be a bottleneck for some cases and eliminating the extra step might help, plus a kernel implementation could be simpler (no extra daemons, etc.)
- bitwize 10y agoI wrote a proof of concept that does multicast using the file system and inotify. A bit hacky and there are drawbacks, but it works.
- thwarted 10y agoHow's it perform on tmpfs or ramdisk?
- wahern 10y ago1) They want better performance over the existing solutions. For better or worse applications are [arguably] abusing the heck out of D-Bus. Using regular files might help with huge messages, but it's a lot of overheard for many small messages. 2) They want the ability to insert a broker that manages permissions among the peers, but have the kernel enforce those permissions on a per message basis so the broker doesn't become a bottleneck. That's not easy to with the filesystem. I mean, strictly speaking it's theoretically possible using the file system considering that in practice the only real broker would be systemd with a fixed set of policies, so theoretically the traditional Unix model of user, group, and supplementary groups would suffice by assigning users and processes into the proper groups, and binding message files into protected group-readable directories. But for whatever pretense, people want the solution to implement a system of opaque, ephemeral identifiers/capabilities. It sort of reminds me of SMF, launchd, systemd, and similar changes. For example, I was installing Solaris 11.3 on a VM yesterday and was trying to figure out how to set the hostname. You used to set it by storing the hostname to /etc/nodename. Now it's stored in some opaque tree data structure deep in the bowels of SMF, which you set with some long and impenetrable command-line utility invocation. You can still set /etc/nodename; if no hostname is configured then SMF will initialize the hostname from /etc/nodename and delete the file. It boggles the mind.
- amscanne 10y agoThat's clever, but there are reasons a purpose-built subsystem could be a better a fit: * Inotify events are coalesced. Great for notifications, may be bad for discrete messages. * The sender may want information about # of messages sent, synchronous delivery, etc.
- Pyxl101 10y agoThe design goals of bus1 are described here: https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-July/003047.html https://lists.linuxfoundation.org/pipermail/ksummit-discuss/... Some call-outs for you: > * efficiently support n-to-n communication. * be well-suited for both unicast and multicast messages. * guarantee a global message order. * avoid any in-kernel buffering and rather transfer data directly from a sender into the receiver's mappable queue (single-copy). The downside of the alternatives that you mention is that they're not available as kernel features in Linux. Bus1 is inspired by that previous work and aims to make a new attempt at inclusion in the kernel, which they believe is required to provide the features they're targeting: > A user-space implementation of bus1 (or even any bus-based IPC) was considered, but was found to have several seemingly unavoidable issues. > o To guarantee reliable, global message ordering including multicasts, as well as to provide reliable capabilities, a bus-broker is required. In other words, the current linux syscall API is not sufficient to implement the design as described above in an efficient way without a dedicated, trusted, privileged process that manages the bus and routes messages between the peers. (...)
- pjc50 10y agoGlobal message order sounds like the kind of commitment that becomes increasingly expensive in a multi core environment..
- grandinj 10y agohence the use of some nifty optimised clocking algorithms: https://github.com/bus1/bus1/wiki/Message-ordering https://github.com/bus1/bus1/wiki/Message-ordering
- tomegun 10y agoThe overhead due to the message ordering is constant, irrespective of the number of cores/peers. See the link posted above for an explanation.
- chubot 10y agoI'm very sympathetic to that point of view -- UNIX is a paradox where everybody uses it but most people don't really know how to use it. But this paper makes a good quantitative case for POSIX not meeting the needs of modern computing: https://news.ycombinator.com/item?id=11652609 https://news.ycombinator.com/item?id=11652609 A good example is that Linux distros, Android, and OS X all have their own non-POSIX IPC mechanisms. Applications are somehow voting with their feet and not using Unix domain sockets and pipes. It leaves me scratching my head because I don't think serialization is that hard a problem. But it seems that most people want IPC with structured data. Android is a bit of a special case because it's a single-language OS. "Traditional POSIX threading models, IPC interfaces, and file system access are being replaced by platform and vendor-specific APIs and frameworks such as Grand Central Dispatch [18], Binder [29], DBus [25], and SQLite [1]."
- pjmlp 10y ago> UNIX is a paradox where everybody uses it but most people don't really know how to use it. Specially when the majority nowadays has the idea that GNU/Linux == UNIX and never tried to write an actual portable UNIX application.
- saynsedit 10y agoEh? The majority of modern POSIXy software runs on at least Linux, Mac OS X, and FreeBSD. In fact, Mac OS X is the most widely deployed UNIX-like system ever. What you're a claiming to be true probably more applies to Mac OS X than Linux. I honestly haven't seen a recent package that was accidentally not portable in the long-term across the various modern UNIX-like systems because of confusion of Linux for POSIX.
- digi_owl 10y agoBecause the automotive industry wants to move from QNX to Linux, and wants to use dbus like they used QNX IPC beforehand. Thus we have projects like streaming video over dbus(?!). https://lwn.net/Articles/551969/ https://lwn.net/Articles/551969/
- cnvogel 10y ago> Large automotive companies have built huge systems on top of QNX > messages, creating large libraries used by their applications. > They would like to be able to use those libraries > on Linux, but often don't know that there is > a way to get the QNX message API for Linux. It is called SIMPL > and it works well. (from the LWN article)
- rwmj 10y agoIt's a shame that QNX is dying inside Blackberry. If there's one project I would love to see open sourced, it is QNX.
- hobo_mark 10y agoThey tried to open it for a short period, I remember getting the sources and playing with it: http://www.qnx.com/news/pr_2471_1.html http://www.qnx.com/news/pr_2471_1.html And now I notice it was almost ten years ago! Nevertheless, too little too late...
- cm3 10y agoAnd the reason this is more prevalent on QNX is that it's a microkernel based platform. Here, in Linux, there's the debate what should be allowed into the kernel, whereas that question is pretty much never asked for QNX. You also don't get discussions about circumventing the kernel network stack to avoid context switches, to name a prominent example. Microkernels also lend themselves better to multikernel designs where you aim to make better use of all the available cpu cores by reducing sharing.
- ndesaulniers 10y agoIn Binder's case, it makes RPC between different languages significantly easier. You can't pass file descriptors over sockets. You can't do RPC over pipes. Anonymous sockets can only be shared with children. Named sockets require write permission and a filesystem. SysV is prone to resource leaks. Binder has authentication, shared memory, reference counting, weak references, dead object notifications. The descriptors and authentication part is key, as it allows Android's trusted system_server to open a device or socket for an untrusted process such as an App if it has user permissions. The receiver of a binder request can check the requester's PID/GID and with confidence from the kernel. Most importantly, I don't think it's healthy to think of POSIX as being done. Some experimentation and discovery of better APIs and better systems should be encouraged. gah, I'm driving myself crazy; I swear I saw somewhere a diagram of the Taxonomy of Unix IPC Mechanisms, with most of them crossed out and replaced simply with binder, please help me find it!
- dozzie 10y ago> You can't pass file descriptors over sockets. Good that my code doesn't know this. It would stop working. > The descriptors and authentication part is key, [...] If by "authentication" you mean "checking PID/UID/GID", we already have both in unix sockets.
- CJefferson 10y agoHow do you pass a file descriptor through a socket? They just take bytes? If you mean "I send some bytes that describes the file to open, and keep my processes in sync manually", of course you can do that, but true passing would allow a number of cool things.
- pjmlp 10y agoThe UNIX War is dead, long live the GNU/Linux war. Ergo, POSIX wasn't the end.
- Philipp__ 10y agoBecause Linux people like to reinvent the wheel! :)
- the_why_of_y 10y agoAF_UNIX sockets don't do multi-cast. AF_INET sockets don't do FD passing or credentials. There was a patch to add an AF_BUS socket family some years ago that sounded like a pretty general solution but the network maintainer said "over my dead body". http://lwn.net/Articles/504970/ http://lwn.net/Articles/504970/