Hi Chris, Thanks a lot for your reply. I do have some follow up questions/comments however.
On Mon, Jul 24, 2017 at 5:37 PM, Christopher Collins <ch...@runtime.io> wrote: > Hi Pritish, > > On Mon, Jul 24, 2017 at 04:25:30PM -0700, Pritish Gandhi wrote: > > Hi All, > > So I'm trying to understand who is responsible for handling chunking the > > characteristic value in case the MTU of the connection is smaller than > the > > characters ic value size. > > > > So for example, if I have a characteristic value of size 100B. When an > iOS > > App connects to my device and reads the characteristic value it gets the > > entire value in a single read. > > It seems like this may be the case because iOS automatically triggers an > > MTU exchange. > > > > However, when the Android App tries to read the characteristic value, > > multiple reads are triggered (5 reads for 20B each). This causes the GATT > > server access_cb() handler to be called 5 times for the "same" > > characteristic read. > > > > My questions are: > > a) Isn't the BLE stack supposed to handle chunking the characteristic > value > > of 100B to 5 x 20B reads and supplying them to the Android App? > > > > b) Does the Application have to save state for each read? check what the > > session MTU is and expect those many callbacks to occur before knowing > that > > the entire characteristic value has been read? > > > > c) Is an MTU exchange required for characteristic values > 20B to work > > correctly? > > > > d) Is it the responsibility of the peripheral or client to initiate the > MTU > > exchange? > > The Read Long Characteristic Values GATT procedure consists of a > sequence of Read Blob Request ATT commands. Each of these commands > specifies the offset to begin the read from. > Thanks! I found the section 4.8.3 Read Long Characteristic Values in the BluetoothCore_v4.2 spec too. > > The NimBLE host does not cache any attribute data after receiving a Read > Blob Request. Instead, the stack asks the application for the full > attribute value for each read request that it receives. The stack > extracts the requested portion of data from the full value and includes > it in its response to the peer. > 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. > So, your characteristic access callback will get called several times > when a peer performs a long read. The correct behavior is for the > application to retrieve the full characteristic value each time. > > 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? > I think this answers the above four questions, but please let me know if > something is missing or unclear. > Thanks very much. > > > e) Is is possible for certain BLE stacks/phones to NOT support increasing > > the MTU? > > Yes, it is possible, though unlikely. The spec only requires devices to > support the default ATT MTU: 23. > 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. Thanks, Pritish > > Chris >
