Hi Brian, On 12/18, Gix, Brian wrote: > Maybe we should start with what you actually need. > * Do you need GATT support only for the Provisioning procedure? Primarily, but not only this. As Danielle mentioned, there are cases where we would like to "fall back" to GATT in order to exchange large amounts of data with a selected node. This is going to happen only occassionally, so it won't affect the "steady state" performance of a mesh network. Spec even mentions that particular use case, via Node Identity procedure. > * or also as a GATT proxy Server? No, at the moment we don't need GATT Proxy Server support in Linux, althouth long-term I think it would be beneficial for bluez to have this. > * I do not think we should try to support Proxy Client *at all*. Agreed. > The Proxy Client assumes a single Node, which defeats the purpose of > having a daemon at all. > > * Only a single node (or unprovisioned GATT server) can use GATT at a > time. The protocol does not allow for the multi-node architecture of > the daemon. I do not think this is true. The spec doesn't seem to put any limitations on the Network PDUs you can exchange with the GATT Proxy Server, so I think it is entirely possible to have multiple Mesh nodes share a single GATT connection to a proxy. Noone does that, though, because performance of such a setup would probably be abysmal :) In the end, I don't consider this a "real" use case. > * If we do try to put a GATT Proxy Server on a single controller > implementation, we may need a special node that loops back data > received from the Mesh to the Gatt Client. Well, I was wondering if it would be feasible to implement another flavour of mesh-io layer, that would talk to Bluetooth Daemon (possibly via API extensions) instead of opening the hci user channel on its own. For that to work, the main Bluetooth Daemon would need to expose D-Bus signals to retrieve "raw" advertising indications, and a method to send a single advertising packet. Alternatively (and this is just me thinking out loud), maybe it would be possible to dup() the HCI socket and pass it to the Mesh Daemon, assuming it gets spawneby by fork()ing Bluetooth Daemon? Not sure if the kernel interface allows such sheganigans. > * We may want to make this a build-time option, because ADV handling > will probably be affected whether an existing GATT connection is > established or not, if it is possible that a GATT connection could be > requested. > > * This affects the times when we can use Randomized, ever changing BD > ADDRs, and requires us to interleave connectable advertisements and > "be connectable", which is not technically allowed with mesh network > ADV packets. In our experience, /just enabling/ Proxy Server on a node (thus making it advertise with connectables) does not seem affect delivery rate of mesh packets, at least not meaningfully (0.1%, maybe). The performance drop is observable only after an actual connection is established, and is in 10-20% range, if I recall correctly. regards -- Michał Lowas-Rzechonek <michal.lowas-rzechonek@xxxxxxxxxxx> Silvair http://silvair.com Jasnogórska 44, 31-358 Krakow, POLAND
