Data-sharing (zero-copy) 配送¶

英語版が正です。この文書は 2026-09-22 時点の英語版に対応しています。

writer と reader が同じホストにあり、型が bounded (サイズ上限あり) なら、Fast DDS はすべての transport を迂回できます。reader が writer の履歴を直接マップする data-sharing 配送です。ツールはこれを SHM transport とは区別して DATA_SHARING と表示します。

ROS 2 ノードが広告するもの¶

rmw_fastrtps_cpp は既定ですべてのエンドポイントに data-sharing OFF を広告するため、ROS 2 のトピックは通常 SHM になり、DATA_SHARING にはなりません。Fast DDS は AUTO を型の boundedness と履歴メモリポリシーに基づいて discovery の前に解決するので、ツールが広告 QoS で見るのは実効的な設定です (std_msgs/String の writer は AUTO を指定しても OFF を広告します)。

bounded な型 (例: std_msgs/Int32) で有効にするには:

export FASTRTPS_DEFAULT_PROFILES_FILE=$(ros2 pkg prefix fastdds_transport_viz)/share/fastdds_transport_viz/config/datasharing_auto.xml
export RMW_FASTRTPS_USE_QOS_FROM_XML=1
ros2 run fastdds_transport_viz bounded_pub &
ros2 run fastdds_transport_viz bounded_sub &
ros2 transport list -v                              # /bounded -> DATA_SHARING? (likely)

既定プロファイルには ON ではなく AUTO (XML では <kind>AUTOMATIC</kind>。どの Fast DDS でも通る綴り) を使ってください。ON だと /rosout のような unbounded な型で writer の作成が失敗します。

確信度¶

両エンドポイントが data-sharing を広告し、domain id に共通部分があれば (または少なくとも片方が domain id を広告していなければ)、判定は likely (DATA_SHARING?) です。ただし例外が 2 つあります。

writer と reader が別々の IPC 名前空間にある場合 (#110): Fast DDS はそれでも QoS だけで両者をペアにしますが、reader は writer の履歴を開けず、何も届きません。ツールがそれを判別できるとき (両方が SHM を持ち IPC 名前空間の分断の SHM の証拠がある場合、または 2 つの data-sharing セグメントの片方だけがツールの /dev/shm にある場合。 datasharing-reader-segment-not-visible / datasharing-writer-segment-not-visible) は、判定は NONE (certain) で警告 shm-ipc-namespace-split が付き、--stats でも変わりません (配送の証明があれば shm-ipc-namespace-split-but-delivered が加わります)。
writer と reader が同じプロセスにある場合 (#201): Fast DDS はサンプルを data-sharing セグメント経由ではなくプロセス内で受け渡すので、理由は datasharing-unverified-by-traffic ではなく intra-process になり、判定は certain になりません。パケットも DATA_COUNT もセグメント経由の配送も無いので、確かめようがないためです。writer の participant から reader へのパケットが実測されたときだけ intra-process の理由が外れ、以下の規則が適用されます。

それ以外では、--stats を付けると次の 2 通りで certain になります。

HISTORY_LATENCY が配送を証明し、かつ reader の locator にパケットが 1 つも届いていない (datasharing-confirmed-no-traffic)。
HISTORY_LATENCY が配送を証明し、かつ観測中に writer の DATA_COUNT が増えていない (datasharing-confirmed-no-data-submessages)。reliable な data-sharing エンドポイントは SHM 上で heartbeat を交換し続けますが、zero-copy 配送は DATA サブメッセージを一切生成しないので、このカウンタで両者を区別できます。観測対象ノードの FASTDDS_STATISTICS に DATA_COUNT_TOPIC が必要です。

export FASTRTPS_DEFAULT_PROFILES_FILE=$(ros2 pkg prefix fastdds_transport_viz)/share/fastdds_transport_viz/config/datasharing_auto_stats.xml
export RMW_FASTRTPS_USE_QOS_FROM_XML=1
export FASTDDS_STATISTICS="RTPS_SENT_TOPIC;RTPS_LOST_TOPIC;HISTORY_LATENCY_TOPIC;PHYSICAL_DATA_TOPIC;DATA_COUNT_TOPIC;RESENT_DATAS_TOPIC;HEARTBEAT_COUNT_TOPIC;ACKNACK_COUNT_TOPIC;NACKFRAG_COUNT_TOPIC;GAP_COUNT_TOPIC"
ros2 run fastdds_transport_viz bounded_pub &
ros2 run fastdds_transport_viz bounded_sub &
ros2 transport list -v --stats                      # /bounded -> DATA_SHARING (certain)

writer が data-sharing でない reader も相手にしている場合、その DATA_COUNT には両方の経路が混ざるので判定は likely のままです (datasharing-ambiguous-mixed-readers)。別の IPC 名前空間にいる data-sharing の reader (shm-ipc-namespace-split) には writer が DATA を送らないので、これには数えません。すべての reader が data-sharing なのにカウンタが増える場合、Fast DDS は zero-copy を使っていません。判定は実測された transport (reader へのパケットが帰属できなければ SHM?) に変わり、理由 datasharing-data-submessages-sent と警告 datasharing-not-used が付きます。DATA_COUNT_TOPIC が無い場合、または HISTORY_LATENCY がまだ配送を証明していない場合、リンク上のトラフィックがあると判定は likely のままです (datasharing-ambiguous-participant-traffic)。トラフィックも配送の証明も無ければ datasharing-no-delivery-observed です。 JSON の measured オブジェクトには data_submessages (DATA_COUNT の増分。取得できなければ null) と delivered_samples が入ります。

履歴のサイズ¶

data-sharing の writer は履歴を /dev/shm の fast_datasharing_<writer の GUID> というファイルに置きます。ツールからそのファイルが見える (同じ IPC 名前空間) 場合、そのサイズを writer に紐付けて JSON の datasharing_history_bytes と web viewer のエンドポイント詳細に出します。data-sharing のエンドポイントのセグメント (writer の履歴、reader の通知ファイル) がそもそもそこにあるかは datasharing_segment_visibility です (#163)。環境の共有メモリの行はこうした履歴をすべて数えます (how-it-works.ja.md 参照)。 Fast DDS は writer が kill されてもこのファイルを消さないので、終了した writer の履歴は fastdds shm clean を実行するまで unmatched として現れます。data-sharing の reader は通知セグメント fast_datasharing_<reader の GUID> を作り、これは datasharing_notifications として数えます。writer の履歴とその reader の通知セグメントの片方だけがツールの /dev/shm にあれば、2 つは別々の IPC 名前空間にいます (IPC 名前空間の分断を参照)。