<div class="gmail_quote">On Fri, Aug 20, 2010 at 10:37 AM, Dan Williams <span dir="ltr">&lt;<a href="mailto:dcbw@redhat.com">dcbw@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On Thu, 2010-08-19 at 18:41 -0700, Sam Leffler wrote:<br>
&gt; On Thu, Aug 19, 2010 at 6:10 PM, Witold Sowa &lt;<a href="mailto:witold.sowa@gmail.com">witold.sowa@gmail.com</a>&gt;<br>
&gt; wrote:<br>
&gt;         Sam Leffler pisze:<br>
&gt;<br>
&gt;         &gt; The coalescing of PropertiesChanged signals is great but<br>
&gt;         doing this<br>
&gt;         &gt; for State&#39;s means the client has to infer missing states.<br>
&gt;         &gt;  Unfortunately the way things are implemented it&#39;s not<br>
&gt;         simple to just<br>
&gt;         &gt; flush a pending signal in the lowest level of the dbus code<br>
&gt;         where it&#39;s<br>
&gt;         &gt; easy to recognize this as the state has already been<br>
&gt;         changed.  Any<br>
&gt;         &gt; suggestions on how to handle this?  Or is it expected the<br>
&gt;         client will<br>
&gt;         &gt; just infer all the missing state transitions? (can be hard<br>
&gt;         and lead to<br>
&gt;         &gt; problems)<br>
&gt;         &gt;<br>
&gt;         &gt; -Sam<br>
&gt;         &gt;<br>
&gt;<br>
&gt;         Hi Sam,<br>
&gt;<br>
&gt;         You may look at wpa_dbus_flush_object_changed_properties<br>
&gt;         function in<br>
&gt;         dbus_new_helpers.c. A pending PropertiesChanged signal will be<br>
&gt;         sent<br>
&gt;         immediately when this function is called. We might add it to<br>
&gt;         wpas_notify_state_changed in notify.c so PropertyChanged will<br>
&gt;         be sent<br>
&gt;         immediately every time state changes. Or actually, we could<br>
&gt;         put it into<br>
&gt;         some new function in dbus_new.c like<br>
&gt;         wpas_dbus_signal_state_changed and<br>
&gt;         call if from wpas_notify_state_changed.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Is State always the last property changed when multiple will be<br>
&gt; coalesced?  I don&#39;t think so; in particular CurrentBSS seems to follow<br>
&gt; and I&#39;ve already had to deal w/ handling that out of order on the<br>
&gt; client side (e.g. so the state change is applied to the new bss and<br>
&gt; not the previous).<br>
<br>
</div></div>Yeah, I can see how that would be an issue; but it&#39;s somewhat more<br>
complicated than just moving CurrentBSS before State.  When you<br>
disconnect CurrentBSS should flip to nothing; so you still would need to<br>
cache whatever the old BSS is and then apply the disconnected state to<br>
the cached one?<br>
<br>
The code appears to usually have the pattern of updating the state<br>
before updating the CurrentBSS, except for &quot;associate&quot; paths.  So the<br>
D-Bus interface should be following the same patterns as the control<br>
interface, except for the coalescing.  So maybe we fastpath State,<br>
CurrentBSS, and CurrentNetwork?<br></blockquote><div><br></div><div>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&#39;t hit any noticeable issues and have done a lot of testing.</div>
<div><br></div><div>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&#39;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).</div>
<div><br></div><div>All in all the new api is much better than the old one but it can definitely be improved.  I&#39;ll be attending the wireless summit meeting next week in SF in case other folks want to discuss this in person.</div>
<div><br></div><div>-Sam</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
Dan<br>
</font><div class="im"><br>
&gt; This would be easy if the new state were passed down from above and<br>
&gt; the notify methods called before modifying the global state.  Then you<br>
&gt; could just check the properties changed flags and notice a new state<br>
&gt; value would overwrite an existing state and flush.<br>
&gt;<br>
&gt;<br>
&gt; I&#39;m going to try and handle this on the client side but I believe the<br>
&gt; state change graph is ambiguous so it may not be possible to infer the<br>
&gt; missing states. Not sure if matters; will find out.<br>
&gt;<br>
&gt;<br>
&gt; -Sam<br>
&gt;<br>
&gt;<br>
</div><div><div></div><div class="h5">&gt; _______________________________________________<br>
&gt; HostAP mailing list<br>
&gt; <a href="mailto:HostAP@lists.shmoo.com">HostAP@lists.shmoo.com</a><br>
&gt; <a href="http://lists.shmoo.com/mailman/listinfo/hostap" target="_blank">http://lists.shmoo.com/mailman/listinfo/hostap</a><br>
<br>
<br>
</div></div></blockquote></div><br>