要約

  • MTP のマスターは data[eom] と途中の全パケットを観測するとメッセージを受理とし、不完全な場合は送信者の生存判断に応じて保留または拒否とした。
  • 受理・保留・拒否は12要素の移動ベクトルで後続パケットに載り、未解決の保留は窓の外へ押し出せず、新しいトークン確認を止めた。
  • 成功した消費者は通常応答せず、欠落だけを NAK で知らせたため、プロトコル合意は各アプリケーションの肯定的受領、認証、実行、永続監査、運用結果とは別の証拠だった。

受理判定は受信者の投票ではなかった

RFC 1301 のメッセージ受理レコードは、同期フラグと、各2ビットの12要素から成る。要素は accepted、pending、rejected の三値を取る。新しいメッセージ番号が進むたび、窓は過去へ向けて12件の状態を示した。

この形だけを見ると、各欄が別のメンバーの回答であるように思える。実際には時間の列であり、状態を設定できるのはマスターだけだった。メンバーは後続パケットを処理して、以前のメッセージにマスターが下した結果を学ぶ。

したがって accepted は、MTP 内では明確な権威を持つ。だが権威の対象は伝送順序とメッセージ状態である。アプリケーションの判断を代行する権利までは含まれない。

下層のIPマルチキャストは到達を保証しない

RFC 1112 のホストグループは動的で、メンバーはいつでも参加・離脱できた。そこへ送る IP データグラムの信頼性は通常のユニキャストと同じベストエフォートである。すべてのメンバーへ完全に届くことも、同じ順序で届くことも保証されなかった。

MTP はその上に伝送規律を置いた。協働プロセスの集合を web と呼び、一つのマスターを必須とした。他のメンバーは生産と消費の双方を行うか、消費だけを行う。マスターは参加、性能パラメータ、送信トークンを管理した。生産者は通常データを送る前に、メッセージ番号を伴うトークンを受け取る。

IP はデータグラムを複製する。マスターは発言順序を割り当てる。アプリケーションは受け取ったバイトの意味を判断する。同じ経路上にあっても、三者の責任は同じではない。

正常な消費者は沈黙した

MTP は否定応答型だった。欠落を見つけた消費者は NAK を送る。期待どおりに受け取った消費者は、生産者へ成功 ACK を返さない。大勢から一斉に応答が返る負荷を避けるためである。

沈黙は、規定時間と保持状態の中で回復要求が出なかったことを示す。しかし、アプリケーションが構文解析を終えた、命令を許可した、画面に表示した、外部状態を変えた、という記録ではない。正の受領書は、設計上そもそも作られていない。

後世の集計が沈黙を「全員確認済み」に置き換えると、プロトコルが削減した通信を証拠の中だけ復活させてしまう。記録すべきなのは、誰がどの欠落を報告し、マスターが何を見て、どの状態を公表したかである。

マスターが全体を見たときに accepted になった

マスターが data[eom] とそれ以前の全パケットを見れば受理。不完全でも送信者が稼働中で接続されていると判断すれば保留。不完全で、故障または分断されたと判断すれば拒否。三つの規則は短いが、観測と推論を分けている。

パケット完全性はマスターの観測である。送信者の生存や分断はマスターの判断である。最終ベクトルだけでは、その根拠を再現できない。監査には、受信範囲、終端マーカー、番号対応、時間、そして生存判断の変化が必要になる。

さらに MTP にとって顧客データは解釈しないバイト列だった。正しい順序で完全に届いたメッセージが、アプリケーションには不正な要求であることもある。受理と拒否が、異なる層で同時に成立し得る。

保留を忘れるために前進することはできなかった

12件より古い状態は移動窓から消える。RFC 1301 はこのヘッダーを永続台帳にはしなかった。ただし保留中の状態だけは、解決せずに最後の欄から押し出すことを禁じた。

最古の pending が端に達すると、マスターは新しい token request を確認してはならない。まず accepted か rejected に決める必要がある。不確実性は通信速度を落とす実体となり、見かけの進歩で隠せなかった。

これは強い設計だが、最終化済みの古い状態まで永久保存するものではない。窓外へ出た判断を後から必要とするなら、ヘッダーとは別に、決定と根拠を保存しなければならない。

16ビットのメッセージ番号はマスターが初期化し、トークン付与ごとに増やした。付与された番号は消費され、関連メッセージは最後に受理か拒否へ到達する。これは一つの MTP インスタンス内の順序であり、業務行為の永続識別子ではない。

二重のトークン確認は過去を一つに決めなかった

制御パケットは通常のシーケンス番号を消費しない。そのため、再送された token request は、新しい要求か、確認を見失った旧要求かを単独では示さない。生産者が確認を受けてデータを送ったのにマスターが全パケットを失った可能性も、再要求が遅い確認を追い越した可能性もあった。

プロトコルは原因を断定せず、収束の手順を定めた。マスターから見てトークンが pending なら再割当てできる。生産者が重複した token confirm を受け取ると NAK と解釈し、同じメッセージ番号で以前送ったデータを再送する。不要なら empty[cancel] を返す。

再送の成功から過去の損失箇所を逆算してはならない。要求、確認、生産者送信、マスター観測、再送を別々に保存して初めて、曖昧さそのものが見える。

保持時間が回復の限界を決めた

heartbeat は共有の時間単位、window は一つの heartbeat で生産者が送れる新規・再送データの上限、retention は再送用データを保持する heartbeat 数だった。

十分な顧客データがなく、まだメッセージ終端でもないとき、生産者は empty[dally] を送って同期を保った。短いメッセージも retention 数以上のパケットになるよう空パケットを加え、消費者が少なくとも一つを観測して生産者を識別できる可能性を高めた。確率を高める反復であり、全員への保証ではない。

消費者は番号の飛び、または未完断片の後の沈黙から欠落を検出し、不足範囲を NAK で生産者へ送った。再送は web 全体へマルチキャストされ、window を消費し、新規データより優先された。他の消費者は、自分が要求していない重複を捨てなければならない。

データが retention を過ぎていれば、生産者は nak[deny] を返す。受信側は失敗を顧客へ報告し、状況によって web から離脱する。回復可能性にも期限があり、期限後に作れるのは失敗通知であって、失われたアプリケーション結果ではない。

識別子は認証ではなかった

IP 上の MTP は RFC 1112 の Level 2 を要求し、恒久グループ 224.0.1.9 を使った。IP にプロセスポートがないため、IP プロトコル番号92の下で、送信元・宛先ポート、長さ、任意チェックサムを持つ橋渡しヘッダーも定義した。

TSAP や接続識別子は伝送インスタンスを区別する。だが RFC 1301 はセキュリティを論じていない。正しい宛先、参加状態、マスター役割は、認証済みの人物・装置・組織や操作権限の証明にはならない。

翌年の評価はマスターの集中コストを示した

RFC 1458 は大容量画像配送の観点から MTP を評価した。トークンによる順序・流量制御、NAK 回復、重複処理を認めつつ、グループアドレスと識別子の外部依存、ほぼ全制御がマスターを通る遅延と混雑を指摘した。その用途には不向きだと結論した。

これは特定の MTP 交換が失敗した証拠ではない。同じ集中点が、合意の源にもボトルネックにもなることを示す設計評価である。

出典

これらは歴史的なプロトコルと設計評価を示す。実在する MTP web、受信者数、認証済みメンバー、アプリケーション処理、事故、普及率、現在の成果は立証しない。