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.
Related
I have a doubt about the IoT Protocol Stack .
Searching between papers on google scholar or IEEE about IoT , i find the actual "IoT Protocol Stack" :
IoT Stack
I think it is uncorrect .
The doubt is about the transport layer and application layer.
1) why there is only CoAP on the application layer if there are many others Application Layer Protocol for the IoT , such as : MQTT, XMPP ,AMQP , WebSockets and so on?
2) Why they provide only UDP at the Transport layer if in the upper layer ( Application) there are some important protocol in the environment of the IoT , for example MQTT, that run over TCP ?
The term "IoT" is used with various meanings by different interest groups; so is therefore the term "IoT stack".
What the linked image depicts is the IETF IoT Stack, which is the IETF's idea of what IoT devices should use to deserve that name. CoAP is the application protocol specified by IETF (and used by various others like OMA LwM2M, OCF or Thread), and is in my experience the best suited protocol as it allows full operation on tiny devices (technically: Class 0 according to RFC 7228 – good luck implementing XMPP, WebSockets or similar on those) while still being powerful enough to express all the concepts from the HTTP web.
The image depicting only UDP is probably due to the focus on IoT devices: While CoAP can be transmitted over several transport layers (including TCP and WebSockets, but also SMS in a draft version), those transports are rather used indirectly (eg. by a browser application that uses a gateway to talk to UDP connected devices), the expected scenario for the devices themselves is using CoAP over UDP on a 6LoWPAN network. That doesn't rule out other deployment scenarios (eg. LwM2M uses CoAP over cellular networks a lot, in UDP and TCP transports), but is better seen as typical example for the smallest of devices.
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.
MQTT is a publish/subscribe protocol. Whenever a publisher publishes to a topic, all the subscribers that have subscribed to that topic will get the message via an MQTT broker. I would like to know the maximum number of clients an MQTT broker can handle. Is there any upper limit for that?
The only way to work this out is to test depending on your specific workload.
It will be entirely dependent on the following:
The size of the machine you run the broker on.
The size of the messages you send.
The rate of messages.
The number of clients (both subscribers and publishers).
The performance characteristics you need to meet.
Which broker you are using.
And possibly many more factors.
How many clients an MQTT broker can serve depends on the MQTT broker software you're using. Most MQTT brokers will likely only be limited by the amount of memory available (each socket uses a chunk of memory) and it therefore becomes a question of which broker software utilizes the memory (and other resources) in the most efficient manner. Of course some brokers might have other limitations.
In practice you'd also have to look at what you can do with the connected clients - some brokers may behave differently (performance wise) depending on how many clients are connected etc.
I want to send small (a few bytes) data from one ESP8266 to another over long distances.
I believe the signal is too weak to connect one ESP8266 to another but maybe they can receive small messages with some delay?
How can I achieve that using arduino-esp8266 library (or whatever)?
If ESP8266 boards can not connect directly to each other because of the weak signal (approximately more than 50m between them) you can still connect them to each other (indirectly) if they are connected to the same WiFi network created by external router or internet. But you can connect them to each other without need to connect to any external network only if they are in range of each other.
It both of them are connected to same local WiFi network router you can communicate between them as if they are connected directly to each other. Just in this case router option "WiFi Client isolation" must be disabled in router settings page for boards to see each other(in case that router has this or similar named option).
Otherwise if ESP boards are connected to totally different networks, but both of these networks have access to internet, you can still connect them to each other but then you must use port forwarding on each router, so both of the ESP8266 boards are visible form internet. Google a bit about it, it is not so complicated. In this case you can have boards on any two locations in the world and make them communicate to each other as long as they are accessible from internet.
Maybe it is hard to test it when your code do not work out of the box, so I would recommend that you use some TCP or UDP terminal to test connectivity between two WiFi clients on different or same network. There are buch of such terminals available online.
For example for sending and receiving UDP packets same way as you would send/receive data from serial port, I use Docklight Scripting.
https://docklight.de/downloads/
I actually use it also for other Serial port communication so no big difference there. Don't let description text on their page fool you. It can also send/receive TCP/UDP data :)
Just when you create new project go to tools->project settings and type IP and port of another device you want to connect with (this can be another PC running docklight scripting or your ESP board). For example in my case I type in
Send/Receive Comm.: UDP:192.168.0.154:9761
Because that is the IP of my ESP board on local WiFi network and press "play button"or F5. Now you can send receive data to your board using UDP in same way that you communicate to basic serial port and in such way test basic connectivity. Or even use two laptops just to confirm connectivity between two WiFi clients on network.
And third hardest option must most versatile is needed if you do not have access to routers setup page (they are password protected) and cannot set port forwarding, then you must create server application on some server that is visible from internet and has public IP. So both of your ESP8266 boards are connected to this server as clients (for client port forwarding do not need to be set but in this case you must have access to internet by both clients) and server can forward their messages to each other. But this is way out of this topics scope. Maybe for start you use TCP/UDP terminal just to check connectivity between two WiFi clients and see if ESP8266 can communicate directly or not. Docklight scripting is just suggestion because it is my personal choice for TCP/UDP/RS232/RS485/MODBUS/USB HID, but you can use other software for this.
I hope this helps a bit about ways to connect two ESP8266 boards indirectly.
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.