Range of handles for my service

[RK]

Is there an easy way to find out the range of handles for a service which I added? Obviously the first one is the service handle, then you add characteristics and descriptors and obviously the last handle is related to the last thing you added, which might be a characteristic which itself adds 4 or more handles.

I can take the last thing I did and figure out what the last handle was, but it's a bit manual and as I change the services during development, I have to remember to keep the code updated. I can't find a function which gives me the range of handles for a given service on my own server, it would be useful.

The motivation is so that I can have each of my service's event handlers explicitly deal with r/w authorization for any of the handles in that service, defaulting to no authorization unless there's specific code for that handle to allow it. To do that I need the range of handles for my service and it would be handy if I didn't have to work it out with custom code.

[Ulrich Myhre]

If you only care about the r/w authorization events, you could use the "context" field of the r/w authorization event to look up the UUIDs/handles of the services/characteristics being written to. Together with stored service handles in each service handler, you can easily look this up.

If not, you will have to store the start and the end handle for each service. You could solve this e.g. by wrapping service_add(). The idea then is that everything between an assigned service handle and the next assigned service handle (minus 1) belongs to the first service. If there are no other services beyond the first, then the end is max (0xFFFE).

Assume initially that the first range is [Undefined, 0xFFFE]. When you add your first service, this range in that service is set to be [assigned handle #1, 0xFFFE]. When you add your second service, the first range will be updated to [assigned handle #1, (assigned handle #2) - 1] and a new service range would be created in the second service between [assigned handle #2, 0xFFFE]. For every new service beyond that, you close the previous range and create a new one.

The range would be a property of each service, and every call to service_add() would need to update the end handle of the previous service. A bit messy, but solvable, and fully automatic.

[RK]

Yes I use the context field to figure out what the auth is for, which ought to be enough, however I was trying to put in some extra protection getting an rw auth request for a field I didn't expect, mostly due to getting my characteristic definitions out of sync with my code but also just as a general good practice. For that you need the range of handles so your my_service_ble_evt_handler() can explicitly send 'failure' for any handle which belongs to the service and it didn't expect.

I ended up wrapping the service add, partly because I'm moving some of my code to C++ anyway and it's a good fit. Doing that I can keep a sneaky pointer to the previous one and update the end handle. I don't love it, but it's good enough for my purposes.

I think a couple of functions which let you iterate your own GATT table might be handy, but probably not worth making the SD larger for.

[Ulrich Myhre]

Yes, I have wanted something like this myself. The stack already has the basic components needed for this to e.g. determine if you are adding a char to a service or not, or to fetch all system attributes for storage. Exposing this functionality in a user-friendly way is not very straight-forward, and it adds very little to the end-product (once all GATT elements are set in stone).

For some test projects I have shadowed every service_add/char_add/etc. with a similar call to a gattdb module which gives me this iterative option, and supports basic filtering like "Print all writable chars" through debug functions. If this is useful for development, maybe the SDK could include something like that in the future.