On 18 May 2018, at 21:50, Simo Sorce <simo(a)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..