箱庭PDUアーキテクチャ(その2)


前回は、箱庭PDUアーキテクチャの全体像について整理しました。
今回は、その中でも「プロトコル層」にあたる部分について、
もう少し踏み込んで書いてみます。

これまでの箱庭PDUの説明

箱庭PDUって、この前の解説記事とかでの謳い文句は、

「箱庭のPDUは、箱庭アセットが互いに通信するためのデータ単位です。
 そして、このデータは、様々な通信プロトコルを介してデータ交換されます。」

でした。

これは、間違ってはいません
ただ、この説明だけでは、実装の視点が少し足りていませんでした。

箱庭PDUでは、
データそのものと データをどう運ぶか を、意識的に分けて考えています。

PDUの「データ定義」と通信は別物

箱庭PDUのデータ定義には、
​​ROS IDL (Interface Definition Language) を使っています。

ここで定義しているのは、

  • フィールドの型
  • 配列や構造体の構成
  • サービスやメッセージのインターフェース

といった、純粋にデータの形と意味だけです。

この段階では、

  • TCP で送るか
  • UDP で送るか
  • SHM で共有するか
  • WebSocket や Zenoh を使うか

といったことは、一切決まっていません。

「様々な通信プロトコルを介して」の正体

次に、箱庭PDUが実際にどのようにデータとして扱われるかを、
図で示します。

この図は、箱庭PDUが

  • アプリケーション内のデータ
  • 通信可能なバイナリデータ
  • そして再びアプリケーションのデータ

へと変換されていく流れを表しています。

プログラムデータ型とPDU定義

箱庭PDUのデータ定義は、
ROS IDL(Interface Definition Language) を使って記述されます。

ROS IDL で定義された PDU は、箱庭のツールを使うことで、

  • C++
  • C#
  • Python
  • JavaScript

といった、利用するプログラミング言語に応じたプログラムデータ型として自動生成されます。

バイナリ変換(encode / decode)

アプリケーション内部では、
PDUは単なる構造体やクラスとして扱われています。

しかし、そのままでは通信できないため、
別のプログラムに送る際には、
通信可能なバイナリデータへ変換する必要があります。

この変換処理が、

  • encode(送信側)
  • decode(受信側)

です。

ROS などの高級なフレームワークを使うと、
この変換は内部で自動的に行われますが、
箱庭では、この変換処理自体を明示的に分離しています。

なぜ変換処理を分離しているのか

理由は単純で、
通信方式の選択と、データ表現を切り離すためです。

箱庭では、

  • どの通信プロトコルを使うか
  • TCP / UDP / SHM / WebSocket / Zenoh
  • あるいは、単なるバッファ共有か

といった点を、
ユーザが自由に選択できるようにしています。

そのため、
「データをどう表現するか」と
「データをどう運ぶか」は、
完全に別の責務として扱います。

通信プロトコルは最後に選ばれる

バイナリデータに変換されたあとは、
そのデータを既存の通信ライブラリに流すだけです。

この通信ライブラリ、
すなわち 通信プロトコル についても、
箱庭ではユーザに選択の自由を委ねています。

この点が、
「箱庭PDUは様々な通信プロトコルを介してデータ交換される」
という説明の、実装上の正体になります。

この図で伝えたかったこと

箱庭PDUは、
・データ定義
・データ変換
・通信プロトコル
を意識的に分離しています。

この分離があることで、
PDUは特定の通信方式やフレームワークに縛られず、
様々な環境で同じデータ定義を使い回すことができます。

最後に。

ここまでの内容については、実は昨年の夏頃、
こちらの資料ですでに一度解説していました。

箱庭(Hakoniwa) PDU

当時は、
「一旦、自分の中では満足いく形でまとまった」
と思っていました。

ところが、昨年の暮れあたりから、
ふと、こんな感覚が出てきました。

「なんか違う」
「まだ足りない」

その起点は、何度も出てきていますが、
箱庭の新機能である Runtime Delegation の開発でした。

この機能を実装する中で、
箱庭PDUの通信には
単なる接続ではなく、アクセス権の概念が必要だ
ということに気づいたのです。

さらに、
データを転送する箱庭ブリッジ側でも、
そのアクセス権が動的に切り替わるタイミングでは、
明確な「手順」が必要になる。

──これは、まずい。

「だめだ、もっとちゃんとやらないと」

そう思って、箱庭PDUの設計を
もう一段、見直すことにしました。

つづく。


“箱庭PDUアーキテクチャ(その2)” への1件のコメント

  1. […] 前回は、箱庭PDUの責務分離と設計上の境界、そして実装レベルでのデータの流れについて説明しました。 […]

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

PAGE TOP