[[!template id=project

title="Publish-subscribe Unix sockets"

contact="""
[tech-kern](mailto:tech-kern@NetBSD.org),
[tech-net](mailto:tech-net@NetBSD.org),
[David Holland](mailto:dholland@NetBSD.org)
"""

category="networking"
difficulty="hard"

description="""
Add publish-subscribe sockets to AF_UNIX (filesystem sockets).

The idea of a publish-subscribe socket (as opposed to a traditional
socket) is that anything written to one end is read out by _all_
processes reading from the other end.

This raises some issues that need attention; most notably, if a
process doesn't read data sent to it, how long do we wait (or how much
data do we allow to accumulate) before dropping the data or
disconnecting that process?

It seems that one would want to be able to have both SOCK_STREAM and
SOCK_DGRAM publish/subscribe channels, so it isn't entirely clear yet
how best to graft this functionality into the socket API.
Or the socket code.
It might end up needing to be its own thing instead, or needing to
extend the socket API, which would be unfortunate but perhaps
unavoidable.

The goal for these sockets is to provide a principled and robust
scheme for passing notices around.
This will allow replacing multiple existing ad hoc callback schemes
(such as for notices of device insertions) and also to allow various
signaling schemes among user processes that have never been very
workable in Unix.
Those who remember AREXX will recognize the potential; but of course
it will take time before anything like that can be orchestrated.

For this reason it's important that it be reasonably easy for one of
the endpoints to be inside the kernel; but it's also important that
peer credentials and permissions work.

Another goal is to be able to use publish/subscribe sockets to provide
a compatibility library for Linux desktop software that wants to use
dbus or any successor to dbus.

I'm marking this project hard as it's still only about half baked.
"""
]]