-
Notifications
You must be signed in to change notification settings - Fork 406
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Offset field in struct ble_gatt_access_ctxt as an indication of long attribute read #1846
Conversation
I've also made some changes to other parts of the code (only code style without change in functionality). <- Moved to other PRs. And provided some points to consider with |
Right now the nimble stack takes all attribute data from an application and truncates it to be the size of MTU (actually MTU - 1). E.g. attribute length is 500 bytes, MTU is 23 bytes. So the application copies 500 bytes to the provided mbuf, and then nimble stack copies only 22 bytes according to an offset. I think it would be nice to allow the application callback to provide only part of the data (as it already knows the offset and could obtain mtu length information). What do you think? @sjanc |
code style fixes should be at least in separate commit, but preferably in separate PR |
46bdca9
to
0e99d0e
Compare
@andrzej-kaczmarek, I've split this PR into 3: #1847 and #1848. But left |
you can make separate PR for other changes so we can discuss them. |
0e99d0e
to
77244b7
Compare
Done, left only changes related to the offset. |
Hi, Code looks OK to me, thanks! But could you amend commit message to follow project style? eg
|
77244b7
to
5c200fc
Compare
Amended the commit message. Also, moved issues to discuss into #1849. |
@sjanc, would you merge the PR? |
This allows application to easily determine if client is performing GATT Long Read operation.
5c200fc
to
019c6e2
Compare
@andrzej-kaczmarek, can we merge now? |
To obtain an attribute value when the attribute size is greater than configured MTU long attribute read procedure could be used.
A client sends consecutive
ATT_READ_BLOB_REQ
requests (passing along an offset) to consume the attribute value. The offset is used internally in the nimble stack but is not passed to a user provided access callback in a GATT characteristic description. This callback is called the same number of times as the number of blob requests, but it's not possible to say whether it's a first request (or maybe justATT_READ_REQ
) or consecutive request.The provided offset could indicate this situation to the app developer. However, Core Spec 5.4 Vol 3 Part F 3.4.4.5 notes:
It's up to a developer to decide what to do, when consecutive (long attribute) reading takes place. This was discussed in #1090.