データ通信ネットワーク

2.2.1 ネーミングモデル

名前が特定のオブジェクトとどう関連付けられるかのモデルを持っていると便利である。 システム設計者は、3つの要素からなるネーミングスキームを作成する。 最初の要素は名前空間であり、これは記号のアルファベットと、どの名前が受け入れられるかを指定する構文規則からなる。 2番目の要素は名前マッピングアルゴリズムで、名前空間のいくつかの(必ずしもすべてではない)名前と、値の世界のいくつかの(やはり必ずしもすべてではない)値を関連付けるもので、これが名前付けスキームの3番目の要素であり、最後の要素である。 値は、オブジェクトである場合もあれば、元の名前空間または別の名前空間からの別の名前である場合もある。 名前から値へのマッピングは結合の一例であり、そのようなマッピングが存在する場合、名前は値に結合していると言われる。 図2.10に示す。

Figure 2.10.に示すように,名前と値との対応付けは,名前と値との対応付けである。 ネーミングスキームの動作の一般的なモデル。 名前マッピングアルゴリズムは名前とコンテキストを取り込み,値の宇宙から要素を返す。 矢印は、コンテキスト「A」を使用して、アルゴリズムが名前「N4」を値「13」に解決することを示す。

ほとんどのシステムでは、通常いくつかの異なる命名スキームが同時に動作している。 たとえば、システムは電子メールボックス名に 1 つの命名スキーム、インターネットホストに 2 つ目の命名スキーム、ファイルに 3 つ目、そして仮想メモリアドレスに 4 つ目を使用することがあります。 プログラムインタプリタが名前に出会ったとき、どの命名方式を呼び出すべきかを知る必要があります。 通常、名前の使用を取り巻く環境は、命名方式を特定するのに十分な情報を提供します。 たとえば、アプリケーション プログラムでは、そのプログラムの作成者は、ファイル名はファイル システムによってのみ解釈されること、インターネット ホスト名はいくつかのネットワーク サービスによってのみ解釈されることを期待すべきであると知っている。 ネームマッピングアルゴリズムは名前を解決する。つまり、関連する値を発見して返す(このため、ネームマッピングアルゴリズムはリゾルバとも呼ばれる)。 名前マッピングアルゴリズムは通常,コンテキストと呼ばれる追加パラメータで制御される. 与えられた命名規則に対して、多くの異なるコンテキストが存在する可能性があり、リゾルバが異なるコンテキストを使用する場合、名前空間の単一の名前が異なる値にマッピングされる可能性がある。 例えば、普通の会話で人が “you”、”here”、”Alice “という名前を呼ぶとき、それぞれの名前の意味は人がそれを口にするときのコンテキストに依存する。 一方、文脈が1つしかない命名法もある。 このような命名法は、ユニバーサルネームスペースと呼ばれるもので、その命名法の中では、誰が使っても常に同じ意味を持つという優れた特性を持っている。 例えば、米国では、政府の年金や税金の口座を特定する社会保障番号がユニバーサルネームスペースを構成している。 複数のコンテキストがある場合、インタプリタはリゾルバーにどのコンテキストを使うべきかを指示するか、リゾルバーがデフォルトコンテキストを使うことができる。

名前に関する以下の概念的な操作を定義することにより、命名モデルを要約することができる:

value ← resolve (name, context)

インタープリタはオブジェクトで名前を見つけると、まずどの命名体系が関係しているかを把握し、したがってどのバージョンの resolve を呼び出すべきかを決定する。 そして、適切なコンテキストを識別し、そのコンテキストで名前を解決し、解釈を続ける際に解決された値で名前を置き換えます。 変数contextは、resolveにどのコンテキストを使うべきかを指示する。

プロセッサでは、レジスタ番号が名前になります。 単純なプロセッサでは、レジスタ名のセットと、それらの名前がバインドされているレジスタは、両方とも設計時に固定されています。 名前を使用する他のほとんどのシステム(一部の高性能プロセッサのレジスタ命名方式を含む)では、新しいバインディングを作成したり古いものを削除したり、名前空間を列挙して既存のバインディングのリストを得たり、2つの名前を比較したりすることが可能である。 このような目的のために、さらに4つの概念的な操作を定義する。

status ← bind (name, value, context)

status ← unbind (name, context)

list ← enumerate (context)

result ← compare (name1, name2)

最初の操作は新しい結合を付加し文脈を変えるものである. ステータス結果は変更が成功したかどうかを報告します (提案された名前が名前空間の構文規則に違反する場合は失敗する可能性があります)。 bindの呼び出しに成功すると,resolveはnameの新しい値を返します。*2番目の操作unbindはコンテキストから既存のバインディングを削除し,statusは再び成功または失敗を報告します(おそらく既存のバインディングが存在しなかったためでしょう)。 unbindの呼び出しに成功すると,resolveはnameにその値を返さなくなります. bindとunbindの操作により、名前を使用してオブジェクト間の接続を作成し、後でその接続を変更することができます。 オブジェクトの設計者は、ある名前を用いてコンポーネントオブジェクトを参照することで、その時または後でbindを実行してその名前がバインドされるオブジェクトを選択し、unbindを実行してもはや適切でないバインドを排除することができます。 このようにバインディングを遅らせたり変更したりする機能は、ほとんどすべてのシステムの設計に利用されている強力なツールです。 名前付けの実装の中には、コンテキスト内で解決できるすべての名前のリストを返す enumerate オペレーションを提供するものがあります。 enumerateの実装によっては、現在コンテキストにバインドされているすべての値のリストを返すこともできます。 最後に、compare操作は、name1がname2と同じかどうかを(trueまたはfalseで)報告する。 same” の意味はセクション 2.2.5 で扱われる興味深い質問で、追加のコンテキスト引数を供給する必要があるかもしれません。

Different naming schemes have different rules about the uniqueness of name-to-value mappings. ある命名法では、名前は与えられたコンテキストで正確に1つの値にマッピングされなければならず、値は1つの名前しか持ってはならないという規則がありますが、他の命名法では1つの名前は複数の値にマッピングでき、1つの値は同じコンテキストでも複数の名前を持ってもかまいません。 もう一つの一意性規則は、一意識別子名前空間のもので、名前空間の存続期間中は決して再利用されず、一度束縛されると常に同じ値に束縛され続ける名前の集合を提供するものである。 このような名前は安定したバインディングを持つと言われている。 一意な識別子の名前空間に、値が1つの名前しか持てないという規則があると、一意な名前は、長期間にわたってオブジェクトを追跡したり、同じオブジェクトへの参照かどうかを比較したり、性能や信頼性のためにオブジェクトを複製するシステムで複数のコピーを調整するのに役立つ。 例えば、ほとんどの課金システムの顧客口座番号は、一意な識別子の名前空間を構成している。 口座番号は、顧客の住所、電話番号、あるいは個人名が変わっても、その口座が存在する限り、常に同じ顧客の口座を参照することになる。 お客様のアカウントが削除された場合、そのお客様のアカウント番号は、いつか別のお客様のアカウントに再利用されることはありません。 口座内の名前付きフィールド (支払残高など) は時々変更されるかもしれませんが、顧客口座番号と口座自体の間の結合は安定しています。

名前マッピング アルゴリズムと単一のコンテキストは、必ずしも名前空間のすべての名前を値にマッピングするわけではありません。 そのため、resolveの実行結果はnot-foundとなる可能性があり、resolveは呼び出し元に対して予約値または例外として伝達することができます。 一方,命名規則が1つの名前を複数の値に対応付けることを許可している場合,可能な結果は値のリストである。 その場合、バインド解除操作には、どの値をバインド解除するかを指定する追加の引数が必要になることがある。 最後に,いくつかのネーミングスキームは逆検索を提供する。これは,呼び出し側がネームマッピングアルゴリズムへの引数として値を供給し,どの名前または名前がその値に束縛されているかを見つけることができることを意味する。

実際には、3つの頻繁に使用される名前マッピングアルゴリズムに遭遇する:

Table lookup

Recursive lookup

Multiple lookup

コンテキストで最もよくある実装が{名前、値}対の表である。 コンテキストの実装がテーブルである場合、名前マッピングアルゴリズムはそのテーブル内の名前のルックアップに過ぎない。 テーブル自体はハッシュやB-treeを含む複雑なものであっても、基本的な考え方は同じである。 新しい名前と値を結びつけるには、その{name, value}のペアをテーブルに追加すればよい。 図2.11に、この一般的なネーミングモデルの実装を示す。 各コンテキストにこのようなテーブルが1つあり、異なるコンテキストは同じ名前に対して異なるバインディングを含むことができる。

Figure 2.11. 名前マッピングのアルゴリズムとしてテーブル・ルックアップを使用するシステム。 図2.10の例と同様に、このシステムも名前「N4」を値「13」に解決する。

一般的なネーミングモデルとテーブルルックアップ実装の両方の実世界の例が豊富にある。

電話帳は、人および組織の名前を電話番号に結びつけるテーブルルックアップコンテクストである。 データ通信ネットワークの例と同様に、電話番号はそれ自体が名前であり、電話会社はエリア コード、交換機、および物理スイッチギアを含む名前マッピング アルゴリズムを使用して、物理的な回線アピアランスに解決されます。 ボストンの電話帳とサンフランシスコの電話帳は、同じ命名スキームの2つのコンテキストです。ある特定の名前が両方の電話帳に表示されることがありますが、その場合はおそらく異なる電話番号にバインドされているのです。

メモリセルも同様にアドレスと呼ばれる数値で命名され、名前から値へのマッピングは再び配線によって達成される。 第5章では、仮想アドレスのブロックを連続するメモリセルのブロックに結合する、仮想メモリと呼ばれるアドレスの改名機構について説明する。 システムが複数の仮想メモリを実装している場合、各仮想メモリは個別のコンテキストであり、あるアドレスは各仮想メモリ内の異なるメモリセルを参照することができる。 メモリセルは仮想メモリ間で共有することもでき、その場合、同じメモリセルは、バインディングによって決定されるように、異なる仮想メモリにおいて同じ (または異なる) アドレスを持つことができます。 ディレクトリはテーブル ルックアップ コンテキストの例です。 あるファイル名は複数の異なるディレクトリに存在し、同じファイルまたは異なるファイルに束縛されることがあります。

コンピュータは、ネットワーク接続点として知られる場所で、データ通信ネットワークに接続する。 ネットワーク・アタッチメント・ポイントは通常、2つの異なる命名方式で命名される。 1つは、ネットワーク内部で使用されるもので、固定長のフィールドの数字からなる名前空間が含まれます。 これらの名前は、ネットワークの物理的な入口と出口に、あるときは恒久的に、あるときは短期間だけ結びつけられます。 第二の命名方式は、ネットワークのクライアントが使用するもので、文字列からなるより使いやすい普遍的な名前空間を、第一の名前空間の名前にマッピングするものである。

A programmer identifies procedure variables by names, and each activation of the procedure provides a distinct context in which most such name is resolved. 静的」 または 「グローバル名」 として識別される一部の名前は、アクティブ化間または異なるプロシージャー間で共有されるコンテキストで解決される可能性があります。

World Wide Web の Uniform Resource Locator (URL) は、URLをいくつかの構成部分に分割し、異なるネーミングスキームを使用して部分を解決する比較的複雑なアルゴリズムによって、特定の Web ページにマッピングされます。

顧客の請求システムは通常、各顧客のアカウントに対して少なくとも 2 種類の名前を保持します。 アカウント番号は、一意の識別子の名前空間でアカウントに名前を付けますが、アカウントを識別するために使用することもできる個人名の明確な名前空間も存在します。 これらの名前の両方は、通常データベースシステムによってアカウントレコードにマッピングされ、アカウントはアカウント番号または個人名によって検索できるようになっています。 すべてではありませんが、コンテキストによっては、一般にその名前を持つと考えられているオブジェクトに名前を対応付けるという意味で、物事を「名付ける」ものがあります。 したがって、電話帳は人にも電話線にも「名前」をつけない。 どこかに、名前を人に結びつけ、電話番号を特定の物理的な電話機に結びつける文脈がある。 電話帳は、人の名前と電話の名前を結びつけています。

コメントを残す

メールアドレスが公開されることはありません。