Great job Virendra. And what the throughput you achieved? Richard, I do not expect to see out of order messages. Nevertheless a seq number will allow the receiver to give back a Nak with the seq number of the missed/corrupted message it refers to, in such a way the sender can decide to retransmit. Robert, the COBS is very good stuff. Due to the fact the stuff()/unstuff() functions are pretty compact and localized, I could easily test both the COBS and the ESC methods with few effort. Now it's time to write down the specs. Sent using OWA for iPhone ________________________________________ From: Virendra Shakya <virendra@skully.com> Sent: Friday, January 29, 2016 8:01:18 PM To: Richard A. Smith Cc: Gabriele Filosofi; robert carlsen; bluetooth-dev@lists.apple.com Subject: Re: R: Designing a communication protocol In one of my apps that involved ble, I had designed a very simple protocol: - only one characteristic used - write - the central writes n bytes on this characteristic- with start byte and end byte - the sender puts all the packets in a queue (so I didn't need sequence number) - the receiver will assemble the packet back - again putting all the fragments in a queue and then re-assembling once an end byte is encountered It worked perfectly in my case. :) Sent from my iPhone

On Jan 29, 2016, at 10:09 AM, Richard A. Smith <smith@whoop.com> wrote:

...

On 01/29/2016 12:24 PM, Gabriele Filosofi wrote:

d) A sequence number in each message. How could I effectively exploit such a feature ?

If you can have out of order messages and need re-assembly then you use the sequence number.

In some fully asynchronous protocols I've done there are multiple commands outstanding the sequence number is used to link the command response back to the original command.

But the main use for me has been while doing protocol debugging. Gaps in the sequence numbers indicate bad things.

-- Richard A. Smith smith@whoop.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/virendra%40skully.com

This email sent to virendra@skully.com

_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.... This email sent to site_archiver@lists.apple.com