On Tue, Jul 25, 2017 at 10:46:32AM -0700, Pritish Gandhi wrote:
[...]
> Ah I see! I was assuming a call to access_cb() on a read to completely read
> the value of a characteristic so I was using that to trigger an event which
> would change the value of that characteristic again. I guess that
> assumption is incorrect and I should probably read the MTU of the channel
> and know for sure how many reads would be required before the entire value
> is read.
I do see how it would be useful to know when a characteristic has been
fully read. I don't think there is any good way to know whether a read
is partial or full in the current stack.
Originally, the stack would handle partial reads by asking the
application for the specific portion of the characteristic being read.
If this were still the case, the application would know when the final
portion is being requested. However, it was deemed that this interface
made the application deal with too many details, so we changed it to how
it is today.
It would be a fairly minor change to have the stack indicate:
* the offset being read, and
* the maximum amount of data that the response might include.
The application could ignore this information except in cases like yours
where it needs to know when a characteristic has been fully read.
> Is this true for notifications too? If I need to send notifications for
> that long characteristic value, will my access callback be called several
> times based on the MTU of the connection?
Unfortunately, Bluetooth restricts notifications to a single packet. If
the characteristic value is longer than the MTU allows, the notification
gets truncated. To get around this, the application needs to chunk the
value into several notifications, and possibly use some protocol which
indicates the total length, parts remaining, etc.
> I guess I should handle the case that I cannot negotiate a high enough MTU
> with the peer even though there's a slim chance.
If you have no control over which devices will connect to your
application, then I'm afraid you're right.
Chris
