New feature: queued packet sends

[sidoh]

This new feature adds a queue for packet sends, which allows the various integration points (REST, MQTT, etc.) to enqueue command packets instead of synchronously sending them.

The observable result to the user is for MQTT and UDP, vastly improved performance. Network commands are not blocked on sending the RF packets. They simply enqueue the commands they want sent and yield back to the system. In testing, I was able to send MQTT commands using mosquitto_pub with absolutely no throttling and there was no observable performance impact.

For REST, there is currently no difference. PUT/POST state still handle the command synchronously. If desired, this is easy to patch.

This change also enables new features like #113.

[coehn1]

Hi,
Great work!

• For REST, there is currently no difference. PUT/POST state still handle the command synchronously. If desired, this is easy to patch.
  Could you please implement this?

[sidoh]

Yeah, I can look into it. I actually added special code to keep the REST API synchronous. PUT returns the state of the group after patching, but state is only updated after packets are sent. So it was returning invalid results.

I think the options are:

• Make sync/async a setting
• Make the API always asynchronous, and add a route to query the queue status
• Make GET wait for sends to complete, update usages that rely on state PUT to instead GET after PUT

I'll think about which of these make the most sense. Let me know if you have opinions.