Annotation of wikisrc/projects/project/pubsub-sockets.mdwn, revision 1.2

1.1       dholland    1: [[!template id=project
                      3: title="Publish-subscribe Unix sockets"
                      5: contact="""
                      6: [tech-kern](,
                      7: [tech-net](,
                      8: [David Holland](
                      9: """
1.2     ! dholland   11: category="networking"
1.1       dholland   12: difficulty="hard"
                     14: description="""
                     15: Add publish-subscribe sockets to AF_UNIX (filesystem sockets).
                     17: The idea of a publish-subscribe socket (as opposed to a traditional
                     18: socket) is that anything written to one end is read out by _all_
                     19: processes reading from the other end.
                     21: This raises some issues that need attention; most notably, if a
                     22: process doesn't read data sent to it, how long do we wait (or how much
                     23: data do we allow to accumulate) before dropping the data or
                     24: disconnecting that process?
                     26: It seems that one would want to be able to have both SOCK_STREAM and
                     27: SOCK_DGRAM publish/subscribe channels, so it isn't entirely clear yet
                     28: how best to graft this functionality into the socket API.
                     29: Or the socket code.
                     30: It might end up needing to be its own thing instead, or needing to
                     31: extend the socket API, which would be unfortunate but perhaps
                     32: unavoidable.
                     34: The goal for these sockets is to provide a principled and robust
                     35: scheme for passing notices around.
                     36: This will allow replacing multiple existing ad hoc callback schemes
                     37: (such as for notices of device insertions) and also to allow various
                     38: signaling schemes among user processes that have never been very
                     39: workable in Unix.
                     40: Those who remember AREXX will recognize the potential; but of course
                     41: it will take time before anything like that can be orchestrated.
                     43: For this reason it's important that it be reasonably easy for one of
                     44: the endpoints to be inside the kernel; but it's also important that
                     45: peer credentials and permissions work.
                     47: Another goal is to be able to use publish/subscribe sockets to provide
                     48: a compatibility library for Linux desktop software that wants to use
                     49: dbus or any successor to dbus.
                     51: I'm marking this project hard as it's still only about half baked.
                     52: """
                     53: ]]

CVSweb for NetBSD wikisrc <> software: FreeBSD-CVSweb