On Fri, Jul 15, 2016 at 06:06:37PM +0200, Kevin Townsend wrote:
> > This is currently hidden from the application. If any GATT procedure
> > times out, the host terminates the connection. So, if the connection
> > stays up, that implies the indicate acknowledgement has been received.
> That seems a bit drastic! If we are operating at the edge of the radio
> range, or maybe if there's just a one-off error with the indicate
> response, I wouldn't have expected an automatic disconnect myself. I can
> understand handling the indicate internally if that simplifies things,
> making any write attempts to an indicate characteristic a blocking call
> until the response is received or we timeout, but then just return
> 'false' or an appropriate error and let the user decide if they want to
> try again, disconnect, ignore the problem, etc.
>
> Disconnecting on a simple indicate failure really seems like overkill to
> me, though, but perhaps I'm missing some use case or requirement in the
> core spec here. I haven't read through it in detail since 4.0 and then
> a re-read a bit with the 4.1 release, but unfortunately I'm a lot more
> familiar with the older 4.0 spec.
The BLE link layer is a reliable protocol, and the upper layers are
specified to assume a lossless connection. I view this as similar to
TCP: if a response is never received, something is wrong with the
connection, and terminating it is probably the only reasonable option.
This is a bit more drastic than what the spec requires (4.2, Vol. 3,
Part F, 3.3.3, "Transaction"):
A transaction not completed within 30 seconds shall time out. Such a
transaction shall be considered to have failed and the local higher
layers shall be informed of this failure. No more attribute protocol
requests, commands, indications or notifications shall be sent to
the target device on this ATT Bearer.
So, the connection need not be terminated, but you can't do much else
with it after a timeout occurs. From what I have seen, other
implementations terminate the connection when an ATT transaction times
out, though I am not sure what the Nordic soft device does in this case.
>From the standpoint of pure laziness, it is easier and requires less
code to terminate the connection than to maintain it in a "zombie
state."
That said, I don't particularly like the idea of terminating a
connection behind the application's back, but I don't know that an
application would do anything other than terminate the connection itself
under these conditions. This is just me speculating, though... perhaps
there is a very good use case for keeping the connection up.
Thanks,
Chris
