IoTセッションの継続時間

Linuxボックスが測定値をAWS-RDBMSに送信します。Pythonスクリプトは、データベースにデータをアップロードするのに十分な時間だけ接続を開いたり閉じたりします（セッションは更新後すぐに閉じられます）。代わりに、ボックスがデータベースへの無期限のセッションを開き、RDBMSを更新します。インターネット接続が失敗した場合の問題は不明であり、不安定なインターネット接続に直面したときの接続の「持続性」の程度が不明です。大規模な場合、RDBMSにデータをアップロードする数百の測定ボックスが存在する可能性があります。

Python IoTセッションの接続時間に関するベストプラクティスは何ですか？データの送信後にセッションを閉じるのがベストプラクティスですか？データが送信された後に開始するアイドル時間を定義する場合があります。アイドル時間が事前定義された時間を超えた場合は、チャネルを閉じます。ベストプラクティスの背後にある理由の説明については、ボーナス。

おそらくこの質問はプラットフォームに依存していますか？つまり、RDBMS対AWS Greengrass？

ここでIoTがパーティーにもたらす変数は、少なくとも規模とエネルギーです。また、セキュリティ/回復力は、この質問が5年前に回答された方法と比較して、さまざまな制約を受けると考えるかもしれません。SO に関する「根本的な」質問はすでに7年前のものであり、あまり人気がありません。

トランザクションの頻度と、認証された接続を設定するコストは、データ帯域幅とエネルギーコストの両方の点で、おそらく主要な要因です。

接続を開いたままにしておくとコストがかかりますか？より平凡な「open-use-close」と比較して、「ほとんど永続的な」接続を管理するには、どれだけ多くの労力が必要ですか？リソースの競合が最も速くなるのはどのアプローチですか（製品の大規模な拡張が計画されている場合）。

将来、コード/プロトコルをネットワークのエッジにさらに移行する（またはクラウド機能をエッジに近いところに移行する）可能性はありますか？これらの潜在的な移行によって制約が変更される場合や、潜在的なソフトウェアへの投資を延期したい場合があります。

あなたはIOTのセッションを使用しているが、これはある*ないよう、Googleでとの多くの、多くの、多くの回答があり、IOTの質問、単に一般的なソケットの質問、およびスタックオーバーフローが。

基本的には、「正しい」答えはありません。状況を検討するだけで済みます。

一般的に言えば、「すべてのトランザクションの後に閉じる」を実装する方が簡単です。「おっと、現在開いているセッションが予期せず閉じられただけ」のコードはそれほど必要ありません。それは私がいつも取っているアプローチであり、産業界で最も頻繁に使用されているのを見てきました。

ただし、頻繁にパケットを送信する必要がある場合（サイズは重要ではなく、頻度だけが重要です）、すべてのパケットの後に閉じて再度開くというオーバーヘッドがパフォーマンスの問題につながる可能性があります。

あなたはあなたのお金を支払い、あなたはあなたの選択をします:-)