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. 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. 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. I think this answers the above four questions, but please let me know if something is missing or unclear. > 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. Chris
