Menu
When publish/subscribe to messages directly from a web server to a web browser or vice versa we can use MQTT over WebSockets. At the same time, SSE(half duplex) can be used to push data from web server to web browser. What are the other major differences? Especially related security and consistency of the application.
844
SSE is best used when it's not necessary to send data from client to server. For example, in status updates and push notification applications, the data flow is from the server to the client only. This is what SSE is designed for, so WebSocket would be overkill. It's always wise to use the best tool for the job.
WebSockets generally do not use 'XMLHttpRequest', and as such, headers are not sent every-time we need to get more information from the server. This, in turn, reduces the expensive data loads being sent to the server. WebSocket connections can both send and receive data from the browser.
MQTT over Websockets allows you to receive MQTT data directly into a web browser. This is important as the web browser may become the DE-facto interface for displaying MQTT data. MQTT websocket support for web browsers is provided by the JavaScript client.
It can service max 10,000 concurrent connections(docs).
WebSocket is a low-level (framing) transport standardized by the IETF and a JavaScript API standardized by the W3C. It is not publish/subscribe. You can have publish/subscribe protocols that sit "on top" of WebSocket. For example, AMQP is a pub/sub protocol that can be implemented with WebSocket. Another example is Java Message Service (JMS); while JMS is an API and not a bit protocol, it can be implemented over a pub/sub protocol that, in turn, is implemented with WS. I mention both AMQP and JMS because both the AMQP protocol and the JMS API provide for "acknowledgements", which will give you a high degree of reliability unlike other mechanisms.
MQTT is a publish/subscribe protocol that can be implemented over a low-level transport. MQTT can run over TCP/IP or WebSocket for example. MQTT has QoS levels which also give you acknowledgements (ie, for reliability). MQTT is not normally native to a browser, so MQTT messages have to be made web-friendly before connecting to a browser... usually WebSocket, since WS is a 'fat pipe' and similar to TCP in a way.
Server-Sent Events (SSE) is a HTML5 formalization of "Comet" (or "reverse AJAX) techniques. "Comet" was a loose collection of informal techniques; different implementations did not work together. SSE is not publish/subscribe. It is an HTTP mechanism to broadcast data from a server to the browser client(s). Essentially its a fire-and-forget technique.
Most modern browsers understand SSE and WS (IE/EDGE does not currently support SSE); they usually all understand Secure WebSocket (WSS) too. Practically all webservers and appservers understand SSE and WS/WSS. If you use WSS, your data will be encrypted in transit. The particular encryption cipher is setup on the connection; you'll have to investigate what ciphers your browser clients and web/app-servers understand.
90
MQTT offers 3 different QOS levels that control delivery of messages
QOS 0 - Best effort QOS 1 - At least once QOS 2 - Once only
MQTT supports User authentication and topic level ACL so you can ensure users only see what they need to see even when using wildcard subscriptions
MQTT also allows for direct connection to the backend systems without the need for bridging in the WebApp
24
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
