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

[Grant Erickson]

On 10/22/11 1:25 PM, Sam Leffler wrote:
> On Fri, Oct 21, 2011 at 5:22 PM, Grant Erickson <marathon96 at gmail.com> wrote:
>> Per thread:
>> 
>> ? ? ? ?http://lists.shmoo.com/pipermail/hostap/2011-October/024363.html
>> 
>> the supplicant property coalescing and queueing logic break network
>> managers such as connman or flimflam in subtle and often random ways.
>> 
>> This set of patches provides a priority, fast-track path for the State
>> property that avoids queuing and dispatching it as with other
>> properites to ensure that higher-level network managers see all
>> supplicant state changes.
> 
> NAK. flimflam is not affected by the coalescing state change signals
> and the coalescing effectively reduces traffic over the dbus.

In the common case for BSSs, etc. I can see where coalescing seems like a
reasonable approach and the submitted patch leaves all of those properties
as-is--they remained coalesced.

For state changes (i.e. the "State" property), I cannot see where coalescing
makes any measure of sense. State changes don't strike me as frequent enough
or high bandwidth enough where losing the information contained therein is a
trade-off worth making.

> If you want to add something to inhibit coalescing please have the client
> explicitly enable it.  Otherwise you may care to look at how flimflam
> handles things.

I've looked at it and I felt that it is sufficiently divergent from
connman-0.77 where an adoption of that approach didn't make sense as a point
of remediation.

That said, the deficiency lies in the supplicant not network managers such
as connman and flimflam and the supplicant is where this deficiency should
be corrected.

Best,

Grant