Forwarding Modes
A device can connect to and communicate with the platform. The device reports data to the platform using custom topics or product models. After the subscription/push configuration on the console is complete, the platform forwards messages about device lifecycle changes, reported device properties, reported device messages, device message status changes, device status changes, and batch task status changes to the application.
The platform supports four data forwarding modes: HTTP/HTTPS, AMQP, MQTT, and M2M communications.
- HTTP/HTTPS mode
- Subscription: You can use an application to call the platform APIs to configure and activate rules, or create a subscription task on the console for obtaining changed device service and management details. Service details involve device lifecycle, device data reporting, device message status, and device status. Management details involve software/firmware upgrade status and result. Related APIs: Create a Rule Triggering Condition, Create a Rule Action, and Modify a Rule Trigger Condition. The URL of the application, also called the callback URL, must be specified during subscription. For details, see How Do I Obtain the Callback URL When Calling the Subscription API? .
- Push: After a subscription is successful, the platform pushes the corresponding change to a specified callback URL based on the type of data subscribed. (For details on the pushed content, see Data Transfer APIs.) If an application does not subscribe to a specific type of data notification, the platform does not push the data to the application even if the data has changed. The platform pushes data, in JSON format, using HTTP or HTTPS. HTTPS requires authentication and is more secure. Therefore, HTTPS is recommended.
For details, see HTTP/HTTPS Data Forwarding.
- AMQP mode
- Subscription: AMQP is short for Advanced Message Queuing Protocol. You can create a subscription task on the IoTDA console, or call platform APIs to configure and activate rules for obtaining changed device service and management details. Service details involve device lifecycle, device data reporting, device message status, and device status. Management details involve software/firmware upgrade status and result. Related APIs: Create a Rule Triggering Condition, Create a Rule Action, and Modify a Rule Triggering Condition. The AMQP message channel must be specified during subscription creation.
- Push: After a subscription is created, the platform pushes the corresponding change to the specified AMQP message queue based on the type of data subscribed. If an application does not subscribe to a specific type of data notification, the platform does not push the data to the application even if the data has changed. You can use the AMQP client to establish a connection with the platform to receive data.
For details, see AMQP Data Forwarding.
- MQTT mode
- Subscription: You can call platform APIs to configure and activate rules for obtaining the changed device service and management details. Service details involve device lifecycle, device data reporting, device message reporting, and device status. Management details involve software/firmware upgrade status and result. Related APIs:Create a Rule Triggering Condition, Create a rule action, and Modify a Rule Triggering Condition. The topic for receiving push messages must be specified during subscription creation.
- Push: After a subscription is created, the platform pushes the corresponding change to the specified topic based on the type of data subscribed. If an application does not subscribe to a specific type of data notification, the platform does not push the data to the application even if the data has changed. You can use the MQTT client to establish a connection with the platform to receive data.
For details, see MQTT Data Forwarding.
- M2M communications
- Subscription: You can create rules on the console or call the platform APIs to configure and activate rules for obtaining messages reported by devices from the platform. Related APIs: Create a Rule Trigger Condition, Create a Rule Action, and Modify the Rule Triggering Condition. Device subscription supports only message reporting.
- Push: After the subscription is successful, the platform pushes messages reported by devices to the specified MQTT topic. After devices are connected to the platform, you can subscribe to the topic to receive data for inter-device message communications.
For details, see M2M Communications.
Data Forwarding Mode |
Application Scenario |
Advantage |
Restrictions |
---|---|---|---|
HTTP/HTTPS subscription/push |
An application functions as the server and passively receives messages from the platform. |
- |
The traffic control limit is 800 TPS per second. HTTP/HTTPS is not recommended for large-traffic push. |
AMQP subscription/push |
An application functions as the client and proactively pulls messages from the platform or passively receives messages from the platform by means of listening. |
Data can be obtained proactively. |
For details, see Connection Specifications. |
MQTT subscription/push |
An application functions as a client and can receive messages from IoT cloud services through subscription. |
- |
For details, see Constraints. |
M2M communications |
|
Communications among devices are supported. |
For details, see Overview. |
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot