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

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

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

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

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

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

クライアントは、サーバのTCPポート8883番にアクセスし、TCPコネクションを確立する。このTCPコネクションは、メッセージ交換の間は常に維持される。
クライアントはCONNECTを送信し、サーバはCONNACKを返信する。
配信先となるクライアントは、サーバにSUBSCRIBEを送信し、購読対象のメッセージを、トピック名を使って通知する。サーバはクライアントにSUBACKを返信し、購読要求を受け付けたことを通知する。
配信元クライアントは、PUBLISHを使ってサーバにメッセージを送信する。
メッセージを受信したサーバは、PUBLISHにに含まれるトピック名について購読要求を受け付けている全てのクライアントに、そのメッセージを送信する。

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

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

QoSレベルが0の場合、MQTT層におけるPUBLISHの送達確認は行わない。TCP層による送達確認だけが行われる。
QoSレベルが2の場合、MQTT層においてもPUBLISHの送達確認が行われる。MQTT層の送達確認の説明を次に示す。
- TCPコネクションが切断された場合のために、PUBLISH及びPUBRELは送信者によって保存され、送信者から受信者への再送に利用される。
- ③PUBLISHを受信した受信者は、メッセージの処理を始める前に送信者にPUBRECを送信し、その応答であるPUBRELを受信してからメッセージの処理を開始する。
- PUBRELを送信した送信者は、その応答であるPUBCOMPを受信してから、メッセージ送信を完了する。

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

　図4の説明を次に示す。

項番1では、デバイスDiは、あらかじめ（オ：SUBSCRIBE）を交換サーバに送信し、トピック名が（カ：config/Di）のPUBLISHが送信されるようにする。
項番1では、QoSレベルとして2が使用されている。交換サーバからデバイスDiへのPUBLISH送信中に（キ：デバイスDi）が電源断などで非稼動になった場合、そのPUBLISHは、（ク：交換サーバ）の中に保存され、稼働再開後に再送される。
項番2では、QoSレベルとして0が使用されている。これは、（ケ：業務サーバ）及びエッジサーバは安定した稼働が見込めるからである。

　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さんは、次のように報告することにした。

TCPコネクションが正常であれば、全デバイスへの設定情報の送信は4分間程度で完了する。
ただし、図1に示すように、（コ：業務サーバ、交換サーバ）は同一拠点に設置されている必要がある。

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

　QoSレベルが０の場合のメッセージ送信について、「QoSレベルが０の場合、MQTT層におけるPUBLISHの送達確認は行わない。TCP層による送達確認だけが行われる」とあります。
　また、MQTT通信におけるTCPについて、「クライアントは、サーバのTCPポート8883番にアクセスし、TCPコネクションを確立する。このTCPコネクションは、メッセージ交換の間は常に維持される」とあります。
　したがって、TCPコネクションが維持される場合は、TCPの再送機能でメッセージが消失することはないと考えられます。
　逆に、TCPコネクションが開放されてしまうと、再送機能も使えなくなり、メッセージが消失する場合があることになります。
　それを裏付けるように、QoSレベルが２の場合には「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社の中に業務サーバと交換サーバが該当します。