11

According to this blog, Mosquitto (the MQTT broker) now supports connecting to clients over web sockets. The blog article seems to hint that web sockets are more useful for browser applications, since web browsers don't support proper TCP sockets (yet), although the web socket protocol is supported by the majority of modern browsers.

If I just have various clients in a network (e.g. sensors and actuators based on microcontrollers such as Raspberry Pis), will there be any advantage to using web sockets over direct TCP connections? Is the overhead of the web socket protocol only worth it when you are communicating with a browser?

  • 1
    Can you please tell us if you are coding all of the network? I.e all nodes or both client and server? Or if you have to interact with someone else's software? It sounds like you might be coding only the clients, but I can't be sure – Mawg Dec 20 '16 at 22:56
  • 1
    @Mawg the server will be the Mosquitto MQTT broker, but I can choose which protocol I use for all the clients (and Mosquitto offers both web sockets and direct TCP connections, which is why I asked). – Aurora0001 Dec 21 '16 at 10:23
  • 1
    I think there is some confusion here. I presume what @Auroa0001 means by "direct TCP" is using MQTT over TCP rather than MQTT over Websockets (...over TCP). In both cases there are libraries available so no need to write any code for sockets. – ralight Jan 3 '17 at 17:41
  • @ralight yes, that was my intention really when asking the question. The answers did go a bit astray, it seems. – Aurora0001 Jan 3 '17 at 17:49
7

The question here appears to be "should I use MQTT over TCP, or use MQTT over websockets (which also goes over TCP)?" In other words, is "encapsulating MQTT in the websockets protocol a good idea?"

This is (almost) entirely down to your application and whether you need websockets support - probably for consuming messages in a browser or for firewall reasons. If you can't have your server be accessible on port 1883 or better 8883 for pure MQTT, then websockets may be your best option.

Websockets does require extra bandwidth, but whether that is important to you is something only you can answer.

It's also worth noting that in current versions of Mosquitto, websockets don't work as well as they could so there can be extra latency when sending/receiving websockets messages. That is something that will not be an issue in future versions though.

7

When you are communicating only inside your network (intranet), using pure TCP will be fine. But if you have to connect to another server, problems will arise.

Because most of the modern servers do not allow clients to connect through random ports. They only allow some dedicated ports to connect. That's all. Hence if you have to connect to another server, better to use websocket rather than pure TCP connection.

If you are considering the overhead, it's not That much bigger. You can refer this article, if you want to know more about the websocket's overhead.

In my personal opinion, it's better to use websocket always, except you have some serious concerns.

  • 2
    Err, TCP and websockets are protocols : tools.ietf.org/html/rfc6455, furthermore TCP IS a socket at low level. – Goufalite Dec 20 '16 at 13:11
  • @ThisaruGuruge thanks for your answer - in my scenario in the question I presume that you'd pick TCP over web sockets judging by your answer? Especially since web sockets seem to be mainly supported by browsers, so there's the code overhead of needing to use web sockets over TCP sockets. – Aurora0001 Dec 20 '16 at 16:20
  • 1
    "most of the modern servers do not allow clients to connect through random ports" - the server can choose which port to bind to (man7.org/linux/man-pages/man2/bind.2.html), plus a firewall can further restrict that. HOWEVER, I do not agree when you say "if you have to connect to another server, problems will arise". Rephrase that as "may arise". Even then, it a matter of configuration, which websockets will probably make easier than raw sockets. – Mawg Dec 20 '16 at 23:04
6

tl;dr - always prefer free libraries to coding it your self (unless you have extreme requirements)


Should I use Mosquitto's web sockets or connect clients directly?

How long is a piece of string? (YMMV)

I can only speak generally, but I always prefer wrapper libraries to raw sockets (or, indeed, to coding anything which I can get for free from a library).

They make coding simpler and less error prone. They take care of a lot of house-keeping and error handling, which is code that you would have to write and debug yourself, where as a library has generally been well reviewed and tested and is being used by thousands of others, all of whom will report/fix bugs for you.

Plus, it is less code for you to maintain (and, possibly, port), which means more time to develop, test & polish your app, or move on to the next one.

The only overhead is arguably a function call, if you accept that all that librarian goodness (error handling, hose-keeping & the like) is something that you would have to code yourself in order to get good, stable, software.

If you are concerned about performance, just profile. But, unless your socket is active hundreds of times a second, I would not even bother.

  • Well, there are free libraries for TCP connections and (web)socket connections, and both require a "received message" event. – Goufalite Dec 20 '16 at 13:11
  • 2
    OP wants to know if it is better to use TCP or websockets for efficiency, and you say "use an abstraction library so you won't bother". Sure, but which one ? In C# There is a TcpClient library in System.Net.Sockets (well, well...) and a websocket library in a nuget package (WebSocketSharp). I agree that there is a generic MQTT library for all languages but OP wants to have control over it to choose which protocol it must use. – Goufalite Dec 21 '16 at 8:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.