> For the complete documentation index, see [llms.txt](https://docs.fubogroup.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.fubogroup.com/natopikku/sesshontoqos.md).

# セッションとQoS

クライアントがブローカーに接続するとき、それは次のいずれかを使用して接続できます

* 非永続的な接続（クリーンセッション）または
* 持続的な接続

非永続的な接続では、ブローカーはクライアントのサブスクリプション情報や未配信メッセージを保存しません。

このモードは、クライアントがメッセージを公開するだけの場合に理想的です。

持続的な接続を使用して耐久性のあるクライアントとして接続することもできます

このモードでは、ブローカーはクライアントのサブスクリプション情報と未配信メッセージを保存します。

> ブローカーがクライアントのセッション情報を保存するためには、クライアントIDを使用する必要があります。

注意：クライアントに配信されたメッセージはブローカーから削除されます。メールメッセージが保存されるようには保存されません。

クライアントがブローカーに接続する際、永続的な接続が必要かどうかを示すために、フラグ（clean\_sessionフラグ）を使用します。

> しかし、サービスの品質や加入者と発行者の影響により、すべてのメッセージが配信用に保存されるわけではないことを理解することが重要です。

この例では、clean\_sessionフラグと品質保証設定がメッセージ配信に与える影響を見ていきます。

## 例の概要と目標

この例では、2つのクライアント接続を作成するPythonスクリプトを使用します。

一方の接続がトピックを購読し、もう一方の接続がそのトピックに対して公開します。

目的は、購読者が何らかの理由で接続が切断された場合に公開されたメッセージに何が起こるかを確認することであり、 `clean_session` フラグとQOS 設定がメッセージ配信にどのように影響するかを見ることです。

 **基本的なプロセス**

1. クライアントをclean\_sessionフラグを適切に設定して初期化します
2. トピックをQOS 設定で購読する
3.  切断します。
4. クライアントがサブスクライブしたトピックにQOSを設定して公開します。
5.  クライアントを再接続
6. 受信したメッセージをメモしてください

## Pythonクライアント設定

クリーンセッションフラグは、4つのオプショナルパラメーターを取るクライアントコンストラクターで設定されます。デフォルト値は以下の通りです：

```python
Client(client_id=””, clean_session=True, userdata=None, protocol=MQTTv311, transport=”tcp”)
```

スクリプトでクライアントインスタンスを作成するには：

```python
client= paho.Client("Python1",False) #create client object persistent connection
```

 翻訳テキスト：

```python
client= paho.Client("Python1",True) #create client object clean seesion
```

###  テスト1

*  clean\_session = True,
* 公開と購読のデフォルトQOS（サービス品質）は0です

予想される結果：ブローカーはメッセージを保存すべきではないため、メッセージは受信されません。

実際の結果：ブローカーがメッセージを保存していなかったため、再接続時にメッセージは受信されませんでした。

 スクリーンショット：

[![clean-session-1](https://github.com/Fubo-Group/docs/raw/main/images/clean-session-1.jpg)](https://github.com/Fubo-Group/docs/blob/main/images/clean-session-1.jpg)

###  試験 2

*  clean\_session = False,
* 公開と購読のデフォルトQOS（サービス品質）は0です

予想される結果：メッセージが受信される。

実際の結果：再接続時にメッセージは受信されませんでした

コメント 重要なのは、clean\_sessionフラグをFalseに設定するだけでなく、QOSを1 以上でパブリッシュおよびサブスクライブする必要があることです。

しかし、サブスクリプション情報はブローカーによって記憶されているため、クライアントは再度サブスクリプションする必要はありません。

 スクリーンショット：

[![clean-session-2](https://github.com/Fubo-Group/docs/raw/main/images/clean-session-2.jpg)](https://github.com/Fubo-Group/docs/blob/main/images/clean-session-2.jpg)

###  テスト 3

*  clean\_session = True, 翻訳テキスト：
* 公開と購読 QoS（品質保証）= 1

再接続時にメッセージが受信されないことが予想されます。

実際の結果：clean\_sessionフラグがtrueの場合、再接続時にメッセージは受信されませんでした。

 スクリーンショット

[![clean-session-3](https://github.com/Fubo-Group/docs/raw/main/images/clean-session-3.jpg)](https://github.com/Fubo-Group/docs/blob/main/images/clean-session-3.jpg)

###  テスト4

*  clean\_session = False,
* 公開と購読 QoS（品質保証）= 1

予想される結果：再接続時にメッセージを受信すること。実際の結果：再接続時にメッセージを受信しました。

コメントクリーンセッションフラグはfalseで、公開と購読のQOSは0より大きいです。

[![clean-session-4](https://github.com/Fubo-Group/docs/raw/main/images/clean-session-4.jpg)](https://github.com/Fubo-Group/docs/blob/main/images/clean-session-4.jpg)

###

###  テスト 5

*  clean\_session = False,
* 送信 QOS（品質保証）= 0 と受信 QOS（品質保証）= 1

予惜結果：？ 実際の結果：再接続時にメッセージが受信されない

コメントクリーンセッションフラグはfalseですが、公開時のQOSは0より大きくありません

[![clean-session-5](https://github.com/Fubo-Group/docs/raw/main/images/clean-session-5.jpg)](https://github.com/Fubo-Group/docs/blob/main/images/clean-session-5.jpg)

以下の表は、QOS、クリーンセッションフラグ、および保持メッセージフラグが受信されるメッセージにどのように影響するかを示す要約です。

[![mqtt-qos-retain-clean-session-table](https://github.com/Fubo-Group/docs/raw/main/images/MQTT-qos-retain-clean-session-table.jpg)](https://github.com/Fubo-Group/docs/blob/main/images/MQTT-qos-retain-clean-session-table.jpg)

 デモスクリプト

## クリーンセッションとクライアントID

永続的な接続では、接続の詳細がクライアントIDに対して保存されるため、永続的な接続（クリーンセッションがFalse）を使用する場合、ランダムなクライアントIDを使用することはできません。

## 一般的な質問と回答

**Q: ブローカーはどれくらいのメッセージを保存しますか？**

* A: これはブローカーの設定です。mosquittoブローカーのデフォルトは100です - 設定はmax\_queued\_messagesのカウントです。

**Q: クライアント接続を非永続的にリセットするにはどうすればいいですか？**

* A: 再接続するとセッションがクリーンに設定されます（True）

##  要約

MQTTは、電子メールのようなサービスと同じ方法でメッセージを保存しませんが、特定の状況下ではメッセージを保存します。

発行者と購読者のQOSによって、それらが保存されるかどうかが決まります。

しかし、購読者に受信され、認識されると、ブローカーはクリーンセッションとQOS 設定に関係なく、それらを直ちに削除します。