教科書4章 - Osaka U

1

名前つけ

教科書4章

2

計算機システムにおける名前リソース共有、エンティティ (entity、実体)の同定、場所(location)の参照などに利用

重要な点：名前はそれが参照しているエンティティへ解決される名前解決(name resolution)名前解決を行うシステム: 名前つけシステム（naming system）

分散システムにおける名前つけシステムの実装複数のマシンに分散(効率化、スケーラビリティ達成のため）

この章では...名前付けの一般的な議論、および、人間が扱いやすい名前付けの構成と実装について説明

モバイルエンティティの位置決定(locating)に使用される名前つけシステムを説明

名前の構成、特に不要になった名前の動的削除に関する議論を紹介

名前つけ

3

エンティティに対する名前つけ

以下のトピックを紹介

名前の種類

名前の集合をどのように名前空間(naming space)に構成するか？

名前解決をどのように行うか？

大きな名前空間を扱う名前つけシステムをどのように分散実装するか？

4

名前・識別子・アドレス

分散システムにおける名前の定義：

エンティティを参照する文字列またはビット列

参照されるエンティティ：　どのようなものでも可

例）ホスト計算機、プリンタ、ディスク、ファイル、プロセス、ユーザ、メールボックス、ニュースグループ、webページ、ウインドウ、メッセージ、ネットワーク接続、など

5


エンティティ：　さまざまな操作の対象例）プリンタ：文書の印刷、現在のプリントジョブ状態の取得など

ネットワーク接続：データの送受信、QoSパラメタ設定、接続状態の取得など

6


エンティティを操作するためには、それにアクセスする必要

アクセスポイント：エンティティへアクセスする場所

アクセスポイントの名前アドレス

エンティティのアクセスポイントのアドレス単にエンティティのアドレスと呼ぶ

7


エンティティは一般に複数のアクセスポイントを持つ

例）

電話番号：個人へのアクセスポイントと見なせる

各個人は一般に複数の電話番号（自宅、会社、携帯など）を持ち、それぞれがその人とコンタクトを取れる場所に対応

分散システムにおける例

特定のサーバが稼動中のホスト計算機

アクセスポイントとして、各サーバ毎にトランスポートアドレス（ホストのIPアドレス+ポート番号）を持つ

8


エンティティはアクセスポイントを変えることがある

例）

移動計算機場所を移動 IPアドレスも変わる（移動先でDHCPなどによってIPアドレス取得）

人の場合他の町や国に引越し電話番号が変わる

職場またはISPを変える電子メールアドレスが変わる

9


アドレス単に、あるエンティティのあるアクセスポイントを参照する一つの特殊な名前

アドレスを、エンティティそのものの名前としてではなく、単にアクセスポイントを指す特殊なタイプの名前として扱うほうが、一般にメリットが大きい

例）

分散システムでは構成の変更がしばしば生じる

あるFTPサーバプロセス（エンティティ）を違うホスト計算機（アクセスポイント）に移動し、以前のホストには全く異なるサーバを置くなど

エンティティのアクセスポイント変更や、アクセスポイントに対

する異なるエンティティへの再割り当てがしばしば発生

アドレスとは違う名前を使ってエンティティを参照した方が良

い

10


一つのエンティティが複数のアクセスポイントを持つ場合どのア

ドレスで参照すればよいか分からない

例）あるwebサービスを複数個のサーバに分散実装

このwebサービスをサーバのアドレスで参照しようとすると... どのサーバのアドレスで参照すれば良いのか分からない

エンティティの名前としては、アドレスと独立のものを用いた方が容易で柔軟に運用できる

このような名前: 位置独立(location independent)と呼ぶ

11


識別子(Identifier):エンティティそのものを同定する名前

以下の性質を持つ名前と定義[Wieringa and de Jonge 1995]

1. 識別子は高々一つのエンティティを指す

2. 各エンティティは高々一つの識別子によって指される

3. 識別子は常に同じエンティティを指す（決して再利用されない）

12


識別子(以下、ID)の利用によって、エンティティを指す際の曖昧さを回避可能

例）2つのプロセスがあるエンティティをIDで参照 IDを比較することで同じエンティティを指しているか否かを容易にテスト可能

アドレスが別のエンティティに再割り当てされる場合アドレスをIDとして利用できない

例）電話番号

13


アドレスとID多くの計算機システムでは機械判読可能(machine-readable)な形式（ビット列）で表現

例）イーサネットアドレス（48ビット）、メモリアドレス（32ビット、64ビットなど）

ヒューマンフレンドリな名前(human-friendly name)人間が使用する目的

一般に文字列で表現

例）UNIXのファイル名：255文字以内の文字列

DNS名：大文字小文字を区別しない文字列

14

名前空間

名前の集合: 名前空間として構成

名前空間の表現名前グラフ：閉路の無いラベル付き有向グラフ

葉ノード(leaf node): 名前のついたエンティティの情報を格納

ディレクトリノード（directory node）：ラベル付きの出力辺を一般に複数持つノード

それぞれの枝のラベルと行き先のノードのIDの対を格納（ディレクトリテーブル)

ルートノード(root node)：入力辺のないディレクトリノード

15

名前空間：絶対/相対パス名

名前グラフのパス（path）：以下の形式で表現

N:<ラベル1,ラベル2,...,ラベルn>N: パスの開始ノード, ラベルi: パスのi番目の枝のラベル

これをパス名（path name）と呼ぶ

Nがルートノードの場合、絶対パス名（absolute path name）, さもなければ相対パス名（relative path name）

16

名前空間：グローバル/ローカル名

絶対/相対の概念とグローバル/ローカルの概念は一般に異なるグローバル名（global name）: システム内のどこで使われても、常に同じエンティティに対応

UNIXファイルシステムの絶対パス名は、分散システムにおいてはグローバル名ではない（単にマシンローカルの名前）

ローカル名（local name）: 名前が使われる場所に依存して異なるエンティティに対応

例）　UNIXファイルシステムのカレントディレクトリに対する相対パス名

17

名前空間の例

名前グラフ：多くのファイルシステムの実装に類似

ファイルシステム：パス名は特別な記号（例えばスラッシュ“/”）で区切られた一つの文字列で

表現

例）/home/steen/mbox一般に同じノードに導く複数のパスが存在

例）ノードn5は複数のパス名(/home/steen/keysと/keys)によって参照可能

ファイルシステム以外の適用例Plan 9[Pike et al. 1995]というOSでは、任意のリソースをファイルと同様のパス名で参照

分散システムでも同様のアプローチ

システム全体のリソース群を一つの名前グラフで表現

18

名前空間の構成法

名前空間の構成法は一般に複数存在

ほとんどの名前空間は一つのルートノードのみ持つ

多くの場合、名前グラフは木構造

この場合、各ノードは唯一の絶対パス名を持つ

名前グラフがDAG(directed acyclic graph)の場合

各ノードが複数の絶対パス名を持ちうる

グラフの閉路は許されない

名前グラフに閉路を許す構成法も存在

19

名前解決

名前からエンティティを参照する処理＝名前解決(Name Resolution)名前解決の処理内容

入力がパス名 N:<ラベル1,ラベル2,...,ラベルn>であると仮定

まずノードNのディレクトリテーブルを調べ、ラベル1の欄を探す

ラベル1の欄からラベル1が指すノードN1を知る

N1のディレクトリテーブルからラベル2が指すノードN2を知る

これをラベルnが指すノードNnを見つけるまで繰り返し、後にノードNnの中身の情報を返す

20

名前付けサービス、名前サーバ

名前つけサービス(name service)ユーザやプロセスに対して、名前の追加･削除・検索などのサービスを提供

名前サーバ(name server): 名前つけサービスを提供するサーバ

LANでは単一サーバで提供可能

大規模広域分散システムにおいては分散実装が必要

21

名前空間の分散化

大規模広域分散システムのための名前空間の分散化通常は階層的に構成

論理的な3層に分割 [Cheriton and Mann 1989]グローバル層（global layer）: も高位のノード（ルートノードおよびそれに近い階層）で構成

ディレクトリテーブルはめったに変更されない

組織、または、組織のグループを表す名前に対応

22


部門管理層（administrational layer）: 一つの組織で管理されるディレクトリノードで構成

同じ組織、あるいは、管理単位の中の名前から構成

グローバル層よりは変更が多いが、それほど頻繁には変更されない

23


マネージャ層（managerial layer）: 頻繁に変更されるノードで構成

例）

一つのLANに属するホスト計算機群の名前

ライブラリやバイナリファイルなどの共有ファイル名

ユーザディレクトリやユーザファイルなど

システム管理者だけでなく、個々のエンドユーザによっても管理

24


可用性,性能の観点からは、名前空間の３つの層に対する要求は異なる

グローバル層: 高い可用性が要求される

もし障害が起こると名前空間の多くの部分がアクセス不能に

性能はそれほど要求されない

内容が殆ど変更されないので、クライアント側のキャッシュが有効

反応時間は遅くても良い

非常に多くのユーザからアクセス

スループットはある程度要求される

25


部門管理層:所属する組織内においては高い可用性が要求されるが、グローバル層ほどではない

もし障害が起きても、他の組織から一時的にアクセス不能になるだけ

性能に関してはグローバル層と同様

26


マネージャ層:可用性はそれほど要求されない

性能面の要求は厳しい

更新が頻繁に起こるのでクライアント側のキャッシュは余り有効でない

27

名前解決の実装

名前空間の複数サーバへの分散化名前解決の実装に影響

名前リゾルバ(name resolver)：クライアントからローカルアクセス可能で、名前解決処理の責任を持つプログラム

2種類の実装の可能性

イテラティブ名前解決(iterative name resolution)再帰名前解決(recursive name resolution)

説明のため、サーバはレプリカを持たず、クライアントはキャッシュを持たないと仮定

28

名前解決の実装: イテラティブ名前解決

イテラティブ名前解決(iterative name resolution)リゾルバはルート名前サーバから順番にパス名を問い合わせ

返答として、次にどの名前サーバに問い合わせればよいかが返される

パス名がすべて解決されるまでリゾルバは問い合わせを繰り返す

29

名前解決の実装: 再帰名前解決

再帰名前解決(recursive name resolution)リゾルバは名前サーバに1回だけパス名を問い合わせ

名前サーバは名前が解決されるまで他の名前サーバに再帰的に問い合わせ、すべて解決されればリゾルバに結果を返す

30

名前解決の実装: 実装法の比較

再帰名前解決とイテラティブ名前解決の比較再帰名前解決の欠点：イテラティブと比較してサーバの負荷が大

再帰名前解決の利点：

キャッシュがイテラティブよりも効果的（リゾルバではなくサーバにキャッシュ）

通信コストが削減（リゾルバとの頻繁な通信がない）

31

名前解決の実装:　実装法の比較

再帰名前解決とイテラティブ名前解決の比較再帰名前解決の欠点：イテラティブと比較してサーバの負荷が大

再帰名前解決の利点：

キャッシュがイテラティブよりも効果的（リゾルバではなくサーバにキャッシュ）

通信コストが削減（リゾルバとの頻繁な通信がない）

再帰名前解決

イテラティブ名前解決

32

モバイルエンティティの位置決定

従来の名前つけシステム: 移動するエンティティ（モバイルエンティティ：mobile entity)の名前つけには適さない

モバイルエンティティに対する名前付けおよび位置決定(locating)に関して解説

モバイルエンティティ向けの名前つけと位置決定

位置決定サービス：簡単な解決法ブロードキャストとマルチキャスト

転送ポインタ

ホームベースアプローチ

階層的アプローチ

33

エンティティの名前つけ vs 位置決定

DNSなどの名前つけシステム:名前空間のグローバル層/部門管理層の内容が滅多に変化せず、マネージャ層の単一サーバのみが頻繁に更新されるという仮定の下では効率がよい

もしあるマシン(例えばftp.cs.vu.nl)を全く違うドメイン(例えばftp.cs.unisa.edu.au)に移動させると...

ftp.cs.vu.nlという名前は変えたくない(他のアプリケーションやユーザが参照している可能性あり）

２つの解決法

34


ftp.cs.vu.nl をftp.cs.unisa.edu.au に移動する場合の名前空間の更新をどうするか？

解決法１）cs.vu.nlを管理するDNSデータベースに新しいアドレスを登録

検索操作には問題ない

もしftp.cs.vu.nlが(cs.unisa.edu.auから）もう一度移動すると...

元々居た場所のcs.vu.nlのデータベースも更新する必要更新操作がローカルで収まらなくなりマネージャ層の

更新だけでは済まない効率悪化

35


ftp.cs.vu.nl をftp.cs.unisa.edu.au に移動する場合の名前空間の更新をどうするか？

解決法２）新しいアドレスを付与する替わりにftp.cs.vu.nlを新しい名前ftp.cs.unisa.edu.auのシンボリックリンク（別名）とする

検索操作の効率が悪くなる

まずマシンの新しい名前を取得し、それからその名前を解決してアドレスを得る

そのマシンが更に(例えばftp.cs.berkeley.eduに）移動すると、さらに効率が悪化

36


頻繁に移動するエンティティの場合、前述の２つの解決法ではさらに効率が悪い

ftp.cs.vu.nlという名前を変えられないことが問題

エンティティの生存期間中に変えなくてもよい適切な名前を選ぶことが重要

他のエンティティが使えないような（一意な）名前にすべき

別の解決法が必要

37


従来の名前つけシステム: 名前からアドレスへ直接対応付けている(direct mapping)

38


モバイルエンティティ向けの名前つけモバイルエンティティの名前付け（naming，名前からエンティティIDへの対応付け）と位置決定（locating，エンティティIDからアドレスへの対応付け）を分離

IDは決して変化しないので、再び名前つけサービスで探す必要が無い

位置決定サービス(locating service)によってIDからそのエンティティの現在位置（アドレス）を得る

39

エンティティの位置決定：簡単な解決法

モバイルエンティティの位置決定に対する２つの単純な解決法

ブロードキャストとマルチキャスト

転送ポインタLANに対してのみ適用可能

LAN環境においては非常に有効

40


ブロードキャストとマルチキャストエンティティIDをLAN全体にブロードキャスト

そのIDを持つエンティティのみが自分のアドレスを返答例）ARP(Address Resolution Protocol)

LANが大きくなると、ブロードキャストは非効率マルチキャストの利用

Ethernetはデータリンクレベルのマルチキャストをサポート

41


マルチキャストは2点間ネットワークにおける位置決定にも利用可能

例）IPマルチキャスト: ネットワークレベルのマルチキャスト

ホスト計算機は特定のマルチキャストグループに参加各マルチキャストグループはマルチキャストアドレスで同定

ホストがマルチキャストアドレスにメッセージ送信グループに属するすべてのホストがメッセージ受信

42


マルチキャストアドレスを用いた位置決定サービス

モバイル計算機Ａ：IPアドレスをネットワーク接続時に動的に付与され、同時に特定のマルチキャストグループに参加

あるプロセスがAのIPアドレスを知りたいとき、マルチキャストアドレスに対して、Aはどこにいるか問う

そのメッセージがAに届くと、Aは自分の現在のIPアドレスを返答

43


複数のレプリカにマルチキャストアドレスを付与し、それらのうちも近いレプリカを探す用途にも利用可能

近いマシンの選び方

雑な方法：　も返答が早いマシンを選ぶ

より精密な方法：　[Guyton and Schwartz 1995]で提案されている

44


転送ポインタ（Forwarding Pointers）[Fowler 1985]

モバイルエンティティの位置決定に対するもう一つの一般的なアプローチ

動作原理：エンティティがAからBに移動エンティティはAにBへのポインタを残す

利点：単純さ

エンティティが移動するとすぐ、クライアントはポインタの連鎖を辿って移動先のエンティティを見つけることが出来る

45


転送ポインタ（Forwarding Pointers）[Fowler 1985]

欠点：ポインタの連鎖が長くなると効率が悪化

ポインタを仲介するホストはそれが不要になるまでポインタを管理する必要がある

連鎖のうち１つでもポインタが失われると、エンティティの新しい場所を見失う（頑強(robust)でない）

課題：ポインタ連鎖を出来るだけ短く保つこと

ポインタ連鎖を障害に強くすること

46

転送ポインタの例：SSP chains

転送ポインタの実例

分散オブジェクトの例(SSP chains [Shapiro et.al. 1992])

(プロキシ,スケルトン)の対で転送ポインタを実現

47


SSP chains [Shapiro et.al. 1992]オブジェクトがAからBに移動するとき、そのオブジェクトは移動元Aにプロキシを残して、移動先Bにスケルトンをインストール

この移動はクライアントからは完全に透過的

移動

以前居た場所に移動先へのポインタ(プロキシ)を残す

移動先プロセスに移動元から参照可能なスケルトンを実装

48


(プロキシ,スケルトン)対の連鎖を短くする手法クライアントからオブジェクトに対する初の起動要求に対する応答に、自分の現在のアドレスの情報を付加

クライアントは受け取ったアドレスを元に、自分のローカルプロキシからの参照を新しいアドレスに付け替える（ショートカット）

要らなくなったスケルトン、プロキシの始末をどうするか？分散ガベージコレクション（後述）

49

転送ポインタの改良

連鎖の一部がクラッシュしたらどうするか？一つの解決法：オブジェクトが生成された場所(ホームロケーション: home location)で、オブジェクトの現在位置への参照を保持[Jul et.al. 1988][Black and Artsy 1990]もし連鎖が壊れたら、ホームロケーションに問い合わせてオブジェクトの現在位置を知る

ホームロケーションの変更への対応：　名前つけサービスを用いてオブジェクトとホームロケーションの対応を管理

ホームベースアプローチ(Home-Based Approach)

50

ホームベースアプローチ

ブロードキャストや転送ポインタの利用スケーラビリティの問題

大規模ネットワークに適用可能なアプローチ：ホームベースアプローチ

ホームロケーションを導入: モバイルエンティティの現在位置を保持する場所（計算機）

通常はモバイルエンティティが初に生成された場所

例）モバイルIP(Mobile IP)[Perkins 1997]

51

ホームベースアプローチ：モバイルIP

ホームエージェント(home agent): モバイルホストのIPアドレスと同じネットワークアドレスを持つLAN上に存在

モバイルホスト宛の通信は、初にホームエージェントに送られる

52


モバイルホストが他のネットワークに移動

ホームエージェントはモバイルホストに一時的なアドレス(気付けアドレス：care-of address)を割り当てる

移動

53

ホームベースアプローチ：モバイルIPホームエージェントがモバイルホスト宛のパケットを受信

モバイルホストの現在の位置を検索

LAN内ならそのまま転送

さもなければ気付けアドレスに転送（トンネリング）

54


ホームエージェントはクライアントにモバイルホストの現在位置（気付けアドレス）を返す

以降の通信は、クライアントとモバイルホスト間で直接行われる

55

ホームベースアプローチの問題点

モバイルエンティティとの通信の際、まずホームエージェントとの通信が必要

ホームエージェントは全く別の（遠くの）場所にある可能性通信遅延の増大

解決法： 2段階スキーム(two-tiered scheme)の利用[Mohan and Jain 1994]

まず、ローカルのレジストリ（データベース）を調べてモバイルエンティティが近くに居ないか探す

もしローカルに居なければホームロケーションにアクセスして、モバイルエンティティの居場所を知る

56

ホームベースアプローチの問題点

ホームロケーションが固定されてしまう問題

ホームロケーションに常にアクセス可能でないと、モバイルエンティティにアクセス不能になる

ホームロケーションの故障、移動など

解決法：名前つけサービスを用いてホームロケーションを検索可能にする

モバイルエンティティとは異なり、ホームロケーションは比較的動かないので従来の名前つけサービスで十分

57


階層的アプローチ(階層的位置決定サービス)２段階ホームベースアプローチの複数のレイヤへの一般化

一般的なメカニズムネットワークを複数のドメイン（domain）に分割(DNSと同様）

各ドメインをさらに複数のサブドメインに分割

58


下層のドメイン：葉ドメイン（leaf domain）　--- LANまたは（携帯電話網の）１つのセルに対応

各ドメイン Dに対してディレクトリノードdir(D)を導入

そのドメイン内のエンティティの情報を管理

上層ドメインのディレクトリノード: 根（ディレクトリ）ノード（root (directory) node） --- 全てのエンティティの情報を知っている

59


エンティティの現在位置：ロケーションレコードに記録エンティティの現在位置を含むドメインDのディレクトリノードdir(D)に格納

エンティティEの実際のアドレスはEの現在位置を含む葉ドメイン Dのディレクトリノード dir(D)に格納

Dの一つ上のドメインD’のディレクトリノード dir(D’)には、Eの位置としてdir(D)へのポインタのみを格納

D

D’E dir(D)

：　　：

E (Eのアドレス)

　：　　　　：E

dir(D’):

dir(D):

60


エンティティEは（複製されるなどによって）複数のアドレスを持ち得る

Eのアドレスがそれぞれ葉ドメイン D1,D2に属するとすると…D1,D2をともに含むも小さいドメインDのディレクトリノードのEのエントリに複数のポインタを登録

61


エンティティEのアドレス検索手順１．Eと通信したいクライアントは、まずクライアントが属す

る葉ドメインのディレクトリノードに対して検索要求を出す

62


エンティティ Eのアドレス検索手順

２．要求を受け取ったノードは、もしEが自分が知らないエンティティであれば、上位ノードに要求を転送

63



３．もし、ディレクトリノードがEが属する下位ノードへのポインタを知っていたら、その下位ノードへ要求を転送

64



４．終的に、Eが属する葉ドメインのディレクトリノードが要求を受け取り、Eのアドレスをクライアントに（直接）返す

Eのアドレスを直接返答

65


エンティティEのアドレスの更新

１．葉ドメインDにEの複製のアドレスを登録したいとき、まず、dir(D)にアドレスの追加要求を出す

66


エンティティEのアドレスの更新２．もしdir(D)のロケーションレコードにEのエントリが無ければ、上

位ノードに要求を転送

67


エンティティEのアドレスの更新３．ロケーションレコードにEのエントリを持つノードMに達したら、E

のエントリにポインタを追加し、要求を受け取った下位ノードに、Eのエントリを作成することを指示する

68


エンティティEのアドレスの更新４．終的にdir(D)は自分のロケーションレコードにEのエントリを作

成し、Eのアドレスを格納する

69

ポインタキャッシュ

検索したアドレスのキャッシュ

モバイルエンティティに対しては一般にあまり有効ではないアドレスが頻繁に変化する可能性

毎回、検索処理全体を行うのは非効率

キャッシュが有効な場合：内容があまり変化しないとき

エンティティEがドメインDの中だけで動いている場合 Eのアドレスは頻繁に変化するが、根ノードからdir(D)までのポインタは変化しない

これらのポインタをキャッシュすることは有効

70


DをエンティティEが頻繁に動き回る小の領域とすると、Eの場所の検索をdir(D)から開始するのが有効

ポインタキャッシュ（pointer caching）A. Baggio, G. Ballintijn, and M. van Steen: “Mechanisms for Effective Caching in the Globe Location Service,” Proc. 9th SIGOPS European Workshop, ACM, pp. 55-60, 2000.

動作原理: Eのアドレスはdir(D)に問い合わせれば分かるという情報を全てのノードに（キャッシュとして）持たせる

検索要求Eのアドレスを応答

71


更なる効率化：dir(D)にEのアドレスそのものを（キャッシュとして）持たせる

検索処理は以下の2ステップのみでよいローカルのキャッシュを検索してdir(D)へのポインタを取得（もし無ければ上位ノードに問い合わせ）

dir(D)のキャッシュを検索してEの現在アドレスを取得(もし無ければ下位ノードに問い合わせ）

検索要求

Eのアドレスを応答

72


ポインタキャッシュの未解決問題モバイルエンティティEのアドレスを格納するも良いディレクトリノードdir(D)を如何に選ぶか？

例）あるユーザはサンフランシスコとロサンゼルス間をよく行き来して、そこでモバイル計算機を利用する

サンフランシスコに滞在中は、サンフランシスコのドメインを選ぶのが良い

ロサンゼルス滞在中も同様

もし、上記2都市間を頻繁に行き来するならば、これら2都市を含むカリフォルニアドメインを選んだ方が良い

カリフォルニアドメイン

サンフランシスコドメイン

ロサンゼルスドメイン

73


ポインタキャッシュの未解決問題キャッシュをいつ無効化するか？

例）前述の例のユーザがニューヨークから仕事の依頼を頻繁に受けるので、マンハッタンにオフィスを開いて、彼の友人にニューヨークからの依頼の取り扱いを任せることにしたとすると...

ニューヨークドメインからのアドレス検索要求に対しては、彼の住所であるカリフォルニアではなく、マンハッタンのオフィスのアドレスを返さなければならないニューヨークドメイン内ではカリフォルニアドメインへのポインタキャッシュを無効化する必要あり

カリフォルニアドメインニューヨークドメイン

74

位置決定サービスのスケーラビリティ

階層的な位置決定サービスのスケーラビリティ問題

ルートノードは全てのエンティティに対するロケーションレコードを管理する必要

ロケーションレコードを格納するディスク容量の問題

非常に多くのアドレス検索・更新要求を受け付ける必要がある問題

解決法：ルートノードや幾つかの上位ノードをサブノードに分割

75


ノードを単に分割するだけでは不十分

例えば、ルートノードを100個のサブノードに分割したとして、それらをどのように物理的にネットワーク上に配置するか？

一つの可能性：サブノード群を一箇所に集中的に配置（お互いの距離は近い）

処理能力は十分だが、ネットワークトラフィックが集中して回線容量が不足するかもしれない

76


より良い方法：（ルートノードの）サブノード群をネットワーク全体に均一に分散させる

各エンティティEには、それを受け持つ(＝Eの位置を知っている)サブノードがネットワーク上のどこかに存在

エンティティ毎に異なるサブノードにアクセスネットワークトラフィックの分散スケーラブル

適切に行われないと問題が生じる可能性がある

77


例）前述のカリフォルニアのユーザの例で、ルートノードが（サブノードに）分割されたとしたとき、このユーザのアドレスを知るにはどのノードに問い合わせればよいか？

例えばフィンランドのルートノードがこのユーザに関する問い合わせの責任を持つとし、ポインタキャッシュが無効であるとすると、例えばブラジルからの検索要求は一旦フィンランドに送信され、それからカリフォルニアドメインのノードに転送される

無駄な通信経路

78


もしテキサスにも（ルートノードの）サブノードが存在したならば、ブラジルからの検索要求はテキサスに送信した方が効率的

より効率的な通信経路

79


一般に、どのサブノードを選ぶのがもよいかという問題はまだ未解決

一つの解決法：エンティティEが生成された場所のサブノードを、Eに関するルートレベルの要求に対して責任を持つノードとして選定する

Eが生成された場所になるべく留まっているなら有効

Eが全く別の場所に引越ししてしまうと問題は残る

詳細は下記文献参照G. Ballintijn, M. van Steen, and A. S. Tanenbaum. "Exploiting Location Awareness for Scalable Location-Independent Object IDs." In Proc. 5th ASCI Annual Conference, pp. 321--328, Heijen, The Netherlands, June 1999.

80

演習問題

1. 以下の用語およびそれらの関係を具体例を用いて説明せよ。

名前, エンティティ,アドレス,識別子（ID）, ヒューマンフレンドリネーム

2. 以下のURLはそれぞれ位置独立か？理由も説明せよ。

http://www.acme.org/index.htmlhttp://www.acme.nl/index.html

3. イテラティブ名前解決と再帰名前解決の利点･欠点を考察せよ。

4. ２段階ホームベースアプローチを階層的位置決定サービスの特別な場合と見なしたとき、ルートノードはどこに対応するか？

5. 階層の深さがkである階層的位置決定サービスにおいて、あるエンティティが移動したとき、更新すべきロケーションレコードの数は大で幾つになるか？

6. エンティティがロケーションA からロケーションB に移動し、その間いくつかの中間のロケーションを通過することを想定せよ。ただし、中間のロケーションにはほんの少しの時間しか滞在しないものとする。ロケーションB に到着すると、しばらくの間そこにとどまるものとする。階層的位置決定サービスでアドレスを変更することは比較的時間がかかるかもしれないので、中間のロケーションを訪れるときにはそれは避けたい。それでは、そのエンティティが中間のロケーションに居る時、どのように位置決定すればよいか？

Documents

教科書4章 - Osaka U