Today we were asked to have a look at MQTT.

MQTT is a machine-to-machine (M2M)/"Internet of Things" connectivity protocol. It was designed as an extremely lightweight publish/subscribe messaging transport. It is useful for connections with remote locations where a small code footprint is required and/or network bandwidth is at a premium. For example, it has been used in sensors communicating to a broker via satellite link, over occasional dial-up connections with healthcare providers, and in a range of home automation and small device scenarios. It is also ideal for mobile applications because of its small size, low power usage, minimised data packets, and efficient distribution of information to one or many receivers

So by the description this is clearly something in the operational domain of PSYC. Let's look at how they did it compared to us:

Protocol Details

• MQTT is binary and not extensible ad hoc. PSYC is designed to operate under similar conditions of compactness, yet its syntax allows for the devices and their protocols to evolve.
• MQTT pays particular attention to keeping communications alive and provides for a defined procedure in case of abnormal disconnection they call "Last Will and Testament." PSYC doesn't have a specific extension protocol like that, you would have to use the programmability of entities to achieve this.
• The protocol has a few other custom extensions like the choice of reporting behaviour (QoS). In a PSYC scenario these could simply have been application-specific extensions, unless you prefer to have them in the standard. This is exactly what PSYC's method inheritance is for.
• MQTT has a very static way of defining error codes. PSYC allows for existing applications to receive and handle errors correctly even if they weren't yet defined and known at the time the device was built.

Minor imperfections

I think there is a bug in the specification: There are several bits "reserved for future use." The protocol writers should specify exactly how the reserved bits have to be set in current applications (zero I presume) and how they should be treated if they are encountered as set (ignore I presume). It's enough if one implementor of the spec does it wrong and, whoops, the last exit for extensibility is blocked.

Another detail. In DISCONNECT it says A server should not rely on the client to close the TCP/IP connection after receiving a DISCONNECT. In fact the client should wait for the server to close the connection as only in that case it is assured that all messages have arrived safely and been processed correctly. The client must close the connection itself only if it can't be avoided. Closing sockets properly however is a frequent mistake made in protocols. See XEP-0190 to see how it got fixed years after the deployment of XMPP.

Multicast, anyone?

Depending on the topology of the nodes to be deployed, it may turn out to be useful that PSYC has a multicast distribution model. Should the devices not always have a direct link to the Internet but rather be connected in a mesh between each other, the multicast model simplifies distributing information from the Internet down to all the nodes in the mesh network.

Conclusion

In other words what is being done with MQTT presumably could have be done with PSYC. There may be a slight disadvantage in encoding compensated by PSYC's advantage in future extensibility (using the try & slice pattern). Another reason to consider PSYC is its applicability to wireless mesh topologies. A suitable implementation of PSYC for embedded devices resides in libpsyc.