IoT core protocol-message Push technology evolution

Messaging capabilities are an important support for the internet of Things (Ofthings, IoT), and many of the IoT technologies are rooted in the mobile internet. This paper describes the application and evolution of mobile Internet message push technology in IoT.

I. IoT architecture and KEY technologies

From the perspective of development, wireless access is the core technology of IoT devices, identity device management and message push technology are the core technologies of the IoT cloud. From the perspective of the scene experience, in addition to the former, but also include the front-end development of mobile phone technology.

In a blog post on a hardware-based IoT architecture, the author has described in detail the components, key scenarios, and communication protocols (application layer and TCP/IP layer) of the IoT architecture based on the hardware platform in a large picture. This paper focuses on the realization of communication technology between various parts of the internet of things.

IP Interconnect architecture is already the de facto standard for the internet of Things (the key technologies for the IoT TCP/IP layer will be addressed in a separate article, so stay tuned). The message push technology mentioned in this paper is the application layer protocol technology based on TCP/IP protocol.

Let's go further by abstracting the Internet of things that are based on IP architectures, such as (ignoring basic technologies such as web and routing):

Visible, the core component is the IoT device things, Gateway and cloud. IoT equipment is divided into two categories, one is its own natural support TCP/IP and can directly access the Internet of things, such as WiFi, gprs/3g/4g and other equipment, and its failure to support IP protocol and require a gateway (protocol conversion) to access the Internet of things, such as ZigBee, Bluetooth and other devices. For Bluetooth devices, the phone is actually a gateway. The phone communicates with the peripheral Bluetooth device through its own Bluetooth, and communicates the message to the cloud server via the phone's WiFi or 3g/4g module.

From the perspective of the scene, the Internet of Things is ultimately a human service, and the mobile phone is the most direct entrance to human experience. As a result, the phone component can be added separately and differentiated from the gateway in general sense. This is the core of the IoT: device-to-gateway-cloud-Mobile.

From the point of view of application layer development technology, the IoT application is based on TCP/IP architecture, and on the basis of the Gateway Protocol conversion, the components of IoT application are: device-to-cloud-mobile.

OK, with the above introduction, we analyze the device, cloud, and mobile direct message push technology from the point of view of Internet of things application, which includes two-way communication technology in the cloud and device side, and two-way communication technology of mobile phone and cloud.

Second, mobile internet communication mode

The Internet has b/S and C/s two modes of communication. In the mobile Internet domain, the app uses the client's role to communicate with the server in the form of C/s, but it is a super app that allows users to H5 programming to gain the ability to manipulate hardware devices through a built-in browser, so the communication module of the hardware platform is B/s mode.

Mobile Internet B/S technology is no different from traditional internet, the built-in browser supports H5, so it can get good platform extensibility. We have recently focused on the hardware platform-based Internet of things, so we've talked about the evolution of message-driven technology around B/s mode.

HTTP protocol is the basis of B/s, HTTP has get and post two ways. Don't know please Baidu, and then look down:-)

Iii. the evolution of message push technology

1.HTTP Unidirectional Communication

The browser uses the HTML text Markup Language, where the browser initiates a request to the server via the HTTP protocol (which includes the URL, which is what we often say), and the server sends the URL's HTML content back to the browser as a response via the HTTP protocol.

1) mobile phone side. End because there is a built-in browser, its natural support front page.

2) cloud-to-mobile push. The cloud uses technologies such as jsp/php to develop and design front-end Web pages and simple logic.

3) device side. When the device is on-line or accesses server-side parameters, it needs to impersonate the HTTP protocol (c) to make a request to the servers, and the requested format is generally not using HTML, but rather a simpler XML or JSON protocol format.

4) cloud-to-device push. The cloud uses HttpServlet, a servlet using the HTTP protocol, to respond to a device's HTTP request, replying to an XML or JSON-formatted message.

5) Disadvantages. This way of communication is characterized by a response to a request, always to the client to make a request to the server, the server to give a response. The server never sends a message to the client at all, and the server replies only once when the client makes a request. This kind of HTTP one-way communication is playing an important role in the Internet domain, that is, the server can be stateless, greatly simplifying the service flow of the server and improving the efficiency. But in the internet of things, we are asking for a two-way communication capability. The server should be able to actively send messages to the device side or mobile phone.

In this mode, how do we do two-way communication? The only way to do this is for the client to constantly make requests (or periodically), and the server is constantly giving back. The disadvantage of this mode is obvious: first, the network load is heavy, the server will close the connection after each response, so each communication has to be re-handshake. The length of the header content of the HTTP protocol is not small. Second, real-time poor. The general device side is periodically polling the server for new messages, and polling is not a good real-time way to get it. Third, the browser side every time the request is in the HTML full content to respond, the message length is too large, in this case, the browser page will be found to constantly refresh.

2.Ajax Polling

Ajax technology is a JavaScript technology supported by browsers. It can locally improve the user experience technology, so that users do not notice the browser page refresh to make a request to the server and get a response. The principle is:

1) The browser issues a URL page request and the server responds to the HTML page content.

2) The HTML page uses JS to call XMLHttpRequest to make an asynchronous communication request to the server.

3) The server responds to the XML format data to the browser page.

4) The HTML page uses the DOM model to dynamically refresh the page elements.

Ajax technology is the recommended page interaction technology in the framework of hardware platform, but its nature is to obey the rules of HTTP one-way communication, but it doesn't need to refresh the whole page when the page interacts. The real-time problem of two-way communication is still unresolved.

3.Websocket

WebSocket is a new protocol supported by HTML5 that truly supports two-way communication between the browser and the server. TOMCAT7 and above also support the WebSocket API.

1) in order to be compatible with the browser HTTP protocol, WebSocket rules that the first request will still be issued in accordance with the HTTP protocol specification header, but its connection domain value is upgrade, and increase the upgrade domain, the value is the socket, That is, inform the server that the incoming communication is websocket two-way communication. If the server accepts it, it returns 101 to the client for protocol switching.

2) The next communication will no longer use HTTP as the transport protocol, but rather communicate using the data format specified by WebSocket, which is divided into control frames and data frames. The control frame is the heartbeat frame (ping), and the server responds Pong, and the end frame, the data frame is the real data format, its format header only 6 bytes (2 byte header and 4 bytes of mask), followed by the real data (masked conversion). is much smaller than the length of the HTTP format header.

3) between the client and the server is to remain connected until close, the current period to send a 2-byte 3-byte ping frame.

Visible WebSocket is a great improvement over Ajax. It not only eliminates the need to connect the handshake often, but also simplifies the format of the protocol, most importantly the real-time is guaranteed because both sides are true full-duplex communication.

Browser client Support WebSocket, the server uses TOMCAT7 above the Websocketservlet class, the device side to the WebSocket protocol in accordance with the C language to simulate communication.

When we use the device to simulate WebSocket communication protocol, we usually look at the protocol first, and then use HttpWatch and other tools to grab the bag, caught the head is get Ws://ip:port/path, if the C language is such a simulation contract will be reported to the bad request. Because the C language uses the socket to establish the communication has used the IP and port, its first packet of the head is Get/path can not precede it with ws://ip:port/.

4.MQTT

The above analysis is the use of mobile Internet technology to the IoT, which has a specific is to establish a connection when the URL address, by two roles is the client and server, which we generally referred to as a restful architecture (in addition, there is a SOAP application-oriented Web services architecture). RESTful architectures are being used more and more widely in the Internet, but in addition to interconnection, the IoT has its own unique features, such as limited resources for its terminal devices, low power usage scenarios, poor network connections (disconnected from time to time), etc. Using a restful architecture (such as WebSocket) in a C-language simulation can make the terminal more heavily loaded, and messages sent to terminal devices by the server may not be received due to disconnection.

MQTT is a lightweight protocol that IBM exits on the internet of things, built on the TCP/IP layer protocol. It is an important part of the Internet of things and may become a de facto standard for the internet of things. It has the QoS, can buffer the message, and through the retransmission mechanism to ensure the terminal device receives the message, its message format is extremely simplified, the shortest is two bytes, it provides the subscription and the release pattern, the high efficiency pushes the message.

Mqtt has three roles, including server proxies, subscribers, and publishers.

1) Start the Server Agent.

2) Subscribers subscribe to the server proxy for related topics.

3) The Publisher publishes the subject information to the Server Agent.

4) The Server Agent wants all subscribers who subscribe to the topic to push messages.

MQTT is implemented in the C + + language and Java packages. It should be clear that MQTT is more suitable for device terminals and mobile app socket communication, but not for browser use. If you want to support browser applications, you also need to add similar websocketservlet technology to provide support to the browser, when MQTT is encapsulated in the JS interface, and is called to complete the message push.

5.CoAP

Coap is synonymous with the Restricted application protocol (Constrainedapplication Protocol). It is based on the UDP protocol, that is, in the device terminal only need to implement the UDP protocol, without the need to implement a more complex TCP protocol. This kind of protocol is used relatively little. I also did not use C language simulation, it does not unfold.

More original embedded Linux and IoT development technology share please pay attention to the public number: embedded Penguin ring

IoT core protocol-message Push technology evolution