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の
timeoutkeepaliveは少し伸ばす。
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 はこの状況に対応するため設計された技術です。
弱ネット環境で
まず、ネットの使用量を少し計算してみる。
- 共通
- Ethernet Head at least 18 bit
- IP 固定 Head 20 bit
- キャリア費用計算 8 bit
- 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ベースで実装された、リアルタイム性が非常に良いです。次に詳しく話す。