[PATCH 0/2] dbus: Do Not Coalesce State Changed Signals

[Dan Williams]

On Mon, 2011-10-24 at 18:26 +0300, Jouni Malinen wrote:
> On Mon, Oct 24, 2011 at 10:05:04AM -0500, Dan Williams wrote:
> > I used to have a problem with this, but I now see where it makes sense
> > for the State property alone.  Most properties *should* be coalesced to
> > reduce dbus traffic, but the State property should probably just trigger
> > an immediate emit of the interface's changed properties.  State doesn't
> > change that often so it wouldn't meaningfully increase D-Bus traffic.
> 
> What exactly are these state changes used for? The main problem I see
> with this is that wpa_s->wpa_state is supposed to be internal data for
> wpa_supplicant and the values it has and the way they are used are
> subject to change whenever needed.. As such, I would really not want any
> external functional to depends on that for anything beyond maybe showing
> some debug information.

NM uses it to determine what state the supplicant is in, obviously.  If
the supplicant is scanning, then we don't want to do certain operations.
If the supplicant is connecting, there are other operations we don't
want to do (like request a scan).

If the supplicant fails during association/authentication, then the
connection manager wants to know that, because that could indicate
specific failures: a failure during 4-way handshake usually indicates
that a password is incorrect, and that's very useful information to a
connection manager.

Obviously we want notification of disconnection events so that in NM we
can start a timer for overall connection failure and after a certain
period of retries, terminate the attempt and look for a different AP.

We need to know, after adding an interface, whether that interface is
now ready for action or not.  When the interface enters state COMPLETED,
we need to know to start IP configuration.  When the interface is DOWN
we need to know to clean stuff up and forget about the interface.  If
the interface is AUTHENTICATED and we're waiting for an EAP identity or
password, then when the interface transitions to DISCONNECTED we need to
know that we should stop waiting for user input.

All sorts of stuff :)

> There are already some horrible hacks in place for wpa_state (just see
> how WPA_IDLE is generated in Android builds) and I really do not want to
> have to consider supporting something like that with the D-Bus
> interface.

Well, it's extremely useful to have something like this, as opposed to a
plethora of signals for other stuff.  Having one state signal for an
interface means one centralized place that client code can perform
actions based on what's happening in the supplicant.  If not state
signals then I'm not sure what we'd use, but hopefully it's not a
combination of other signals since those arrive asynchronously and thus
are harder to handle.

> If there is desire to actually use this type of information for taking
> some actions, it would be much safer to define a new value that will be
> generated based on internal state (including wpa_s->wpa_state) and
> define that in a way that makes it easier to maintain this in a stable
> way even if the internal implementation changes.

That's fine with me, we could simply keep the same state values and just
change how the D-Bus property value is calculated.  But having a
notification of supplicant interface state is really, really useful.

Dan