In this article:
The message queue is your red carpet to the Myriota Network. To transmit on the Network, you need to add a message to the queue using the ScheduleMessage API.
Myriota’s unique patented communications technology enables massive numbers of devices to send messages in an uncoordinated fashion without the need for complex handshaking. This provides reliable communication while minimising energy consumption.
Once you have scheduled a message, the queue carefully manages transmission and combines forces with the other unique elements of the Myriota’s communication stack to deliver it to you.
You can think of the message queue as a super efficient waiting room. Messages in the queue are processed based on priority, and prioritisation is based on the likelihood that a given message has been successfully transmitted. Message age is just one factor that can influence the measure of priority.
Message transmission
At each transmit opportunity, the Myriota Module transmits as many messages from the queue as possible, selecting messages in order of priority. A message remains in the queue until the target probability of successful reception has been reached, and the message may be sent more than once to achieve this.
This behaviour has two benefits:
-
Latency is minimised by the distribution of priority. Fresh arrivals to the queue are not forced to wait for older messages to reach a minimum success threshold before being transmitted
-
Message delivery success is maximised through redundancy
At present, you cannot determine whether a particular message in the queue has been sent. However, the MessageBytesFree API can be used to tell if there is space in the queue for transmitting for more messages. For example, if MessageBytesFree() is 60, then there is space for 3 more 20 bytes messages.
Message queue size
The queue is 480 bytes in size, or capable of holding up to 24 messages at any one time.
To identify when the message queue is full, you can inspect the remaining space in the queue with the MessageBytesFree API.
If you continue to schedule messages once the queue is full, the Module copes with this by prematurely replacing the messages that have the highest likelihood of having been received successfully.
Overloading the queue may have the affect of reducing the target probability, resulting in a higher number of undelivered messages.
How many messages can I schedule per day?
Whilst knowing how big, or how full the queue is can be useful, it may be more important to think of queue capacity in terms of how many messages you can schedule per day to meet a target latency.
The Myriota Network has two service types. The daily message rate is service type dependent.
Service 2
- 50 messages per day
- Total 1kB of message data per day
Service 1
- 24 messages per day
- Total 480B of message data per day
Scheduling no more than the daily message rate with the ScheduleMessage API, spread out across regular intervals, or using the MaxThroughout or BeforeSatelliteTransmit APIs, will maximise the probability that all messages are successfully sent and delivered with minimal latency.
You are free to schedule more than the daily message rate, but doing so may overload the queue relative to the available capacity for transmission. You may see an increase in latency as a result and some messages may be not be delivered. See the Myriota Network Latency article for more details.
The recommended daily message rate will continue to increase as our service is optimised and improved.
Deleting from the queue
It is not possible to remove a particular message from the queue. Calling ScheduleMessage when MessageBytesFree is zero will effectively replace a message in the queue.
The message replaced is typically that which has been in the queue for the longest time.
Message arrival order
The Message Queue is best thought of as a waiting room. Our smart transmit scheduler may send a single message several times over different satellite passes in order to increase the probability that it is received. Fear not, the Myriota Cloud removes duplicate transmissions prior to forwarding them to you.
Because of this unique algorithm, messages have an excellent chance of making it all the way to your Destination. Occasionally, they may also be received out of order.
This might be totally fine for you, in which case you'll be happy to hear that we don't introduce network latency by buffering messages for re-sequencing, or use up precious payload for sequence numbers that you don't need.
If your application is sensitive to the order of delivery, or you want to detect if an individual message goes missing, you can add a scheduled date/time stamp or a sequence number to your payload and use this to buffer and re-order messages at your Destination.
A sequence number has the added benefit of allowing you to detect if a given message is not received.