Can someone explain to me the advantages and disadvantages when transmitting MQTT over Websocket instead of direct transmission over MQTT? . I am planning to use MQTT over websocket for my project on ESP8266. I am in a situation where I cannot use MQTT directly
The major upside to MQTT over Websockets for none browser based clients is that it allows you to make use of HTTP proxies (assuming the client also supports proxies) when you don't have a direct connection to the broker.
The other advantage is that if you have a mix of devices and web based MQTT clients that you only need to expose one port to service both sets of clients.
You do pay a price for a larger connect/setup payload with MQTT over Websockets because you have the HTTP Upgrade message that needs to be handled before the normal MQTT connection starts.
Related
In most of IoT platforms, MQTT is used as M2M communication, one of the reasons being lightweight.
Device ---N/W--> MQTT Broker ---> another device
The device communicates to MQTT Broker over TCP/IP, which means there would be a payload addition as part of the TCP/IP layer.
This is my start of confusion:
If MQTT runs over TCP/IP, then how come it's a lightweight protocol?
What are you comparing MQTT to?
The problem with your question is the starting premise to compare MQTT to the underlying TCP/IP that it's using as it's base transport.
Since MQTT runs on top of TCP/IP it's not a valid comparison, try comparing it to say HTTP (with it's HUGE header) which also runs over TCP/IP.
Setting up a MQTT connection and then subscribing to a topic is handled in a few bytes + the topic name and the connection is persisted. When a message is sent it again has a couple of bytes of head + topic and the payload.
By comparison HTTP requests start with the URL + a bunch request headers, the response includes a whole bunch more response headers (there can easily be 100s of bytes of headers as it's all encoded as text) before we get to the payload and in general the connection is closed after the payload.
If you add in TLS/SSL overheads of starting up a new connection for each payload HTTP get even worse.
My MQTT client is paho mqt in Python and the broker is mosquitto. I am sending multiple messages on one topic at the same time using threads in Python. I want to return an answer corresponding to each message, but I feel paho mqtt is single threaded and cant handle simultaneous requests. How can I solve it? I know MQTT v5 supports request-response pattern but, paho mqtt in Python can't provide it yet.
I'm using Mosquitto MQTT broker in my embedded Linux device.
The current topology is like below:
MQTT clients(Publishers) -------MQTT broker--------MQTT clients(Subscribers)
To get the data from MQTT broker which data are published by client,
shall I create MQTT clients(Subscribers) in my embedded Linux device?
Is there any way to make a simple application in
c or c++ to get the data from MQTT broker which data were published by clients(publisher) so that CPU time and memory than creating MQTT client(sub)?
Please let me know how. Thank you.
//Daum
MQTT v3.1 messages only contain the following information:
Topic
QOS level
Retained flag
Payload
There is no information about who published the message, if you need that information you will need to find a way to encode it in the payload when you publish it or use client specific topics.
If MQTT is already a lightweight protocol and it uses small amount of power and bandwidth, then why do we have MQTT-SN? When is it appropriate to use MQTT and when MQTT-SN?
There are few advantages in MQTT-SN (SN for Sensors Network) over MQTT, especially for embedded devices.
Advantages
MQTT-SN uses topic ID instead of topic name. First client sends a registration request with topic name and topic ID (2 octets) to a broker. After the registration is accepted, client uses topic ID to refer the topic name. This saves media bandwidth and device memory - it is quite expensive to keep and send topic name e.g: home/livingroom/socket2/meter in memory for each publish message.
Topic name to topic ID can be configured in MQTT-SN gateway, so that topic registration message can be skipped before publish.
MQTT-SN does not require TCP/IP stack. It can be used over a serial link (preferred way), where with simple link protocol (to distinguish different devices on the line) overhead is really small. Alternatively it can be used over UDP, which is less hungry than TCP.
Disadvantages
You need some sort of gateway, which is nothing else than a TCP or UDP stack moved to a different device. This can also be a simple device (e.g.: Arduino Uno) just serving multiple MQTT-SN devices without doing other job.
MQTT-SN is not well supported.
If you are running out of resources, or you do not have Ethernet/Wifi in your device, use MQTT-SN.
MQTT-SN (wher SN means Sensors Network) is different from MQTT.
MQTT goes over TCP/IP and it can used for LAN communication or over Internet and the Cloud (if you have a client inside your network but the broker is outside on Internet).
MQTT-SN can be used on more protocols suited for sensors network like ZigBee, Z-Wave and so on.
The specification is different from MQTT ... so it isn't MQTT not over TCP/IP.
It's more lightweight and needs a bridge to translate MQTT-SN messages into MQTT messages.
Paolo.
There appears to be 2 ways to maintain an open connection between a Dart server and a Dart client: ServerSocket and Websocket.
https://www.dartlang.org/dart-by-example/#sockets
https://www.dartlang.org/dart-by-example/#websockets
When is it best to use one instead of the other?
Websocket is a protocol build on top normal sockets that are based on the TCP protocol (ServerSocket and Socket). Websockets give you more comfort during programing, because it helps you with:
Framing: TCP is stream based, Websockets allow you to send packages. You don't have to find the start and end of your package on your own.
Closing Handshake: You can send a connection close reason.
Security (in browser context, not required in console application context)
You can also access your Websocket server via a Webbrowser API.
If you want to work together with existing Servers / Clients that are using TCP, that you have to use ServerSockets. Websockets and ServerSockets are not compatible (intentionally, for security reasons).
As Websockets have more internal stuff to do the performance and throughput will not be as good as raw TCP, but this point is negligible.
Both protocols can be used with encryption, Websockets by using a HTTPS connection (wss://) and TCP using TLS (SecureSocket and SecureServerSocket).
For more details about Websockets, take a look at the RFC. RawDatagramSocket allows you to use the UDP protocol in addition to the TCP based ServerSockets.