機能リクエストは問題に関連していますか?
offline publishing
がデフォルトで有効になっているかどうかはわかりませんでした。
希望するソリューションを説明してください
python sdk v1の場合と同様に、 configureOfflinePublishQueueing
メソッドのようなものが表示されると便利です。
検討した代替案を説明してください
メッセージが公開されているかどうかに関係なく、自分のキューを維持します。
追加のコンテキスト
https://github.com/aws/aws-iot-device-sdk-python/blob/master/samples/basicPubSub/basicPubSub.py#L101
現在の動作は次のとおりです。
これには一貫性がないことを理解しています。 ユーザーはおそらく次のいずれかを望んでいます。
1)メッセージは、送信できるようになるまで常にキューに入れられます
2)クライアントがオフラインの場合、またはメッセージが送信される前にオフラインになると、メッセージは失敗します。
私たちはこれを変えることを非常に積極的に評価しています。 私はこの問題を開いたままにし、変更を加えた(または現在の動作を形式化した)ときに更新します
今すぐ運命を完全に制御したい場合は、一度に1つのメッセージをクライアントに送信する独自のキューを作成できます。 成功した場合は、次を送信します。 失敗した場合は、再試行してください。 これにより、メッセージをキューに入れることができる時間の長さ、キューに入れるメッセージの数などを完全に制御する機会も得られます。
今すぐ運命を完全に制御したい場合は、一度に1つのメッセージをクライアントに送信する独自のキューを作成できます。 成功した場合は、次を送信します。 失敗した場合は、再試行してください。 これにより、メッセージをキューに入れることができる時間の長さ、キューに入れるメッセージの数などを完全に制御する機会も得られます。
こんにちは@graebm。 どうしますか? 私のデバイスがメッセージを公開しているが、それがオフラインである場合、それらのメッセージはsomsのようなキューにとどまると思いますか? このキューにアクセスして、まだ公開されていない場合に特定のメッセージをキューから削除する方法はありますか?
ありがとう
@samvandammeは、サービス品質(qos)を最大で1回(0)に設定できます。
qos=mqtt.QoS.AT_MOST_ONCE
同じデバイスで、公開しているトピックにサブスクライブします。 次に、メッセージが送信されることを確認するために、公開したメッセージのリストを維持します。 トピックに関するメッセージを受信した場合にのみ、それらを削除してください。
現在の動作は次のとおりです。
- クライアントがオフラインかオンラインかに関係なく、公開されたすべてのメッセージは送信前にキューに入れられます。
- クライアントがオンラインになると(またはすでにオンラインになっている場合)、キューからのメッセージが順番に送信されます。
- ただし、クライアントがオンラインでオフラインになった場合、その時点で、キュー内のすべてのPUBLISHおよびSUBSCRIBEがキャンセルされます。
これには一貫性がないことを理解しています。 ユーザーはおそらく次のいずれかを望んでいます。
- メッセージは、送信できるようになるまで常にキューに入れられます
- クライアントがオフラインの場合、メッセージは失敗するか、メッセージが送信される前にオフラインになります。
私たちはこれを変えることを非常に積極的に評価しています。 私はこの問題を開いたままにし、変更を加えた(または現在の動作を形式化した)ときに更新します
今すぐ運命を完全に制御したい場合は、一度に1つのメッセージをクライアントに送信する独自のキューを作成できます。 成功した場合は、次を送信します。 失敗した場合は、再試行してください。 これにより、メッセージをキューに入れることができる時間の長さ、キューに入れるメッセージの数などを完全に制御する機会も得られます。
では、デバイスが一定期間オフラインになるのを処理するために推奨されるアプローチは何ですか?
5秒ごとにメッセージを送信するデバイスがあり、デバイスがオンラインであり、メッセージがAWS IoTCoreに到達していると仮定します。 その後、デバイスは10分間接続を失い、その後再びオンラインになります。 10分間のオフライン期間中に公開しようとしたすべてのメッセージはどうなりますか? デバイスが再びオンラインになるとすぐに公開されますか、それとも永久に失われますか?
最初のいくつかのメッセージは、SDKが切断されていないことに気付かないうちに失われます。 以降のすべてのメッセージはキューに保存され、接続が復元されたときに送信されます。
これをテストすると、毎秒メッセージを送信するpubsubを使用すると、最初の5つのメッセージが失われました。 したがって、ほとんどの場合、メッセージを1つだけ失うことになります。
これについても詳しく理解したいと思います。 上記のように、オフライン中に公開されたメッセージはキューに入り、接続がオンラインに戻ったときに公開されます。
オフラインキューにはいくつのメッセージが保存されていますか? 以前のSDKでは、無限、なし、または指定された量を選択できました。 これに関するドキュメントが見つかりません。 無限のように聞こえますが、知りたいのですが。 以前のSDKでは、キューの一番上または一番下からドロップすることもできました。 それは今可能ですか?
以前のSDKでは、キューに保存されているメッセージのドレインレートを選択することもできました。 これは今設定可能ですか? そうでない場合、値は何ですか?
最も参考になるコメント
これについても詳しく理解したいと思います。 上記のように、オフライン中に公開されたメッセージはキューに入り、接続がオンラインに戻ったときに公開されます。
オフラインキューにはいくつのメッセージが保存されていますか? 以前のSDKでは、無限、なし、または指定された量を選択できました。 これに関するドキュメントが見つかりません。 無限のように聞こえますが、知りたいのですが。 以前のSDKでは、キューの一番上または一番下からドロップすることもできました。 それは今可能ですか?
以前のSDKでは、キューに保存されているメッセージのドレインレートを選択することもできました。 これは今設定可能ですか? そうでない場合、値は何ですか?