Service re-discovery

[Jeffrey Yasskin]

Hi Luiz,

I'd like to move the discussion from https://github.com/thegecko/web-bluetooth-dfu/issues/12#issuecomment-195321652 onto a more dedicated thread, so we don't get in the DFU folks' way.

With the Web Bluetooth API, we're trying to present a single model to all web pages, and ideally that model should match the specified Bluetooth model. IIUC, Bluetooth (4.2 3.G.2.5.2) specifies that "For clients that have a trusted relationship (i.e. bond) with the server, the attribute cache is valid across connections. … For clients that do not have a trusted relationship with the server, the attribute cache is valid only during the connection." We haven't fully decided if a website granted access to a device should appear to be bonded to that device, or if we should expose the underlying platform's bonded status, and make websites adapt to it. If the website appears to be bonded, then we'd expect it to wait for service-changed events before using the device after a re-connection. If the website doesn't appear to be bonded, then the getPrimaryService() would need to appear to re-discover services and not return until enough discovery has finished to ensure the requested service still exists. I'm not sure which is better.

Re "I wonder how it would be possible to access discovered services before full discovery", the Web Bluetooth JS API does allow the implementation to only partially discover services before handing them back to JS. For example, getPrimaryService() can use Discover Primary Service by Service UUID instead of Discover All Primary Services, and because getCharacteristic() is also asynchronous the implementation can delay Characteristic Discovery until the characteristics are actually needed. That said, on platforms that don't have APIs to request such partial discovery, like Android and BlueZ, we just do a full discovery on connect(), which satisfies the needed semantics.

Jeffrey

P.S. If you're going to be at Bluetooth World, we should meet up.

[Jeffrey Yasskin]

Also, we really appreciate your help with the BlueZ implementation and your interest in making sure Web Bluetooth works. Thank you.

[luiz....@gmail.com]

Hi Jeffrey,

We are aware of the trusted relationship, but BlueZ employed a more sophisticate detection since it does check if services are in the same range every time the device is reconnected, this is considerable faster since it is just about 1 Read by Group Type command and if nothing has changed the discover stop right there: http://www.spinics.net/lists/linux-bluetooth/msg62362.html

*This was actually done in order to deal with devices that loose track of service changed configuration once their batteries are removed.

Regarding the actual problem, Im actually working on having proper notification of the cache refresh, but apparently there is already an API to deal with service updates which would probably solve the problem have it been used. My last response was actually about that since the application does have knowledge that the database will change it could actually wait for the events to come in instead of pool services again with getPrimaryService.

[Jeffrey Yasskin]

I'm curious how you deal with characteristics that appear or disappear within an existing service range. But anyway, it sounds like you're suggesting that we should have Web Bluetooth emulate a bond between a website and a device, even if there's no underlying Bluetooth bond. That seems like a reasonable option. I'll bring it up on the specification list.

I believe we can do either using the Discovering property you were proposing to add. Without that, I don't think we can expose a non-bonded state, but we could emulate bonding.

The service-changed events aren't implemented in Chromium yet, but that's an implementation detail, not a problem with the underlying BlueZ API.

Thanks,

Jeffrey

[Luiz Augusto von Dentz]

Hi Jeffrey,

Characteristics changing in a way that the handles range wouldn't
change is probably near impossible right now, service normally are
register and unregistered including all attributes in most systems
since the service handles needs to be continuous when you discover
them. Also service definitions are normally static, have been since
classic, which is perhaps the reason service changed shall carry the
start and end handle of the entire service as it doesn't expect
internal changes to service as it would things a lot more complicated.

Regarding the bond, I don't think we need to add anything actually, in
BlueZ the cache is not really tied to the bonding information and wont
be loaded until the device is connected again. That being said perhaps
you are talking about a feature of remembering devices even if is not
paired/bonded, I wouldn't call this a bond because that is different
than what the spec suggest, so that perhaps don't have to be exposed.
From what I could test with chrome 50 under Linux it does appear to
get the list of devices from BlueZ regardless if they were bonded or
not which I find it great.

Regarding the service-changed events, I remember seems them handled in
the bottom layer at least, it is actually used to build the list of
services in case of getPrimaryService, etc. So perhaps it is just a
matter to forwarding them to the application somehow, but perhaps you
only want to do that if is actually a UUID the application is
interested.

--
Luiz Augusto von Dentz

[François Beaufort 🇫🇷]

http://git.kernel.org/cgit/bluetooth/bluez.git/commit/?id=4ed99044f49af9ef21c89b283399112cddfe68c0 (Replace GattServices with ServicesDiscovered property) has been applied upstream. Thank you Luiz!

Is this enough for the Web Bluetooth team to implement a reliable Service discovery?

--
You received this message because you are subscribed to the Google Groups "web-bluetooth" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-bluetoot...@chromium.org.
To post to this group, send email to web-bl...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/web-bluetooth/CABBYNZKG2ZEVig4wQzGJMDE47sWnFLM1%3Ds_kTiLtvpLMA0ouwQ%40mail.gmail.com.

[Von Dentz, Luiz]

Hi François,

Let me know if you find anything wrong, btw can you notify us when you
are done including support for ServiceDiscovered? Or perhaps it makes
more sense I just clone the upstream chromium tree and wait until it
is integrated there. Btw, do you know if there exists any
implementation of an attribute explorer with the Web Bluetooth API?

[François Beaufort 🇫🇷]

I will definitely send you an update when this gets merged into https://chromium.googlesource.com/chromiumos/third_party/bluez/+/master

It will be doable to some extents to find characteristics/descriptor with service.getCharacteristics, service.getIncludedServices, characteristic.getDescriptors.

However since we require developer to define ahead of time all service UUIDs that can be accessed, it won't be as powerful as the nRF Master Control Panel Android App for instance.

[Luiz Augusto von Dentz]

Hi François,

Hold on with the integration since I discovered a problem with the
order where ServicesResolved wont actually be the last to trigger
which may give the upper layer the wrong impression that the discovery
is complete when in fact there still some objects to appear.

I think I have a fix for that, but there one detail I want to get
sorted as well:

signal time=1458046687.767355 sender=:1.1745 -> destination=(null
destination) serial=222 path=/org/bluez/hci0/dev_...;
interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
string "org.bluez.Device1"
array [
dict entry(
string "ServicesResolved"
variant boolean true
)
]
array [
]
signal time=1458046687.825368 sender=:1.1745 -> destination=(null
destination) serial=223
path=/org/bluez/hci0/dev_.../service001b/char0021;
interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
string "org.bluez.GattCharacteristic1"
array [
dict entry(
string "Flags"
variant array [
string "read"
string "write"
string "extended-properties"
string "reliable-write"
]
)
]
array [
]

This happens because there a read for the extended properties after
the discovery, given the timestamps I don't think it would be a
problem since characteristics is a different method call in the Web
Bluetooth API but then we need to take care of the following code:
(https://code.google.com/p/chromium/codesearch#chromium/src/device/bluetooth/bluetooth_remote_gatt_service_bluez.cc&sq=package:chromium&rcl=1458027245&l=242)
if (property_name != properties->characteristics.name()) {
NotifyServiceChanged();
return;
}

if (discovery_complete_)
return;

VLOG(1) << "All characteristics were discovered for service: "
<< object_path.value();
discovery_complete_ = true;
DCHECK(adapter_);
adapter_->NotifyGattDiscoveryComplete(this);

I actually would like to get rid of Characteristics and Descriptors
properties, so this code should probably be removed in favor of using
ServicesResolved, if we find out the read is too slow we may have to
incorporate it to the discovery procedure to guarantee it happens
before ServicesResolved.

[François Beaufort 🇫🇷]

Hello Luiz,

I believe the last part was fixed in Bluez 5.38.

Can you confirm?

Moreover, does Chrome has to be updated to reflect these changes?

http://git.kernel.org/cgit/bluetooth/bluez.git/commit/?id=bfec482d7aade2fd263c5981bca0b779955a87ab

http://git.kernel.org/cgit/bluetooth/bluez.git/commit/?id=2f3c4b2ff2dcd087ae328efdc86b35234a4ed25e

[Luiz Augusto von Dentz]

Hi François,

On Thu, Mar 31, 2016 at 4:04 PM, François Beaufort 🇫🇷
<fbea...@google.com> wrote:
> Hello Luiz,
>
> I believe the last part was fixed in Bluez 5.38.
> Can you confirm?
>
> Moreover, does Chrome has to be updated to reflect these changes?
> http://git.kernel.org/cgit/bluetooth/bluez.git/commit/?id=bfec482d7aade2fd263c5981bca0b779955a87ab
> http://git.kernel.org/cgit/bluetooth/bluez.git/commit/?id=2f3c4b2ff2dcd087ae328efdc86b35234a4ed25e

Yes those 2 patches should solve that problem, but 5.38 has a
regression when connecting to A2DP headset which cause bluetoothd to
crash so I would recommend waiting for 5.39 that should be release
quite soon.

[François Beaufort 🇫🇷]

Thank you, we will wait for 5.39.

In the mean time, can you confirm the "only" change we have to do in Chrome is to replace "GattServices" property with the brand new "ServicesResolved" property?

[Luiz Augusto von Dentz]

Hi François,

Yes, to be more precise the following code needs to be changed:

if (property_name == properties->gatt_services.name()) {
device_bluez->SetGattServicesDiscoveryComplete(true);
NotifyGattServicesDiscovered(device_bluez);
}

Id actually should be able to contribute with some code once Im done
with the CLA, etc.

On Thu, Mar 31, 2016 at 4:12 PM, François Beaufort 🇫🇷

[François Beaufort 🇫🇷]

Please let me know when you're done with the CLA and everything.

I'd love to see you contribute to the open-source Chromium projects.

Here's a beginning of a patch that you might find useful when starting to work on this: https://codereview.chromium.org/1847823002

[François Beaufort 🇫🇷]

For info, I've filed https://bugs.chromium.org/p/chromium/issues/detail?id=599472 to keep track of this.