new dbus api coalesces state change

[Sam Leffler]

On Fri, Aug 20, 2010 at 10:37 AM, Dan Williams <dcbw at redhat.com> wrote:

> On Thu, 2010-08-19 at 18:41 -0700, Sam Leffler wrote:
> > On Thu, Aug 19, 2010 at 6:10 PM, Witold Sowa <witold.sowa at gmail.com>
> > wrote:
> >         Sam Leffler pisze:
> >
> >         > The coalescing of PropertiesChanged signals is great but
> >         doing this
> >         > for State's means the client has to infer missing states.
> >         >  Unfortunately the way things are implemented it's not
> >         simple to just
> >         > flush a pending signal in the lowest level of the dbus code
> >         where it's
> >         > easy to recognize this as the state has already been
> >         changed.  Any
> >         > suggestions on how to handle this?  Or is it expected the
> >         client will
> >         > just infer all the missing state transitions? (can be hard
> >         and lead to
> >         > problems)
> >         >
> >         > -Sam
> >         >
> >
> >         Hi Sam,
> >
> >         You may look at wpa_dbus_flush_object_changed_properties
> >         function in
> >         dbus_new_helpers.c. A pending PropertiesChanged signal will be
> >         sent
> >         immediately when this function is called. We might add it to
> >         wpas_notify_state_changed in notify.c so PropertyChanged will
> >         be sent
> >         immediately every time state changes. Or actually, we could
> >         put it into
> >         some new function in dbus_new.c like
> >         wpas_dbus_signal_state_changed and
> >         call if from wpas_notify_state_changed.
> >
> >
> >
> > Is State always the last property changed when multiple will be
> > coalesced?  I don't think so; in particular CurrentBSS seems to follow
> > and I've already had to deal w/ handling that out of order on the
> > client side (e.g. so the state change is applied to the new bss and
> > not the previous).
>
> Yeah, I can see how that would be an issue; but it's somewhat more
> complicated than just moving CurrentBSS before State.  When you
> disconnect CurrentBSS should flip to nothing; so you still would need to
> cache whatever the old BSS is and then apply the disconnected state to
> the cached one?
>
> The code appears to usually have the pattern of updating the state
> before updating the CurrentBSS, except for "associate" paths.  So the
> D-Bus interface should be following the same patterns as the control
> interface, except for the coalescing.  So maybe we fastpath State,
> CurrentBSS, and CurrentNetwork?
>

FWIW I was able to workaround the limitations of the current code by not
using most of the state changes signals except to help in maintaining UI
state.  I depend entirely on the CurrentBSS signal and transition to
COMPLETED+DISCONNECTED states which appear to be reliably delivered.  Not
real happy with this but I haven't hit any noticeable issues and have done a
lot of testing.

It turns out the other tricky area is handling Disconnect.  In some
instances there is no notification from supplicant for an explicit
Disconnect request.  To workaround that I've had to more carefully maintain
client-side state and do client-side state changes immediately (before
sending a request to supplicant).  This is especially tricky when
synchronizing state around connect/disconnect (e.g. disconnect old network
and immediately connect to new network).

All in all the new api is much better than the old one but it can definitely
be improved.  I'll be attending the wireless summit meeting next week in SF
in case other folks want to discuss this in person.

-Sam


> Dan
>
> > This would be easy if the new state were passed down from above and
> > the notify methods called before modifying the global state.  Then you
> > could just check the properties changed flags and notice a new state
> > value would overwrite an existing state and flush.
> >
> >
> > I'm going to try and handle this on the client side but I believe the
> > state change graph is ambiguous so it may not be possible to infer the
> > missing states. Not sure if matters; will find out.
> >
> >
> > -Sam
> >
> >
> > _______________________________________________
> > HostAP mailing list
> > HostAP at lists.shmoo.com
> > http://lists.shmoo.com/mailman/listinfo/hostap
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20100903/ef10be65/attachment.htm