Networking experimental devices: MQTT

[eugeneia]

This issue serves to extend on #54 and #24. Quartiq devices will be managed/interconnected over a network, how should that be implemented?

@jordens suggested MQTT as a suitable protocol. I’ve investigated that option a bit and will compare it with what we currently have. I’ll try to summarize the approaches, and distill features/requirements/use-cases served by aspects of those approaches. Please fill in whatever I miss.

Status-quo

Yeet JSON to a TCP port. This is what stabilizer supports currently.

• I can telnet/netcat to the port, type in my JSON and that’ll work.
• I can vendor smoltcp and a ubiquitous JSON encoder/decoder crate and call it a day
• I can probably read it in Wireshark
• Can be described with JSON schemas, flexible extensible
• Question: is JSON is a desirable wire format? Debatable.

MQTT

MQTT is a message bus protocol that facilitates N to N connectivity (hub and spoke). It acts as a transport substrate on top of TCP and implements support for application level features such as QoS (unreliable, at least once / only-once delivery), N-to-N broadcasting, and some more. Classic request-response patterns are re-implemented on top of more generic MQTT constructs.

I’ve implemented a minimal MQTT client that can publish/subscribe (QoS=0) to a topic in ~200LoC. Running ejabberd as a broker was fairly straightforward.

• What MQTT would give us is a well defined way to control/orchestrate N devices on a network—instead of having one concurrent connection per device we’d have all devices connect to the broker, and one or more controller/orchestrator clients that connects to the broker to perform the experiment.
• (We could go for a zero-conf setup and use e.g. DHCP/mDNS to have our devices automatically connect to local broker on startup, and implement a scheme to have automatic discovery of active devices)
• The devices could also interact with each other without establishing connections (meshing) with each other
• We could control auxiliary protocols like high-bandwidth sample streaming via MQTT (E.g., sending a MQTT message dump:10.10.0.7:4567 to stabilizer_XYZ could trigger it to attempt to open a TCP socket to 10.10.0.7:4567 and stream samples over that socket)
• We’d have a clear interface (the broker) to extract low-bandwidth time series data for historic analysis
• Caveat: you need a MQTT broker to talk to your devices (us implementing a client subset seems like reasonable effort, maintaining an MQTT broker would possibly be overkill—we’d rely on a third party providing a working broker)
• MQTT doesn’t define a wire format for payloads (and as mentioned request/response patterns are implemented ad-hoc), we’d do our status-quo or an alternative protocol over MQTT instead of plain TCP. I.e., MQTT does not supersede any functionality that is currently implemented.
• I can maybe still read our protocol on top of MQTT in Wireshark

Cc @ryan-summers @jordens @cjbe

[jordens]

We've settled this in favor of going for MQTT. Forking individual issues arrising from it.