GATTS long reads behavior
- Dominant language
- C
- Stars
- 893
- Forks
- 512
- Avg merge
- 13d 31m
- Merged PRs (30d)
- 7
Description
In general, I like that NimBLE tries to hide the complexity of long reads and writes from the user, automatically servicing them within the stack, it's a welcome change from Bluedroid that spills all this onto the user of the API and expects the user to deal with all the complications.
However, currently observed behavior for long reads is that NimBLE will repeatedly request the value from the attribute callback while responding to central's requests and sending MTU chunks at a time (at least i suspect that's what's happening). However, if the value of the characteristic happens to change between reads, incorrect value will be returned to the client. As far as i can tell, there is current;y no way for the API user to tell if a particular BLE_GATT_ACCESS_OP_READ_CHR is part of the same long read or not - for example, read offset is not provided to the user, so user application cannot work this around either.
IMO, NimBLE should buffer the long response and serve long reads from internally buffered copy of the response and not rely on the value staying the same.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.