This page discusses the idea of running MQTT over Websockets and what is required to ensure implementations are inter-operable
The majority of MQTT implementations build on top of TCP. TCP works in many scenarios with one big exception, it is not possible to create a TCP connection from a Web Browser. HTTP is the main protocol used by browsers to communicate with servers, it is great for many things but has one big drawback good when it comes to efficiently receiving "events". With HTTP the browser has to poll the server to find out if an event has occurred, polling is bad at the best of times and especially so for events that occur infrequently. Wouldn't it be great if events and data could be pushed to (and from) a browser without the need for polling?
With the advent of Websockets it is now possible to create a bi-directional communication path between a web browser and a web server. A web socket is for web browsers/programmers the same as a TCP socket outside of a browser. It provides a powerful construct for building applications that need to communicate but in being powerful the application programmer has to do a lot of the work. Wouldn't it be great to do MQTT from a web application. With the advent of Websockets it becomes possible and with it all the benefits of MQTT can be experienced by a new class of web applications.
For background, Websockets is two standards - an API looked after by W3C and a protocol which is managed by the IETF.
Ensuring implementations can inter-operate
This remainder of this page captures areas that need to be considered in order to create a consistent approach for MQTT over Websockets. Or put another way, what an MQTT Websocket client and a MQTT websocket server need to implement in order for them to be inter-operable. Going forward this is something that should be considered as part of the MQTT specification.
Making MQTT over Websockets inter-operable:
- Must support WebSockets as defined by RFC 6455
- Must use websocket binary frames.
This enables MQTT v3,1 per the specification to flow over websockets with no change to the MQTT packets
- Must use "mqttv3.1" as the websocket protocol name.
This is applicable when creating the websocket: e.g. new WebSocket(wsurl, 'mqttv3.1')
- The path portion of the url specified on the MQTT connect should be "mqtt"
For instance ws://m2m.eclipse.org:800/mqtt . mqtt should be the default with the option for an alternative to be configured / specified
Open points for further discussion:
- Should an MQTT packet be aligned with a WebSocket frame?
- A MQTT WebSockets client should not assume that a MQTT packet is aligned with a WebSockets frame. A WebSockets frame may contain either part of a MQTT packet, or more than one MQTT packets, the final one which may also be partial
- The reason for this is it enables folks to simply put one of the many TCP <=> WebSockets gateways / mappers / proxies in front of an existing broker / client / whatever and just make things work. This has come out of real dev work here at stormmq (BTW, we don't use a generic gateway, but it's a great way to get mileage out of existing infrastructure). If this must isn't included, then (a) naive clients come into being or (b) a W/S gateway has to be able to parse the TCP stream and know about MQTT packets - not good for several reasons.
The idea is for Paho to host a MQTT over websocket implementation