7 ms·

AFAIK, 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

AFAIK, 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 ago
I 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 ago
  How's it perform on tmpfs or ramdisk?
- wahern 10y ago
  1) 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 ago
  That'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.

bitwize 10y ago

I 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 ago
How's it perform on tmpfs or ramdisk?
wahern 10y ago
1) 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 ago
That'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.