> On 18 May 2018, at 21:50, Simo Sorce <s...@redhat.com> wrote: > > Sorry Pavel, > but I need to ask, why a new bus instead of somthing like varlink ?
Do you think there is an advantage with varlink over D-Bus as long as we use a private style of communication and use either varlink or D-Bus more or less as a marshalling mechanism? > >>> Now, I'm integrating it into SSSD. The work is quite difficult since it >>> touches all parts of SSSD and the changes are usually interconnected but I'm >>> slowly moving towards the goal [2]. >>> >>> At this moment, I'm trying to take "miminum changes" paths so the code can >>> be built and function with sbus2, however to take full advantage of it, it >>> will take further improvements (that will not be very difficult). >>> >>> There is one big change that I would like to take though, that needs to be >>> discussed. It is about how we currently handle sbus connections. >>> >>> In current state, monitor and each backend creates a private sbus server. >>> The current implementation of a private sbus server is not a message bus, it >>> only serves as an address to create point to point nameless connection. Thus >>> each client must maintain several connections: >>> - each responder is connected to monitor and to all backends >>> - each backend is connected to monitor >>> - we have monitor + number of backends private servers >>> - each private server maintains about 10 active connections >>> >>> This has several disadvantages - there are many connections, we cannot >>> broadcast signals, if a process wants to talk to other process it needs to >>> connect to its server and maintain the connection. Since responders do not >>> currently provider a server, they cannot talk between each other. > > This design has a key advantage, a single process going down does not > affect all other processes communication. How do you recover if the > "switch-board" goes down during message processing with sbus ? FWIW, this is a worry I also expressed to Pavel on the phone the other day. > >>> sbus2 implements proper private message bus. So it can work in the same way >>> as session or system bus. It is a server that maintains the connections, >>> keep tracks of their names and then routes messages from one connection to >>> another. >>> >>> My idea is to have only one sbus server managed by monitor. > > This conflict wth the idea of getting rid of the monitor process, do > not know if this is currently still pursued but it was brought up over > and over many times that we might want to use systemd as the "monitor" > and let socket activation deal with the rest. It’s something we’ve been talking about but never got around to implementing. Additionally, there are users who are running sssd in a container for better or worse and I’m not sure we systemd in a container is something used or stable outside some test builds.. _______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-devel@lists.fedorahosted.org/message/GRJULOCJ3H2KSLCJKQUM3WSBNE7R4LRD/
