I’m trying to wrap my mind around the worst case that can happen when devices and agents communicate heavily with each other and device peripherals. Am I correct that all of the following statements are true?
Either agent or device can send messages to the other at any rate. It is not necessary that a message arrives at the destination before the next message send can be initiated.
All messages arrive in the same sequence as they were sent. No duplicates will be received, and none will be missing.
It is generally undetermined how long a it takes to deliver a message.
There is no multithreading within device code. No callback in user code will be executed as long as some other user code is still executing on the device. The same is true for agent code.
However, device code and agent code may run in parallel.
There is an incoming and outgoing message queue on both device and agent.
Messages can be sent even if the receiver is currently executing code.
It is impossible for deadlocks between agents and devices to occur.
Also:
Is there a maximum message size?
what exactly happens to messages if a device is down for extended periods of time, and/or WiFi is unreliable?
All messages arrive in the same sequence as they were sent. No duplicates will be received, and none will be missing.
No duplicates will be received, but delivery is not guaranteed if the device disconnects and reconnects, and nor is ordering guaranteed in that situation. (All messages sent during a single connection are ordered, but two rapidly opened and closed connections might be perceived in the wrong order.)
Messages, in both directions, will be throttled (discarded) if the rate exceeds a certain (generous) level.
Is there a maximum message size?
1Mbyte.
what exactly happens to messages if a device is down for extended periods of time, and/or WiFi is unreliable?
When Peter says: Messages, in both directions, will be throttled (discarded) if the rate exceeds a certain (generous) level.
I believe he means that messages may be discarded before reception, rather than before transmission. Messages that the agent or device send will be sent but if transmit buffers are full, the code will block until sufficient buffer space is available. This is certainly the case with the device. Because of this (and because of my next comment), I do my own queuing for transmission.
I’ve also observed that bombarding a device with a high number of closely spaced messages can result in the device disconnecting and reconnecting again a few seconds later. The device doesn’t restart, but it seems to be its way of saying “back off!”. @Peter, is that intended behaviour?
My devices have a lot of air-miles on unstable wifi connections. I can confirm that I’ve never received a duplicate message and I can’t recall an out-of-sequence arrival either. However, if you implement your own timeout functionality (or use bullwinkle), you have to be careful with retries. You can’t be sure whether your original message failed to reach the destination or whether any acknowledgement failed. Idempotency is a valuable trait here.
In my opinion, agent.send and device.send are barebones (but sufficient for many apps). For a more robust communications scheme, you’ll need to wrap a framework around it.