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.
Related
I have one concern as I have just started working with MQTT and CoAP in my school.
I did data packet transmission using both protocols separately, For MQTT I used mosquitto and libcoap is used for CoAP, the transmitted packet contains the information “Temperature=22*C”. I know the difference in Header sizes in the packet for both protocols. But My question is why the payload size is different even though it is containing the same information.
I know the TCP header is larger than UDP header. But for MQTT, the payload is 22 bytes and for CoAP it is 4 bytes. Why the payload is compressed for CoAP with the same info?
Please help me with an answer.
As you noted TCP packet and UDP datagram sizes will differ at least due to TCP and UDP headers sizes difference.
MQTT message (TCP packed body) and CoAP packed (UDP datagram body) will differ at least due to MQTT & CoAP messages headers difference.
MQTT payload and CoAP payload (omitting MQTT and CoAP headers) might differ due to different serialization protocol. The string can be transmitted being serialized in different formats: JSON, TLV, CBOR, plaintext. You need to check what is used for each message in your case.
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.
I have recently developed a GPRS communication software using Arduino (embedded application) and GSM modem to communicate to/fro from web server. However I found that there is enough delay and request getting dropped (response timeout) while receiving a response from server at client side.
The techniques I have tried are - TCP / UDP / HTTPS / HTTP.
In my case our requirement is for a Reliable, Fast, Guarantee Communication between client and server.
Please let me know which communication stack would establish the same or rather be best to be used?
Thanks in advance
GPRS gives you direct IP access to the Internet. If you're losing packets or suffering large delays when sending packets to your server then this sounds like a problem with the mobile ISP.
As Ken mentioned GPRS will provide you IP connectivity to the internet (or some private network if applicable).
On top of IP you can choose to use a number of higher layer protocols, the two most common of which are probably UDP and TCP.
UDP is 'connectionless' and provides very little in the way of error detection/correction etc.
TCP is connection orientated (which means that some signalling happens back and forth to establish a virtual 'connection' first). It also includes mechanisms to provide error detection, error correction and correct packet delivery order. TCP also includes flow control, to avoid the sender overloading the receiver, and congestion control to avoid network overload.
There is a perception that UDP is faster than TCP, but I think it depends on the situation - take a look at this discussion for some further discussion on speed, reliability etc between UDP and TCP (go down through all the high scored answers):
UDP vs TCP, how much faster is it?
For your requirements, I would think a solution based on TCP/IP is probably what you want.
Whether you want to use HTTP or some other protocol on top of that is going to be dependent on your solution, and to some extent on personal preference.
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.
I'm trying to implement the following UDP protocol, but I'm having a little trouble figuring exactly how I should approach this.
The protocol states that I should send a particular UDP packet to a certain server, after which the server will stream (several UDP packets that are related) a response back to me, also as UDP packets. I have managed to send the UDP packet fine using the following code:
connection, error := net.DialUDP("udp", nil, endpoint)
...
if written, error := connection.Write(query.ToBytes()); error != nil {
...
} else {
log.Printf("Successfully wrote %d bytes to %s", written, connection.RemoteAddr())
}
When I use Wireshark and take a look at what's going over the wire, it looks like it sent the packet just fine (the only issue here is that I never get a reply from the server, but that's unrelated to this question).
What's the best way for me to handle the server reply in this case? Can I use the previously established connection to read server responses back (this seems unlikely to me, as it's UDP so connectionless) or should I use net.ListenUDP(...) to establish a server on the correct local address and port to read whatever the server sends back to me?
The intent of the protocol is clearly that you just use the same UDP socket to receive the reply that you used to send the request. If you have a client-side firewall, you will have to explicitly open a UDP port and bind the UDP socket to that port before you send. Otherwise just let the system choose the local port, by not binding at all.
The phrase 'the same port as was established by the intial packet' is misleading. Are they your words, or the protocol specification's? What really happens when you do the first send is that if you haven't bound the socket yet, it is automatically bound to a system-chosen port, exactly as if you had bound it to port zero.
Because of the specific protocol design, it's impossible to know on which port the server will send its reply packets. After taking a second look at the packet dumps, I noticed that the server in fact does reply, only the client immediately replies back with an ICMP message saying Destination port unreachable. So the server was trying to reply, but it couldn't because the client would not accept the packets on that port.
To solve this, I have used net.ListenUDP to listen for incoming packets immediately after the client sends the initial packet using the established connection's local address:
incomingConnection, _ := net.ListenUDP("udp", connection.LocalAddr().(*net.UDPAddr))
log.Printf("Listening for packets on %s", incomingConnection.LocalAddr())
defer incomingConnection.Close()
After which incomingConnection can be used as a Reader - for example - read the packets that the server is sending.