要約

  • LTP の赤部分は確認・再送の対象となる連続した接頭部で、緑部分はその後に続く未確認・未再送の接尾部である。色は優先順位ではなく、通信費用の扱いを表す。
  • 送信セッション完了通知が証明するのは、全バイトを送信し、赤部分全体の受信を報告で確認したことまでである。緑部分、Bundle の次ホップ、最終アプリの受領は別の証拠を要する。

「全部送った」と「全部届いた」の間にある設計

あるブロックの先頭には復号に必要な制御情報があり、後半には多少欠けても使える観測値があるとする。クライアントは先頭を赤、後半を緑として LTP に渡す。この選択は内容の価値を色で順位付けする行為ではない。どのバイトに再送枠、電力、保存領域、往復待ち時間を使うかを決める行為である。

送信セッションが完了する条件は二つある。全ブロックのデータが実際の送信へ回ったこと。そして、受信報告の累積が空でない赤部分の全域を覆うことだ。緑部分の受信は条件にない。混合ブロックなら、緑は全部届いたかもしれず、一部だけかもしれず、ゼロかもしれない。

同じ complete でも、全赤ブロックなら全域の報告受信を含み、混合ブロックなら前半だけ、全緑ブロックならデータ確認なしでも成立しうる。赤長を持たない完了統計は、異なる保証を同じ母数に入れている。

さらに、要求した境界と実行された境界が同じとは限らない。一つのデータセグメントは一色だけである。希望する赤長がリンクに適したセグメントの途中に来ると、実装はそのセグメント末尾まで赤として扱える。監査対象は設定値だけではなく、実際の EORP、EOB、オフセット、長さである。

赤の後に緑が続く順序も不変条件だ。すでに緑を観測した位置より上に赤が現れたり、赤と分かっている位置より下に緑が現れたりすれば、受信側は誤着色として破棄し、キャンセルを開始する。色は見た目ではなく、信頼性の構造そのものだ。

通知を並べると、証拠の主体が見える

初期送信完了通知は、元の赤・緑セグメントをすべて送った時点で発生する。失われた赤セグメントの再送は残り得る。これは第一巡の終了である。

赤部分受信通知は受信側で発生する。EORP によって赤長が確定し、全赤バイトが揃ったとき、ローカルクライアントへ渡される。赤の終端がブロック終端でもあるかという情報も含むため、混合ブロックでは「まだ緑が続く」ことを明示できる。

緑部分にはブロック全体の受信通知がない。緑セグメントごとに、データ、オフセット、長さ、EOB 到達の有無が通知される。EOB 付きセグメントが届いても、その手前の穴が埋まったことにはならない。

送信セッション完了通知は、全バイトの送信と赤全域の受信証明を組み合わせる。初期送信完了より強いが、緑については沈黙する。キャンセル通知はまた別で、相手側の要求、エラー、再送上限、資源不足などによる終了を表す。送信側キャンセルでは、宛先クライアントがブロックの一部でも受け取ったという保証はない。

誰が、どの方向で、何を知ったのかを残せば、これらは有用な証拠になる。一つの「配送済み」フラグへ潰せば、最も大切な違いが消える。

受信報告には発言できる範囲がある

チェックポイントに対し、受信側は下限・上限と、その範囲内で受け取った区間を記した報告を返す。報告範囲の外は欠損ではなく、観測対象外だ。正のクレームだけを保存し境界を捨てると、「受け取らなかった」と「尋ねていない」を区別できない。

大きな状態は複数の報告セグメントに分かれる。赤全域の完成は、同一セッションに属する互換な区間を組み合わせた判断であり、報告が一枚あることではない。受信率の数字だけでは、重要な先頭が欠けたのか、範囲外なのか、報告同士が矛盾したのかを復元できない。

報告確認もデータ確認ではない。そこに入るのは報告のシリアル番号であり、送信側がその報告を受け取ったので受信側が報告の再送を止められる、という意味だ。確認された対象と方向を省けば、制御メッセージの受領がペイロード配送へ化ける。

タイマーを動かすのは接触計画である

常時接続を前提にした経過時間は、断続回線では役に立たない。運用環境は、相手への送信機会と相手からの送信機会の開始・終了、片道光時間、想定速度を LTP エンジンへ知らせる。チェックポイントや報告のタイマーは、キュー投入時ではなくリンクへ実際に引き渡された時点を基準にする。

相手が送信できない期間には関連タイマーを止め、接触再開時に動かす。したがってタイムアウトは、実損失のほか、古い接触計画、誤った距離、キュー信号の遅れ、通常の中断でも起こる。

計画とリンク通知を管理する主体は、いつプロトコルが限界を宣言するかに影響する。再送上限によるキャンセルを遠端の失敗と呼ぶ前に、使用した計画世代とタイマー停止履歴を示す必要がある。

エンジンの受信から利用者の受領までは別の道

LTP エンジン ID は閉じた通信集合の中でエンジンを識別する。Bundle のエンドポイントとの対応は収束層アダプター次第であり、人、組織、宇宙機アプリの本人性を証明しない。

赤部分が受信クライアントへ届いた後も、Bundle は保存待ち、期限切れ、後続ホップ失敗、セキュリティ拒否、アプリ未受領になり得る。逆に、一つの LTP セッションが失敗しても、別コピー、次の接触、別経路、アプリ回復があれば最終喪失とは限らない。

RFC 5327 の認証拡張は送信元や改ざん、資源攻撃への対応を補うが、報告の区間を広げるものではない。本物の報告でも赤だけを覆い、赤が完全でも緑は欠け得る。

RFC 5326 は Experimental である。IESG の注記は、セキュリティ、輻輳制御、既存プロトコルとの相互作用について Internet Standard と同じ審査を経たとはしていない。仕様自体にもフロー制御・輻輳制御はなく、遍在する公開インターネット向けではない。当時の UDP 利用は開発またはプライベート LAN に限定された。後続文書は登録簿や Bundle の発展を説明するが、個別導入の適合を立証しない。

出典と証拠の限界

以上は仕様の意味、公開位置付け、周辺構成を確立する。現在の導入、緑全域の受信、Bundle 配送、最終アプリ利用、ミッション成果までは証明しない。