Combining long reads

[schlaegerz]

Awesome work on this package.

I am working on implementing BLE for the first time in my project and I'm curious if there is suggested way to deal with "long" reads/writes.

BLE seems to support reads and writes up to 500, but I'm just curious what part o the app should be handling the combining of it into the packets.

If I do a longer read from an phone I notice that it calls onRead repeatedly until it reads the full thing. In some cases I end up updating the value it is reading before it is completely done.

My question for that, is it possible in the onRead callback to see if it is part of an ongoing call so I can make sure that it is not updated in the middle of reading.

Similarly for the onWrite, if I write a large packet from a phone, I just see a bunch of small parts of the whole packet written individually. I could figure out what to do if there was some way just to tell if it is the end of the packet or not.

I can figure out some custom solutions for these problems, but before I spend the time doing that, I was just curious if there are parts of the api I am missing, or if there are more things that need to be implemented before this package is complete.

[h2zero]

Hi, thanks for testing it out 😃 .

Long reads and writes will be implemented shortly, I have the test code in place currently in the bugfix branch, although commented out for now. It needs more work as NimBLE doesn't really provide a great way to detect when a long write or write is in progress so I need to stumble through the source code a bit more. With luck it won't be too much longer.

[chegewara]

I dont know NimBLE, but here is how long read is solved in old library (its in bluetooth specs):
https://github.com/nkolban/esp32-snippets/blob/master/cpp_utils/BLECharacteristic.cpp#L373

IIRC long write is handled by WRITE_EVT and param->write.is_prep, and finally by EXEC_WRITE_EVT (im not sure about last event).

PS i am wondering if its required to write long read/write code or its maybe handled internally by NimBLE

[h2zero]

@chegewara Thanks for the link, sadly it doesn't seem NimBLE provides any sort of indication flag for long read/write.

The best I can do it seems is compare the data size with the mtu the check the packet header length that may give an indication if this is an initial read or followup. I think it does handle the offset internally though so hopefully that won't need to be managed.

[schlaegerz]

I figured out I could fix my case by negotiating a higher mtu from the client side.

I'm not sure if that should be the standard way to do it or if the package should somehow combine it.

[h2zero]

Long reads and writes are sub-optimal, they consume a lot of time. It's much better to use the biggest MTU size you can handle.

That said, I have sorted out the long read/write situation in the server code and just now pushed the update to the bugfix branch if you want to check it out.