From 8335161c6fd9dcd645cbb7b69e715ff3e9955ca7 Mon Sep 17 00:00:00 2001 From: Steve Kim Date: Wed, 7 Dec 2022 15:47:10 -0800 Subject: [PATCH] MQTT5 Userguide Update --- README.md | 1 + documents/{MQTT5.md => MQTT5_Userguide.md} | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) rename documents/{MQTT5.md => MQTT5_Userguide.md} (98%) diff --git a/README.md b/README.md index 07aec71c..34e7da55 100644 --- a/README.md +++ b/README.md @@ -26,6 +26,7 @@ to Python by the `awscrt` package ([PyPI](https://pypi.org/project/awscrt/)) ([G * [Getting Help](#Getting-Help) * [FAQ](./documents/FAQ.md) * [Giving Feedback and Contributions](#Giving-Feedback-and-Contributions) +* [MQTT5 User Guide](./documents/MQTT5_Userguide.md) ## Installation diff --git a/documents/MQTT5.md b/documents/MQTT5_Userguide.md similarity index 98% rename from documents/MQTT5.md rename to documents/MQTT5_Userguide.md index b80b5b49..b984f6c0 100644 --- a/documents/MQTT5.md +++ b/documents/MQTT5_Userguide.md @@ -276,4 +276,5 @@ Below are some best practices for the MQTT5 client that are recommended to follo * When creating MQTT5 clients, make sure to use ClientIDs that are unique! If you connect two MQTT5 clients with the same ClientID, they will Disconnect each other! If you do not configure a ClientID, the MQTT5 server will automatically assign one. * Use the minimum QoS you can get away with for the lowest latency and bandwidth costs. For example, if you are sending data consistently multiple times per second and do not have to have a guarantee the server got each and every publish, using QoS 0 may be ideal compared to QoS 1. Of course, this heavily depends on your use case but generally it is recommended to use the lowest QoS possible. * If you are getting unexpected disconnects when trying to connect to AWS IoT Core, make sure to check your IoT Core Thing’s policy and permissions to make sure your device is has the permissions it needs to connect! -* For **Publish**, **Subscribe**, and **Unsubscribe**, you can check the reason codes in the returned Future to see if the operation actually succeeded. \ No newline at end of file +* For **Publish**, **Subscribe**, and **Unsubscribe**, you can check the reason codes in the returned Future to see if the operation actually succeeded. +* You MUST NOT perform blocking operations on any callback, or you will cause a deadlock. For example: in the on_publish_received callback, do not send a publish, and then wait for the future to complete within the callback. The Client cannot do work until your callback returs, so the thread will be stuck. \ No newline at end of file