On Tue, Jul 25, 2017 at 11:14 AM, Christopher Collins <ch...@runtime.io> wrote:
> 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. > My thoughts on this: > a) Ideally, I would be nice if the access_cb() is called once by the stack for each characteristic read no matter how big the MTU is. Considering that, it would be good if the mbuf which is filled in with the full characteristic value is kept around until the entire thing is read (or some timeout OR a different operation begins) and all the underlying reads for each offset are handled by the BLE stack. b) If for some reason (a) doesn't work then (as you suggested) it would be to good pass the offset (maybe make it part of the ctxt) so that the application can decide whether it needs it in order to handle chunking. c) For now I think I'm left with this option so I'll implement it like so. Each call to the access_cb() can check what the current connection's MTU is. Based on that it can decide how many reads are required before it determines that the entire characteristic value has been 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. > That definitely is unfortunate. > > > 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. > Thanks a lot for your responses. -Pritish > > Chris >
