7
8

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

MQTTは弱ネットワーク環境の表現について

Last updated at Posted at 2016-05-11

Background

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

弱ネット環境の表現

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

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

TCP接続の3回 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 はこの状況に対応するため設計された技術です。

Image_thumb.png

弱ネット環境で

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

  • 共通
    • 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はまた1回目のhandshackのとき、UDP はすでにデータを送ってしまった。
  • 三回handshack の間に、UDPは一回完全的なデータ送信(ping-pong)を完成可能。

プロトコル面

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

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

Next : webRTC x IoT

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

7
8
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
7
8

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?