アリエルフレームワーク(以下afw)は、ネットワーク越しにリソースを取得する時、依存関係を見て一括取得します。 ネットワークの効率的な利用のため、取れる時に、可能な限りリソースを取っておこうという戦略です。P2Pの特性上、あまり頻繁に探索要求を出したくない、という側面もあります。裏の事情はともかく、結果的にはスループットの向上につながっています。

一括取得する時のプロトコルは簡略化すると次のようになっています。

1. 要求側が「欲しいリソースのIDリスト」を提出
2. 応答側が「応答可能なIDリスト」を返す
3. 要求側がリソースを順々に取得

2の返答で、ACLで読み取り不可のリソースを返さないようにしています(3の時もACL処理はありますが)。 3の時のムダな通信が省けますし、2の返答サイズも小さくなります。正しい設計だと思っていました。

残念ながら正しい設計とは言えませんでした。 なぜなら、ACLで取得できないケースと、応答側がリソースを返せないケースの区別を、要求側ができないためです。

要求側は、「取れるべきなのに何らかの障害で取り損ねた」のか「取れるべきではない」の区別ができない以上、取得を試みる必要があります。

ACLで取れないフラグつきで、IDリストを返すべきでした。

afwでは、未取得リソース(取り損ねた or ACLで取れていない)を覚えておき、一括取得時の「欲しいリソースのIDリスト」に載せることで、取得失敗を補完しています。また、ACLで弾かれたケースをキャッシュして、ムダな試行を回避しています。

ACLで読めないリソースは、ローカルにダウンロードしてもどうせ復号できない(つまり読めない)、というafwの特性を利用して、読めないACLのリソースでも取得してしまう、という案も理屈上は可能です。afwではちょっと採用が難しいと思いますが。

同じように見える問題や領域でも、アクセス制御が絡むと問題が複雑になることがあります。

P2Pのプロトコルなんて自分には関係無いと思って読んでいるかもしれませんが、アクセス制御の問題は突然やってくるかもしれません。