要約

  • RESERVEは名前を他の要求者が取得できない状態にするが、RFC 3656は、それだけでクライアントがメールボックスを使えるとは述べていない。
  • MAILBOXがアクセス可能な有効レコードを示す。通常はローカル作成の後にACTIVATEするが、この順序は推奨であり、参加者の協調を前提とする。サーバーが前段の予約を必須条件として強制するわけではない。

名前を先に確保し、箱は後で用意する

複数のメールサーバーを束ねると、二つの問いを分けて答える必要がある。ある名前をどのサーバーが担当するのか。そして、そのメールボックスを今すぐクライアントが使えるのか。2003年12月にExperimentalとして公開されたRFC 3656は、この二つを別の状態として表した。MUPDATEは、複数のIMAPまたはPOP3サーバーで配送責任を分担しながら、共通のメールボックス名前空間を設けることを目指した。

典型的な作成手順はRESERVEから始まる。クライアントはマスターに対し、指定した場所で名前を確保するよう求める。OKが返ると、ローカルでメールボックスを作成し、名前、場所、ACLを添えてACTIVATEを送る。成功した有効化によってレコードはactiveになる。場所は保存先サーバーへの案内になり、ACLはアクセス権を記述する。

応答語が境界を示す。RESERVEは、その名前を別の要求者が使えなくなったことを表す。ただしRFCは、メールボックスがその時点でクライアントから利用可能になったという意味ではないと明記する。MAILBOXはアクセス可能なレコードを示す。両者を同じ意味に扱えば、名前空間のロックを可用性の誤報に変えてしまう。ローカルの箱がまだ存在しない場合も、作成処理が終わっていない場合もある。

原子性は参加者の共通規律だった

MUPDATEの構成では、権威あるデータベースを持つマスターが一台あり、スレーブはその内容を複製する。検索はどちらにも送れるが、データベースを変える操作はマスターへ向ける。つまり作成は、分散した名前登録とローカルのメールボックス保存という二つの面をまたぐ。プロトコルは両者を調整するものの、単一の原子的な機械にまとめてはいない。

規範語もその限界を示す。新しいメールボックスは有効化の前に予約するSHOULDとされた。認証済みの参加者が協力して原子的な操作を守る、という設計前提があるためだ。それでもACTIVATEは先行する予約を要求しない。実際の保存場所との同期を容易にするため、その動作は許容された。共通のロック規律を無視する参加者がいれば、データベースは不整合になり得る。データベースに報告されなかったローカル処理を、データベースが推測することはできない。

DEACTIVATEはactiveな名前をreservedに戻す。名前空間から消す操作とは異なる。RFCは、この移行で既知のACL情報が失われる可能性も指摘した。移行中や作成中断時には、名前は確保済みのままでもactiveなメールボックスが広告されていないことがある。記録された場所は、ユーザーのログインやメール閲覧を証明しない。

レプリカのOKが保証する範囲

スレーブがUPDATEを発行すると、マスターは最初に一覧を送り、その後の変更をストリームする。マスター側で変更が起きた場合、30秒以内にスレーブへ送ることが規定されていた。UPDATE後、スレーブはNOOPを送れる。その応答OKは、NOOP時点で保留中だった更新がすべて届くまで返してはならない。これは境界のある同期時点であり、その応答後もデータベースが常に最新であるとの保証ではない。

役に立つが、限られた確認である。その時点までの保留ストリームが特定のレプリカへ届いたことは示せる。後で起きた更新の到着、ローカル保存領域の正常性、ユーザーのアクセスまでは証明しない。RFC 3656はExperimental文書であり、提案された調整契約を記すもので、今日の導入状況や可用性測定を示すものではない。

出典