MQTT (Message Queuing Telemetry Transport)
MQTT stands for Message Queuing Telemetry Transport. It is a lightweight messaging protocol suitable for situations where clients require a small code footprint and need to connect to unreliable networks or networks with limited bandwidth resources. It is primarily used for machine-to-machine (M2M) communication or Internet of Things (IoT) type connections.
1. History of MQTT
MQTT was originally created by Dr. Andy Stanford-Clark and Arlen Nipper in 1999. The initial purpose of this communication method was to allow monitoring devices used in the oil and gas industry to send their data to remote servers. In many cases, these monitoring devices were used in remote areas where establishing any form of landline, wired connection, or radio transmission connection would be difficult, if not impossible. At that time, the only option for such situations was satellite communication, which was very expensive and charged based on the amount of data used. There were thousands of sensors in the field, and the industry needed a communication method that could provide sufficiently reliable data for use while using minimal bandwidth.
MQTT was standardized as open-source in 2013 and is managed by the Organization for the Advancement of Structured Information Standards (OASIS). OASIS still manages the MQTT standard.
2. MQTT Message Architecture
MQTT minimizes its transmission through a tightly defined small message structure. Each message has a fixed header of only 2 bytes. Optional headers can be used but will increase the size of the message. The message payload is limited to only 256 MB. Three different Quality of Service (QoS) levels allow network designers to choose between minimizing data transmission and maximizing reliability.
-
QoS 0 – Provides the least amount of data transmission. At this level, each message is sent to subscribers only once, with no acknowledgment required. It is not possible to know whether the subscriber received the message. This method is sometimes referred to as “fire and forget” or “at most once delivery.” Since this level assumes the transmission is complete, messages are not stored for delivery to disconnected clients when they reconnect later.
-
QoS 1 – The broker attempts to deliver the message and then waits for an acknowledgment response from the subscriber. If acknowledgment is not received within a specified time, the message is sent again. With this method, if the broker does not receive the subscriber’s acknowledgment in time, the subscriber may receive the message multiple times. This is sometimes referred to as “at least once delivery.”
-
QoS 2 – The client and broker use a four-step handshake to ensure that the message is received and only received once. This is sometimes referred to as “exactly once delivery.”
For scenarios where communication is reliable but limited, QoS 0 may be the best choice. For scenarios where communication is unreliable but connection resource limitations are not significant, QoS 2 may be the best choice. QoS 1 provides a solution that balances both, but requires the application receiving the data to know how to handle duplicates. For QoS 1 and QoS 2, messages are stored or queued for clients that are offline and have established persistent sessions. Once the client comes back online, these messages (according to the appropriate QoS level) will be resent.
PdM (Predictive Maintenance)
Predictive maintenance is a monitoring strategy for an organization’s physical assets aimed at detecting potential future problems and taking corrective actions before components fail. The types of assets typically monitored include large and expensive equipment, such as field instruments and machines, as well as small but critical components like valves and fan belts.
1. What is Predictive Maintenance (PdM)?
Predictive maintenance systems are the practical application of predictive maintenance strategies. Predictive maintenance systems include sensors connected to field hardware, means integrated with industrial control systems to collect sensor data and execute corrective actions, and predictive analytics software used to analyze data and predict potential future equipment failures. At the core of predictive maintenance systems is a control center that schedules tasks for maintenance personnel.
Before organizations implement predictive maintenance policies, they must design a predictive maintenance plan (action plan). The predictive maintenance plan describes the assets to be maintained and identifies potential failure points under different operating conditions, known as failure modes.
Failure modes refer to the specific ways in which components may fail. Examples of failure modes include human error, corrosion, wear and tear, and metal fatigue. Failure modes can lead to failures such as misalignment of fan belts, pump seal failures, lubrication defects, and empty oil tanks. Components may have multiple potential failure modes.
2. In which fields is Predictive Maintenance applied?
Predictive maintenance systems are particularly important for the safe and reliable operation of assets in critical systems such as oil and gas, mining, aviation, and industrial manufacturing, as well as in nuclear power plants and utility providers.
Predictive maintenance systems are commonly used:
-
In industries with high-value assets that have high maintenance or replacement costs, or require specialized skills to maintain, such as in space stations
-
Where reliable predictions of failure modes such as electrical overload can be made
-
Where asset failures (such as power outages) can impact service delivery
-
In retrofitting environments
3. Why use Predictive Maintenance?
Predictive maintenance helps organizations:
-
Comply with safety regulations
-
Take preventive corrective actions on faulty equipment
-
Reduce operational costs
-
Enhance the health and performance of valuable assets
-
Minimize human error in determining when equipment needs maintenance
-
Minimize system downtime
-
Reduce resource waste
-
Plan maintenance around their production schedules
Ping
Ping is a command-line tool that is available on almost any operating system with network connectivity, serving as a means to test whether network devices are reachable.
The ping command sends requests over the network to a specific device. A successful ping results in the pinged computer returning a response to the originating computer.
1. What does Ping mean?
According to the author, the name Ping comes from sonar terminology. In sonar, a ping is a sound wave emitted to locate an object. If the sound hits an object, the sound wave will reflect, or echo, back to the source. By measuring the time and direction of the returning sound wave, the distance and location of the object can be determined.
Similarly, the ping command sends out echo requests. If the target system is found, the remote host will send back an echo response. The distance to the remote system (in hops) and the conditions in between (packet loss and response time) can be determined from the response. While the author of the ping utility states that the program name is simply based on the sound of sonar, others sometimes say that Ping is an acronym for Packet InterNet Groper.
2. How does it work?
The Ping utility uses echo request and echo reply messages from the Internet Control Message Protocol (ICMP), which is a fundamental part of any IP network. When the ping command is issued, an echo request packet is sent to the specified address. When the remote host receives the echo request, it responds with an echo reply packet.
By default, the ping command sends several echo requests, usually four to five. The result of each echo request is displayed, showing whether a successful response was received, how many bytes were received in the response, the time to live (TTL), and the time taken to receive the response, along with statistics about packet loss and round-trip time.
3. How to use Ping?
The Ping tool is most commonly used in troubleshooting. When trying to use applications or systems over the network, the most important thing to understand is whether there is an actual working connection. A series of ping commands can help identify where the problem lies.
Quickly pinging an IP address can confirm that the system is on, there is a connection, and that the two machines can communicate with each other.
Ping 172.168.9.13If pinging by name and IP address is successful but the response time is too long, there may be routing, network speed, or congestion issues. Even if the ping operation is unsuccessful, it can provide valuable troubleshooting information.
If pinging by IP address is successful but fails by name, there is a name resolution issue. If the ping completely fails, you can try pinging other parts of the network to isolate the problem. Successfully pinging the default gateway confirms that the network connection is operational, but something is interfering with the connection to the remote system.
If you can successfully ping a remote system on the same subnet but cannot ping the target system itself, then the network connection of the remote host is worth questioning. If you cannot ping the default gateway but can successfully ping the loopback address (127.0.0.1), then you know that the network interface is working, but there is no connection to the network.
Ping Errors
If ping does not receive a response from the target host, most implementations of ping will not display anything or will show a timeout notification. The result may look like this, for example:
Pinging 121.242.124.9 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.NetFlow
NetFlow is a protocol used to collect, aggregate, and record network traffic data. NetFlow data provides a more granular view of bandwidth and network traffic usage compared to other monitoring solutions such as SNMP.
NetFlow was developed by Cisco and is embedded in the company’s routers and switches running Cisco IOS software, and has been supported on almost all Cisco devices since the release of Cisco IOS software version 11.1. Many other hardware manufacturers either support NetFlow or use alternative flow technologies such as jFlow or sFlow.
1. NetFlow Versions
There are technically ten different versions of NetFlow. However, several versions were released internally or never widely applied outside of specific hardware.
Version 5 is still widely used today because a large number of Cisco routers and switches were installed when it was the standard version. It added Border Gateway Protocol information and flow sequence numbers to NetFlow exports. It is only applicable to IPv4 flows.
| v1 | First implemented, now deprecated |
| v2 | Internal version, not publicly released |
| v3 | Internal version, not publicly released |
| v4 | Internal version, not publicly released |
| v5 | Still widely used, only applicable to IPv4 flows |
| v6 | No longer supported |
| v7 | Added support for Cisco Catalyst switches |
| v8 | Supports router-based NetFlow aggregation |
| v9 | Current version, template-based, supports IPv6 |
| v10 | Used for identifying IPFIX |
2. Use Cases for NetFlow
Network, User, and Application Monitoring
The most obvious use of NetFlow is network monitoring. NetFlow data provides detailed bandwidth usage information that can be segmented in various ways, including by user, client system, time, and application. Data reaching the NetFlow collector is almost real-time, allowing for specific granularity in monitoring and aggregating data to observe the bigger picture.
Network Planning
The ability to detect and respond to changes in network conditions is a valuable capability. Even better is the ability to foresee what is about to happen and proactively address any issues.
Capturing NetFlow data over long periods and analyzing trends in the data can provide early insights into network demands. Perhaps various applications running at the end of the month generate additional traffic that impacts network performance. In such cases, other high-bandwidth activities can be scheduled at different times of the month to prevent bottlenecks.
Additionally, NetFlow data can help determine when traffic growth has actually become too high for the current hardware to handle, providing ample time to purchase, install, and configure additional or faster routers and switches.
Usage-Based Billing and Reporting
By leveraging its ability to identify specific traffic flows (including their sources and the applications triggering them), NetFlow data can be analyzed for billing customers, internal cost allocation, or showing how much network is used by specific users, groups, or applications. With such detailed data collection, it is easy to adjust billing standards based on the time of day or application usage or total bandwidth.
Application Reporting and Profiling
NetFlow data can not only show the amount of traffic generated by applications but also when and for whom. NetFlow can determine whether an application is optimized for the accounting group but generates a lot of traffic for different departments.
Security Analysis
NetFlow can assist with network security. Is a user suddenly generating a large amount of traffic that is not typically needed for their work? Perhaps their account has been compromised? NetFlow data can quickly reveal anomalies in network traffic, whether it is a worm trying to spread, malware trying to contact a control server, or a disgruntled employee copying sensitive company data.
Source: Paessler (PRTG) Official Website: https://www.paessler.com/
Scan to add corporate WeChatLearn more about software information at home and abroadScan the QR code to follow us
If you have any product inquiries, please feel free to contact us: 021—58996110
We will provide corresponding software version recommendations based on your needs
Scan the QR code to enter the mini program
One-stop query and procurement platform
