Hi Chris,
I think I mischaracterized my opinion here, so let me try again.
I think the stack should make as few decisions as possible. Decision
making should be delegated to the application and to supplementary
libraries. So, ideally, the stack would not terminate a connection in
the case of an ATT timeout; it would put the connection in a "zombie"
state and let the application close the connection.
I can think of two reasons why the stack my keep its current,
less-than-ideal, behavior for the time being (again, all just my
opinion):
1. The extra code needed to implement the zombie state may not be worth
it (this requires some investigation, though).
2. There are more important things that still need to be implemented.
I don't think the disconnect is a massive issue at this point and worth
a lot of effort. There are higher priorities as you said, which gets a
+1 from me anyway, and it isn't entirely unreasonable based on the spec
(thanks for the reference!).
I think the following are probably worth the effort, though:
1. Getting CCCD update events into a callback (important for power
management)
2. Alerting users of an indicate failure
A disconnect might seem valid for #2, but I would argue that this then
removes all of the value of indicate even existing!
Even if a failure does cause an eventual disconnect (up to 30s later!),
we still have no way to know if the cause of that failure was the lack
of an indicate response, or ... something else (power failure on the
Central, etc.). Indicate significantly slows data throughput down in
BLE, but is the only means to have genuinely reliable transactions where
we can recover later, which is important transferring binary files or
other similar information. We should always know if an indicate write
passed or failed in my opinion, and tracking disconnect might be a good
indicator but isn't 100% reliable.
I'd of course be curious to hear other people's opinions on this!
K.
