autotoc_md7

marp: true

NestDAQ ヘッダーの現状・構想

大田 晋輔

背景

ヘッダーの構造の変更は柔軟か？

headerLength を構造に埋め込むことでヘッダー部分が可変長になったが、実際に使おうとすると構造を解析するためにはその構造を事前に知っておく必要があるため、バージョンを挙げるなどの対策が必要になる。また、必要な情報を必要なときに追加し、不必要になったら削除するというような柔軟性はない。

構造解析のメンテナンス

構造解析をするコードはバージョンごとに解析コードを準備する必要があるため、分岐が多いコードとなるし、メンテナンス性も下がってくる。

理想

• 安定性 : ヘッダーの定義（スキーマ）は唯一であり、構造の解析は一種類だけで良い。
• 拡張性 : 追加の情報がある場合には柔軟に追加あるいは削除が可能である。
• 整合性 : 追加の情報について一元管理されている。

現状

6つのヘッダー（デリミタ）が存在する。 当初は、それぞれのデバイスの開発者が思い思いのヘッダーを作った。その後、さすがに統一的にやったほうが良かろうということで、固定部分が作られた。しかし、固定部分のあとについての規定はなかった。各ヘッダの詳細は付録に載せる

• FileSinkHeader.h
• FileSinkTrailer.h (実際は FileSinkTrailer とおなじ)
• FilterHeader.h
• HeartbeatFrameHeader.h
• SubTimeFrameHeader.h
• TimeFrameHeader.h

対応

基本部分と拡張部分に分けて管理をする

• 基本部分
  • バージョン
  • マジック
  • ブロック長
  • ヘッダ長
  • ブロックタイプ
• 拡張部分
  • 長さ、名称、データを単位とする繰り返し

さらなる拡張の可能性

• マジックを分割（拡張）して、階層、タイプ、バージョンによる表現にする

付録

• 2025/02/01 現在のヘッダーの詳細について
• timeframe(v1)