Background

MQTT 3.1 は弱ネット環境（2G/3Gなど）の表現は良くないため、いろいろ反省したいと思う。

弱ネット環境の表現

携帯は弱ネット環境でpackageの紛失率が高くので、MQTT Serverとの接続成功率が低いです。HTTPのモデルと比べると、実際HTTPの成功率はMQTTより高くになる。

携帯端末は毎回TCP切断された後、直ぐTCP再接続を行う。接続成功する場合、今まで接続のstepは改めて踏み、CONNECTや、SUBSCRIBLEなど。外から見ると、このプロセスは特に問題がないと見えるが、弱ネット環境でconnect -> subscribleのコストが高いです。

TCP接続の３回 handshackから、subscribleコマンドを送るまで、TCP stack毎回データを受けた後のACKも考えて、
一回接続のため、server <-> client の間で、少なくでも10回以上な通信を行った。

その原因です、もともと不安定の弱ネット環境で、この負担はさらに重くになる。下記何れのstepで突発性の接続失敗を発生する可能がある。

TCP接続できない、またはhandshack時失敗、handshackした後のpackage を紛失、clientのtimeout時間が短いすぎ。
TCP接続後、CONNECT送った後、TCPのACK packageを受け取れない、またはclientのtimeout時間が短い過ぎで、sub失敗。
SUBSCRIBLEを送ったが、サーバーまで届けないとか、package紛失とかなど、sub失敗
SUBSCRIBLEを発送成功したが、キャリアネットによる、ネットワーク切断、timeoutなど。

TCPは無感知的な接続です。切断されたの両方に対して、すぐ分かることができないです、でないと、keepaliveの心拍方式は入らないです。

現在業務中のLogから軽く見ると、CONNECTだけの状況で、一日約数百万回の感じです。

少し改善

業務の改善

clientのtimeout``keepaliveは少し伸ばす。

The Keep Alive timer, measured in seconds, defines the maximum time interval between messages received from a client.
It enables the server to detect that the network connection to a client has dropped, without having to wait for the long TCP/IP timeout. 
The client has a responsibility to send a message within each Keep Alive time period. 
In the absence of a data-related message during the time period, the client sends a PINGREQ message, which the server acknowledges with a PINGRESP message.

If the server does not receive a message from the client within one and a half times the Keep Alive time period (the client is allowed "grace" of half a time period), it disconnects the client as if the client had sent a DISCONNECT message. 
This action does not impact any of the client's subscriptions. See DISCONNECT for more details.

retainを利用して、接続成功することを検知する。
will を利用して、ある程度ネットワーく切断状況を判断する。

MQTT-SN

TCP/IPなどサポートしていないデバイス環境について、MQTTは使えないです。例えば、センサー系やなど。よう使うのはIEEE 802.15.4に従って低速無線ネットワーク(LR-WPAN)とか、UDP packageなど。

MQTT-SN はこの状況に対応するため設計された技術です。

弱ネット環境で

まず、ネットの使用量を少し計算してみる。

共通
TCP
- TCP Head 20 bit
- TCP Data Head at least 66 bit
UDP
- UDP Head 8 bit
- UDP Data Head at least 54 bit

つまり、UDPの場合、TCPより12 bit少なくになる。

弱ネットで表現から見ると

ネットワーク到達可能状況で、TCPはまた１回目のhandshackのとき、UDP はすでにデータを送ってしまった。
三回handshack の間に、UDPは一回完全的なデータ送信（ping-pong）を完成可能。

プロトコル面

TCPは接続にたいして, status の管理とメンテのコストがあります。良く見えるのは　reset異常など。一回請求するデータは必ず一台サーバーで完成する。
UDPは無接続の特徴がある、一回請求するデータは復数のサーバーに分けることが可能。

まとめ、リアルタイム性、速やかに通信するたえ、UDPで考えで良いかも。状況による、MQTT/HTTP/UDPを混雑して利用することが良いかも。

Next : webRTC x IoT

なぜここでwebRTCで出す、webRTCはUDPベースで実装された、リアルタイム性が非常に良いです。次に詳しく話す。