| |||||||||||||
Missing the AF_BUSMissing the AF_BUSPosted Jul 12, 2012 5:28 UTC (Thu) by slashdot (guest, #22014)Parent article: Missing the AF_BUS
Why is a bus even needed?
Make it so that the server creates a UNIX socket with the same it wants to take, and the client connects to it.
One of those could be an enumeration/activation/etc. server (but not a message router!).
For multicast, do the same and connect to all message broadcasters, using inotify to notice when new ones come up; the publisher just sends to all connected clients.
ZeroMQ can automate most of this, if desired.
The only kernel support that might be needed is support for having unlimited size Unix socket buffers and charging that memory to the receiver, so that the OOM killer/rlimit/etc. kills a non-responsive multicast receiver rather than the sender.
A more sophisticated solution that doesn't duplicate the socket buffer for each subscriber would be even better, but probably doesn't matter for normal usage cases.
Alternatively, get rid of signals, and instead have a key/value store abstraction where you can subscribe to value updates: this way, if the buffer space is full, you can just end an "overflow" packet and the client manually asks for the values of all its watched keys.
(Log in to post comments)
Missing the AF_BUS Posted Jul 12, 2012 5:57 UTC (Thu) by michelp (guest, #44955) [Link]
There is an effort to put ZeroMQ in the kernel as well.
Missing the AF_BUS Posted Jul 12, 2012 6:31 UTC (Thu) by michelp (guest, #44955) [Link]
I guess I should point out it's also going about it by implementing a protocol family similar to AF_BUS. Why can't we have d-bus and more? There are plenty of useful patterns out there and many available protocol family constants. If it's well tested and performant and cleanly coded, then why reject it? Is't that the purpose of having extensible protocol families? It's not like it's going to screw up any existing code.
Missing the AF_BUS Posted Jul 12, 2012 6:57 UTC (Thu) by neilbrown (subscriber, #359) [Link]
Don't under-estimate the maintenance burden of adding more code.
It is true that we seem to add filesystems with gay abandon so maybe a similar case could be added for address families...
The reason that I would avoid adding multiple address families for IPC is that someone would want a mix of features from one and features from another (e.g. multicast and fd passing from AF_INET and AF_UNIX). So would we add yet another one that does both?
Missing the AF_BUS Posted Jul 12, 2012 15:02 UTC (Thu) by michelp (guest, #44955) [Link]
> Don't under-estimate the maintenance burden of adding more code.
Can you give me an example of who is burdened by what exactly in this case?
> The reason that I would avoid adding multiple address families for IPC is
That seems like a speculative reason to reject existing and well established software patterns like d-bus, that are correctly leveraging a well established extension mechanism for adding new protocol families. Again, if it wasn't meant to be extended, then why have protocol families at all? Why was the 'sk is first member of the struct' pattern so well thought out from the beginning? It was done this way to provide ways for the mechanism to grow and evolve.
|
|||||||||||||