サイトアイコン やさしいネットワークとセキュリティ

MQTT(メッセージ交換方式・QoSレベル)【ネットワークスペシャリスト試験 平成30年度 秋期 午後2 問1 No.2】

ネットワークスペシャリスト試験 平成30年度 秋期 午後2 問1 No.2

【出典:ネットワークスペシャリスト試験 平成30年度 秋期 午後2 問1(一部、加工あり)】

【MQTTを使ったメッセージ交換方式】
 Wさんは、MQTTを使ったメッセージ交換方式を調査した。
 このメッセージ交換方式では、固定ヘッダ、可変ヘッダ及びペイロードから構成されたMQTTコントロールパケットを使う。MQTTコントロールパケットの種別を表1に示す。


 MQTTを使ったメッセージ交換方式の通信シーケンス例を図2に示す。


 図2中の通信シーケンスでは、配信元から複数の配信先へメッセージが配信されている。通信シーケンスの説明を次に示す。

 PUBLISHを使ったメッセージ送信では、QoSレベルを使って送達確認手順を指定する。QoSレベルとメッセージ送信の通信シーケンスを図3に示す。


 図3中の通信シーケンスの説明を次に示す。

 次にWさんは、Xシステムの2種類のメッセージ交換について、トピック名、QoSレベル、及び配信元と配信先を整理した。
 Xシステムのメッセージ交換を図4に示す。


 図4の説明を次に示す。

 Wさんは、1台の業務サーバが6,000台のデバイスの設定を変更する場合の送信時間(T)を概算した。
 WさんがTの概算に用いた通信シーケンスを図5に示す。


 図5中の装置の処理時間を無視し、図5中のt1及びt2は、それぞれの装置間のRTT(Round Trip Time)の2倍に等しいとし、LANのRTTを20ミリ秒、WANのRTTを200ミリ秒とすると、Tは次のように概算できる。
 T=m×t1+t2=6,000×2×20+2×200(ミリ秒)≒ 4(分)
 この概算を基に、Wさんは、次のように報告することにした。

図3中のQoSレベルが0の場合のメッセージ送信について、TCPの再送機能だけではメッセージの消失が防げないのはどのような場合か。45字以内で具体的に答えよ。:TCPの送信処理中に、デバイスの電源断などでTCPコネクションが解放された場合

 QoSレベルが0の場合のメッセージ送信について、「QoSレベルが0の場合、MQTT層におけるPUBLISHの送達確認は行わない。TCP層による送達確認だけが行われる」とあります。
 また、MQTT通信におけるTCPについて、「クライアントは、サーバのTCPポート8883番にアクセスし、TCPコネクションを確立する。このTCPコネクションは、メッセージ交換の間は常に維持される」とあります。
 したがって、TCPコネクションが維持される場合は、TCPの再送機能でメッセージが消失することはないと考えられます。
 逆に、TCPコネクションが開放されてしまうと、再送機能も使えなくなり、メッセージが消失する場合があることになります。
 それを裏付けるように、QoSレベルが2の場合には「TCPコネクションが切断された場合のために、PUBLISH及びPUBRELは送信者によって保存され、送信者から受信者への再送に利用される」とあります。
 TCPコネクションが開放される場合とはどのような場合でしょうか。
 これについては、問題文のもう少し先に、「交換サーバからデバイスDiへのPUBLISH送信中にデバイスDiが電源断などで非稼動になった場合、そのPUBLISHは、交換サーバの中に保存され、稼働再開後に再送される」とあります。
 デバイスが電源断などで非稼動になるとTCPコネクションが開放されてしまい、再送機能が使えなくなり、メッセージが消失されてしまいます。

③について、PUBRELを受信するまで、メッセージの処理を保留する目的を、20字以内で述べよ。:メッセージの重複を防止する。

 図3の通信シーケンスをよく見ると、送信者と受信者でそれぞれ送達確認ができてから処理を開始したり完了させたりしています。
 また図3の注記2には、「QoSレベルが2の場合、受信者は、メッセージの処理を開始した以降に受信したPUBLISHは、パケットIDの重複にかかわらず新しいパケットとみなす」とあります。
 この説明からすると、もしもPUBRELを受信する前にメッセージを処理するとした場合は、送信者から同じパケットIDのメッセージが再送されると新たに処理を開始してしまうことが分かります。
 PUBLISH、PUBRELの保存や、PUBREC、PUBCOMPのやり取りは、このようなメッセージの重複(に伴う処理)を防止するためにあります。

オ:SUBSCRIBE、カ:config/Di

 項番1は業務サーバがクライアント(配信元)で、デバイスDiがクライアント(配信先)になります。
 クライアントの事前動作について、図2の通信シーケンスで「配信先となるクライアントは、サーバにSUBSCRIBEを送信し、購読対象のメッセージを、トピック名を使って通知する」と説明されています。
 購読対象のメッセージのトピック名は、項番1では「config/Di」になります。

キ:デバイスDi、ク:交換サーバ

 送信者である交換サーバ、受信者であるデバイスDiとのやり取りで、PUBLISH送信中に非稼動になる方は、デバイスDiと考えられます。
 また、その時にPUBLISHを保存するのは送信者である交換サーバになります。 

ケ:業務サーバ

 項番2では、受信者は業務サーバとエッジサーバです。
 「安定した稼働が見込める」とは、電源停止などで非稼働状態にならないことであり、サーバが該当します。
 一方、デバイスは顧客の工場内にあり、使用していないデバイスは電源停止などで非稼働状態になる可能性があります。

コ:業務サーバ交換サーバ

 「同一拠点に設置」とあるのは、この概算において二つの装置間がLANにあることを示します。
 LANのRTTである20ミリ秒を使っているのは「t1」になりますので、図5から二つの装置は業務サーバと交換サーバになります。
 別の解き方として、図5の装置のうち、図1の構成例で「同一拠点に設置」しているものはどれかを探す方法があります。
 それによりX社の中に業務サーバと交換サーバが該当します。

モバイルバージョンを終了