客戶端和伺服器必須儲存會話狀態才能提供服務質量保證。客戶端和伺服器必須在會話的整個持續時間 [mqtt-4.1.0-1]中儲存會話狀態。 會話必須至少持續有效的網路連線[mqtt-4.1.0-2]。
保留的訊息不構成伺服器中會話狀態的一部分。伺服器應該保留此類訊息，直到客戶端刪除為止。
客戶端和伺服器實現的儲存功能當然在容量方面具有限制，並且可能受管理策略的約束，例如在網路連線之間儲存會話狀態的最大時間。作為管理員操作的結果，可以丟棄儲存會話狀態，包括對定義條件的自動響應。這具有終止會話的效果。這些操作可能由資源限制或其他操作原因引起。謹慎地評估客戶端和伺服器的儲存功能以確保它們足夠。
硬體或軟體故障可能導致客戶端或伺服器儲存的會話狀態丟失或損壞。
伺服器客戶端的正常操作可能意味著儲存狀態由於管理員操作，硬體故障或軟體故障而丟失或損壞。管理員操作可以是對已定義條件的自動響應。這些操作可能由資源限制或其他操作原因引起。例如，伺服器可能基於外部知識確定一條或多條訊息不能再傳遞給任何當前或未來的客戶端。
mqtt使用者應評估mqtt客戶端和伺服器實現的儲存功能，以確保它們足以滿足其需求。
例如，希望收集電表讀數的使用者可能會決定他們需要使用qos 1訊息，因為他們需要保護讀數免受網路上的丟失，但是他們可能已經確定電源足夠可靠以使資料在客戶端和伺服器可以儲存在易失性儲存器中，而不會有太大的丟失風險。
相反，停車計費器支付應用程式提供商可能決定不存在支付訊息可能丟失的情況，因此他們要求在通過網路傳輸之前將所有資料強制寫入非易失性儲存器。
mqtt協議需要乙個底層傳輸，它提供從客戶端到伺服器和伺服器到客戶端的有序，無損的位元組流。
用於承載mqtt 3.1的傳輸協議是[rfc793
]中定義的tcp / ip。tcp / ip可用於mqtt 3.1.1。
在以下也是合適的：
·tls [rfc5246]
·websocket [rfc6455]
tcp埠8883和1883分別在iana註冊，用於mqtt tls和非tls通訊。
諸如使用者資料報協議 （udp）之類的無連線網路傳輸本身並不合適，因為它們可能丟失或重新排序資料。
IOT MQTT協議 控制資料報 CONNACK
connack資料報是伺服器響應從客戶端收到的connect資料報傳送的資料報。從伺服器傳送到客戶端的第乙個資料報必須是connack資料報 mqtt 3.2.0 1 如果客戶端在合理的時間內沒有從伺服器收到connack資料報，則客戶端應該關閉網路連線。合理 的時間量取決於應用程式的型別和通訊基礎...
IOT MQTT協議 控制資料報 PING
pingreq資料報從客戶端傳送到伺服器。它可以用於 在沒有任何其他控制資料報從客戶端傳送到伺服器的情況下，向伺服器指示客戶端處於活動狀態。請求伺服器響應以確認它處於活動狀態。練習網路以指示網路連線處於活動狀態。此資料報用於keep alive處理，有關詳細資訊，請參閱第3.1.2.10節。圖3.3...
WCF 第五章 行為 實現事務 操作行為
有兩個場景一般用作事務的參考。多步驟商業過程是典型跨度分，天，月的長時間執行過程。它們可以涉及多個組織和基於人的工作流。短期執行事務是那些在幾秒鐘完成並很少有外部依賴的商業操作。儘管它們都有定義的很好的介面和確定的工作流，它們是根本不同的事物。wcf支援短期執行的事務。它通過借助.net和windo...