Hi Simon, On Thu, Mar 08, 2018 at 12:18:41AM -0800, Simon Ratner wrote: > Old thread, but I just bumped into this myself so want to resurrect it. > > Current api makes it very difficult to implement a long characteristic that > changes frequently (e.g. time- or sensor-based reading, or including a > random component). In the case where mtu exchange fails or does not > complete in time, the client may receive a mashup of two or more different > values, if access_cb returns a current value each time. For example, a > 32-byte value might end up as 22 bytes from sample 0 plus 10 bytes from > sample 1 -- a combination that does not decode to a valid reading. One way > around this is to lock in a stable sample for each connection, but that > becomes harder to keep track of with many concurrent connections.
If you expect all clients to support a reasonable MTU, you might just punt on the problem: if you can't fit the characteristic value in a single response, send some sort of "characteristic not ready" response instead. You can determine the connection's MTU by calling `ble_att_mtu()`. This doesn't solve the general problem, of course. > I don't really have a solution yet, just complaining ;) Perhaps nimble > holding on to the value for subsequent offset reads makes sense after all. > I guess the difficulty there is knowing when to free it? That seems like a good solution. Regarding how long to hold onto the cached value, well, that's what syscfg is for :). I thought of an alternative that won't actually work, but I'll share it anyway: allow the application to associate a minimum MTU with each characteristic. If a peer attempts to read the characteristic over a connection with an MTU that is too low, the stack initiates an MTU exchange procedure, and only responds to the read request after the MTU has increased. Unfortunately, this doesn't work because changes in the MTU don't apply to transactions that are already in progress. Chris > > Cheers, > simon > > > On Tue, Jul 25, 2017 at 12:19 PM, Andrzej Kaczmarek < > andrzej.kaczma...@codecoup.pl> wrote: > > > Hi, > > > > > > On Tue, Jul 25, 2017 at 8:14 PM, Christopher Collins <ch...@runtime.io> > > wrote: > > > > > On Tue, Jul 25, 2017 at 10:46:32AM -0700, Pritish Gandhi wrote: > > > [...] > > > > > [...] > > > > > > > > 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. > > > > > > > Also client can just do long read in order to read remaining portion of > > characteristic value > > > > - this is what ATT spec suggests. > > It depends on actual use case, but this way client may be able to decide > > whether it should read remaining portion of value or skip it, e.g. some > > flags can be placed at the beginning of the characteristic value and they > > will be always sent in notification. > > > > Best regards, > > Andrzej > >
