Apple

From my experience / testing:
- There is an outbound queue. When I tested, I used iOS 8.1. If I would
flood the queue, I would start seeing dropped writes w/o responses after
~20 packets of 155 bytes payload (158 including the ATT header). I have not
tried using smaller payloads, so not sure if the queue is bound by number
of bytes or by number of packets.
- That said, there is no API to let the app know when the queue is full
(that's my bug report about
http://www.openradar.me/radar?id=5845858713075712). It's unfortunate,
because many stacks / APIs do provide this (Android for one). I think the
spec describes Write w/o Response is unreliable, but IMO it's kind of silly
if it's possible to detect when your local queue is about to overflow, to
not provide a API for it... Especially since at the lower layers automatic
retransmits and error checking is happening...
- Instead of a timed approach, I'm using a "number of packets in flight"
counter (sliding window). I think the timed approach is tricky. This
implies you'll need to do (async) acking. I've seen iOS devices (as master)
start a connection at intervals between 15ms and 30ms.
- If you're going for throughput, negotiate a bigger (G)ATT MTU (search for
MTU Exchange in the spec doc). Not all stacks can though it unfortunately
(I heard that Nordic's can't at the moment).
- For throughput you also want to avoid "draining the pipe". This means you
need to make sure there are always packets queue'd up, so the connection
events can be stuffed as much as possible. Using a sniffer you can check
how you're doing on this front.

Using these thing, I've been able to get up to 13Kbytes/s throughput ("one
way at a time").

Martijn

Pebble: E-Paper Watch for iPhone and Android
http://www.getpebble.com
Tel: +1 (650) 308-9383

_______________________________________________
Bluetooth-dev mailing list
email@hidden
https://lists.apple.com/mailman/listinfo/bluetooth-dev

End of Bluetooth-dev Digest, Vol 12, Issue 50
*********************************************