Partial flashing protocol prone to deadlock

lancaster-university / microbit-dal

http://lancaster-university.github.io/microbit-docs

Other

256 stars 130 forks source link

Partial flashing protocol prone to deadlock #397

Open pelikhan opened 5 years ago

pelikhan commented 5 years ago

Transferring a packet requires 4 writes then the client waits for a FLASH_DATA notification. If a packet comes out of order, a FLASH_DATA + 0x01 message is sent. However, if a packet is lost, the protocol is in a deadlock.

the problem

WebBLE is not reliable and some of the writes are being lost.

Context

I am testing partial flashing via WebBLE in Chrome Canary (70). It's pre-release quality: the BLE stack crashes if I add 25 delay between packet writes.

@jaustin @finneyj @microbit-sam

martinwork commented 5 years ago

See https://github.com/microbit-sam/microbit-dal/issues/17, which is fixed but notes that there's another problem if packet 4 goes missing (or 3 and 4 etc). Maybe the PF service needs a timeout, after which it sends AA. The iOS app gives up if the successful packet rate falls very low, to avoid retrying forever.

pelikhan commented 5 years ago

I ended up watching for the completion of every packet. If no notification comes with 500ms, I send a packet number ~0 which triggers an out of order and restart the transmission.

martinwork commented 5 years ago

Good idea @pelikhan ! I've created an issue to remind me to look at that. But I'll probably leave it for now. I can't remember seeing the recovery protocol triggered for real - I artificially dropped packets to test it!