Hi folks,
I sent a mail about new sbus implementation (I'll refer to it as sbus2)
[1]. 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.
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. Other
processes will connect to this server with a named connection (e.g.
sssd.nss, sssd.backend.dom1, sssd.backend.dom2). We can then send
message to this message bus (only one connection) and set destination to
name (e.g. sssd.nss to invalidate memcache). We can also send signals to
this bus and it will broadcast it to all connections that listens to
this signals. So, it is proper way how to do it. It will simplify things
and allow us to send signals and have better IPC in general.
I know we want to eventually get rid of the monitor, the process would
stay as an sbus server. It would become a single point of failure, but
the process can be restarted automatically by systemd in case of crash.
Also here is a bonus question - do any of you remember why we use
private server at all? Why don't we connect to system message bus? I do
not see any benefit in having a private server.
[1] https://github.com/pbrezina/sbus
[2] https://github.com/pbrezina/sssd/tree/sbus
_______________________________________________
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/Z7ZSIEX7QAAZAUGCVNLTYDAYEUHOQHY6/
