TCP/IP control

[ric355]

I've had a play with the protocol using TCP/IP and mDNS as the transport and advertisement method. I have a connection to the MyWhoosh instance and can control it, but it's a little bit unreliable.

To give you an example, having got connected and into the ride screen, I put the bike into virtual gear 1 with the AppleTV remote, and then let my device send upshift messages at a rate of 1 upshift every 5 seconds. After 30 upshifts, the virtual gear was only in gear 21.

If I watch the Apple TV, alongside the debug output from the device, I can see upshift messages being sent but apparently not being processed (or at least not resulting in an upshift).

I have tried both just sending a "press" message (three bytes to shift up - 0x01, 0x01, 0x01) and also sending a "press" followed by a "release" with a 100ms gap in between. Both of these seem to result in the same scenario of shifts being missed. It's not obvious whether you're supposed to send a release or not - I can see the example does but the behaviour with and without the release is essentially the same.

When I looked at the protocol a bit closer, I saw that you can actually send multiple buttons in the same button state message. I'm a bit surprised by the fact that there is no counter of the number of buttons to follow in the message. I don't really see how that can work reliably - MyWhoosh has to be able to tell when the end of the message has been reached and that won't always be on a received buffer boundary. With 0x01 being both a command and a button id, it seems like there is scope for subsequent button state messages to be interpreted as buttons from the previous button state message.

What have I missed?

[ric355]

After a bit more investigation:

• if you do three separate writes each one of a single byte for a button command to MyWhoosh, it is unreliable. Sometimes it will change gear and sometimes it won't (about 30% of the time it does not).
• if you do one write of three bytes it's a lot more reliable.
  This is definitely down to the lack of either a button count, or a terminator at the end of the button list. At the moment developers just have to read a block of data from their TCP stack and hope they got all of it. The actual way in which the data is received is entirely dependent upon the TCP stack being used and the way the device at the other end performed its writes (and how its TCP stack works).
  You have to insulate developers from all of that via the protocol, and currently it does not do that.