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