Problem with BSS properties

[Marcel Holtmann]

Hi Witold,

> >> If we really want a complete D-Bus interface, we *have* to keep both old
> >> + new around to take a difference between the two and push out the
> >> PropertiesChanged signal.  I don't really know what Jouni will think
> >> about that, but I don't see any other way to get a complete change list
> >> (including IEs, which are the major memory user).
> >>
> >> While IEs are nice to have, if Jouni is really concerned about memory
> >> usage we can ignore IE changes for now and just do limited set of
> >> properties.  But eventually I think we pretty much need everything.
> > 
> > This really has to be a configurable option, i.e., wpa_supplicant will
> > need to work without requiring there to be two copies of full scan
> > results in memory. I haven't checked D-Bus resource requirements in
> > general, but unless shown otherwise, I would assume it can be used in
> > relatively low-powered devices, too, and it could also be useful to have
> > an option to disable the scan results PropertiesChanged signal while
> > still leaving in some other parts of D-Bus code.
> > 
> > Of course this does not apply to any of the modern laptop/desktop
> > systems where 200 kB of memory is not really anything and as such, I
> > have nothing against wpa_supplicant doing the comparisons in general as
> > long as it does not break some of the other cases where wpa_supplicant
> > is used.
> > 
> So lets add a config option to enable this comparison and add a comment
> saying that is useful feature but pose a risk of additional 200kB memory
> usage.

since the PropertiesChanged signal is defined to contain the whole set
of properties, we could just simply send that with all properties when
we get a BSS result that we already know about. This will not increase
the memory usage.

The downside is that we would send signals for every BSS result now, but
in the end we would be doing that anyway to some level since the signal
strength is changing almost on every scan. The few BSS results where it
stays the same can be probably ignored.

Problem now is that the client doesn't know what changed and has to do
the comparison. It would be great to avoid that.

Since we really only handle like four IEs anyway, it might be better to
just hold a copy of these. If I count correctly we have SSID, WPA, RSN
and WPA elements we export. So if we just copy these, then we should be
good.

Alternatively we could just hash them and only store the hash value. So
we can do a comparison via hash values.

Maybe some hybrid way of handling capabilities and signal strength
changes manually so that these changes are clearly distinguishable. And
then just use one hash for all IE values.

Regards

Marcel