TR-369 WebSocket vs MQTT vs STOMP: how do the USP transports compare?

Before an Agent and a Controller can exchange a single USP Message, they have to agree on how it travels. TR-369 calls that layer the Message Transfer Protocol (MTP) and defines four of them. The one you pick decides whether your devices need a broker, how they announce who they are and how they behave after an outage. This guide compares WebSocket, STOMP, MQTT and UNIX Domain Socket using only what the specification says.

What is a Message Transfer Protocol?

An MTP is “the protocol at a layer below USP that carries a Message”, for example WebSocket (§1.4). The USP Record is the MTP payload (§4.1.3), so every binding answers the same questions: how to connect, how to carry a Record and how to report a failure. Our guide to TR-369 explains how Records and Messages nest.

A few rules apply to every MTP (§4.1). Agents and Controllers may support more than one, and Endpoints always respond on the MTP where the Message was received (§4.1.1). Once the channel is up, an Agent that can do so sends the Connect Record for the MTP in use, such as WebSocketConnectRecord or MQTTConnectRecord (R-MTP.6), and it should send a DisconnectRecord before leaving (R-MTP.7). Since USP 1.2, Record problems are reported with USP Records instead of MTP-specific messages, using error codes 7100 to 7199 (§4.1.4, Issue History).

How do the four MTPs compare?

The split that matters most is direct versus brokered. With WebSocket, the two Endpoints hold the session themselves. With STOMP and MQTT, each Endpoint holds a session with a server that routes Records on its behalf.

How does the WebSocket MTP work?

The WebSocket binding uses RFC 6455, with long-lived sessions reused for later Records (§4.3, §4.3.2). An Agent must be able to open a session and to accept one from a Controller (R-WS.5, R-WS.6). In general the Agent opens it, so it does not expose an open port toward the Internet for security reasons, and two Endpoints use at most one open session (§4.3.2, R-WS.4).

The handshake carries two USP details (§4.3.2.1):

• The subprotocol. The client sends v1.usp in the Sec-WebSocket-Protocol header and the server returns it (R-WS.9 to R-WS.11). If it does not come back, the client does not establish the session (R-WS.12).
• The client’s Endpoint ID. With TLS, the server cannot tell who is connecting without looking inside the certificate, so the client adds eid= and its Endpoint ID to the query of the request URI (R-WS.10b). The requirement to use a WebSocket Extension instead was removed in USP 1.3 (R-WS.10a).

Records travel in binary data frames (R-WS.14). Senders should not fragment them, but receivers must handle fragments (R-WS.14a, R-WS.14b). If a Record cannot be extracted, for example from a text frame, the receiver closes the connection with status code 1003 (R-WS.16). Agents keep the session alive with Ping and Pong frames on a configurable interval (R-WS.17, R-WS.18).

How do STOMP and MQTT use a broker?

Both brokered bindings follow the same basic steps: negotiate TLS if configured, connect to the server, subscribe, then send USP Records (§4.4, §4.5).

1. AgentSTOMP or MQTT clientSubscribes to its own destination or Topic and adds a reply-to address to everything it sends.
2. BrokerSTOMP or MQTT serverAuthenticates each client and limits what it may subscribe to.
   • STOMP: destination
   • MQTT: Topic
3. ControllerSTOMP or MQTT clientSends to the Agent’s destination or Topic and answers on the reply-to address.

Because there is no direct session, everything sent through the broker says where to answer. STOMP uses a reply-to-dest header (R-STOMP.21). MQTT requires a “reply to” Topic in every PUBLISH packet: in the Response Topic property on MQTT 5.0, or after /reply-to= at the end of the Topic Name on MQTT 3.1.1 (R-MQTT.22 to R-MQTT.24). The broker can also tell an Agent where to listen: a subscribe-dest header on STOMP, a subscribe-topic User Property on MQTT 5.0 (R-STOMP.6, §4.5.2).

The broker carries real duties. A STOMP server must authenticate clients and let each one subscribe only to its own destination (R-STOMP.34). An MQTT server must authenticate clients and support an Access Control List that restricts the Topics each one can use (R-MQTT.42).

• STOMP, the Simple Text Oriented Message Protocol, is used in version 1.2 (§4.4). USP Endpoints send the Endpoint ID in an endpoint-id header (R-STOMP.4), subscribe with ack set to “auto”, and never send transaction or acknowledgement frames (R-STOMP.17, R-STOMP.26, R-STOMP.27).
• MQTT, Message Queuing Telemetry Transport, joined USP in 1.1 (Issue History). Clients must implement MQTT 5.0 and may add 3.1.1 (R-MQTT.1, R-MQTT.2). Version 5.0 matters because 3.1.1 gives a client no simple way to pass its Endpoint ID to the server, and gives the server no way to tell the client its “reply to” Topic (§4.5.1.1). Agents must support MQTT over TCP, and MQTT over WebSockets is allowed (R-MQTT.3). Endpoints must support QoS 0 and 1 (R-MQTT.20), and since USP 1.5 they should support ALPN in the TLS handshake (R-MQTT.48a).

In DNS-SD records, a brokered Endpoint advertises the broker’s address, not its own (R-STOMP.32, R-MQTT.38). See how a USP Agent finds its Controller.

When does the UNIX Domain Socket MTP make sense?

When the Agent and the Controller live on the same box. This internal MTP, added in USP 1.3, connects “separate processes within a single device” (§4.6). The socket is tied to a local file path instead of a host and port, each Endpoint acts as server or client but not both, and nothing needs advertising over mDNS (§4.6.1).

FrameA Header, then one or more TLV fields.

• Sync: 0x5f 0x55 0x53 0x50 (“_USP”)
• Length of the rest: 4 bytes

TLV fieldType 1 Handshake, 2 Error, 3 USP Record, 4 Password.

• Type: 1 byte
• Length: 4 bytes
• Value

USP RecordThe Protocol Buffers binary encoding of the Record, carried as the value of a Type 3 TLV.

Both sides exchange Handshake TLVs with their Endpoint IDs before any Record, and a client that gets no answer within 30 seconds closes the connection (R-UDS.16 to R-UDS.18). When a connection drops, the client retries within a random 1 to 5 seconds (R-UDS.5). Encryption is not required, though TLS has been an option since USP 1.4, and USP 1.5 added the Password TLV for shared-secret authentication (§4.6.4, Issue History).

Which MTPs need TLS?

The baseline is R-MTP.0: an MTP “MUST use secure transport when USP Messages cross inter-network boundaries” (§4.1.2). Within an end user’s LAN, MTP security may not be necessary. MTPs over TCP are expected to implement at least TLS 1.2, and when TLS is used, the Agent must require an X.509 certificate from its peer (§4.1.2, R-MTP.1).

MTP bindings provide point-to-point security, so on a brokered MTP that TLS protects each hop to the broker, not the whole path between Agent and Controller (§6.4). For that, USP has Trusted Brokers and end-to-end Secure Message Exchange, covered in TR-369 security.