BLE Notifications vs. Indications

[dlech]

One thing I have been thinking about that is specific to BLE UART is that we have write with response or write without response in one direction and indicate (with response) or notify (without response) in the other direction. In the with response case, there should be no packets dropped, but throughput will be lower since there is the extra overhead of a response sent for each packet. In the without response case, the transmitter has no way of knowing if the receiver actually received the data and the receiver has no way of knowing if they missed something (unless it is handled at the protocol level).

So I'm thinking we probably want to default to the slower, safer option. But we might want to add an option for the faster lossy option if there are use cases that require high bandwitdh.

Originally posted by @dlech in #262 (comment)

[dlech]

Allowing both Write (with response) and Write Without Response is fairly trivial to implement. Clients generally have ways to choose which method gets called. However, they generally have a single method for enabling notifications that will try to be smart and either enable notifications or indications based on the device properties.

Here are some ideas on how to deal with this:

• Just use notifications. This seems to be what most devices do. Perhaps connections are just "good enough"
• Allow both. If we set the properties to indicate that both are supported, connecting devices will probably enable indications rather than notifications (need to confirm this). We still might be able to send the type that wasn't enabled, but some Bluetooth stacks might not like this.
• Add an extra characteristic for indications. For example, on Nordic UART Service, we could add an additional Rx characteristic that uses indications instead of notifications. Since this would be non-standard though, it would only work with clients we wrote and not generic apps.

Another thing to consider about indications is that it means we will have to handle timeouts in our firmware. BTStack currently has the timeout hard-coded to 30 seconds. This seems way too long. Even with that changed to a shorter value, our current implementation would block all other outgoing Bluetooth messages until the ack was received or it timed out. So it would make our Bluetooth implementation significantly more complex.

[dlech]

lots of good info here: https://interrupt.memfault.com/blog/ble-throughput-primer

TL;DR; is that write with response and indications don't actually guarantee that data isn't lost elsewhere in the stack.

So this probably explains why indications don't actually seem to be used that much. Data still has to be verified at the application layer so using indications would just add extra complexity.