分散システムのための Styx アーキテクチャ

Rob Pike
Dennis M. Ritchie
Computing Science Research Center
Lucent Technologies, Bell Labs
Murray Hill, New Jersey
USA
NOTE: Originally appeared in Bell Labs Technical Journal, Vol. 4, No. 2, April-June 1999, pp. 146-152.
Copyright © 1999 Lucent Technologies Inc. All rights reserved.

概要

分散システムは、お互いに独立した各部分が集まって構成され、 その集合体が場所的にも機能的にも分散していながら、 統一された形を作りあげています。その例としてはネットワークOS、 インターネットサービス、国際電話通信網、さらに一般的には、今日の デジタルネットワークを使うすべての技術が分散システムといえます。 しかしながら分散システムの設計、構築、保守は依然として困難な ままであり、その主な原因は、簡単明瞭な相互接続のモデルが欠けて いるためだと思われます。

Plan 9 と Inferno という二つの分散システムを通して我々が得た経験は、 上記のようなモデルを提案する助けになりました。これらのシステムは、 ある有用なアイディアのもとして作られ、それが実際に有効であることを 示していますし、またシステムの大部分において、そのアイディアができる かぎり利用されています。その アイディアとは、システムの持つ資源を、階層的な名前空間の中に置かれた ファイルとして提供する、ということです。ファイルとしてあらわされる ものの実体は保存されたデータかもしれませんし、あるいはデバイス、 動的情報のソース、サービスへのインタフェース、制御の参照口かも しれません。この手法によって、全てのシステム資源に対して統一された 基本的な名前付け、構造付け、アクセス制御のメカニズムを提供することが できるようになります。これを支える Styx という単純なネットワーク プロトコルがこのアーキテクチャの中心となって、システム内通信のための 共通の言葉を提供しているのです。

分散されてないシステムでさえ、サービスをファイルとして提供 することで、使いなれた名前付け、アクセス制御、システム資源との 結びつきを大幅に拡張できます。しかし、より重要なのは、リモートファイル システムと接続するという良く知られた技術を使うことで、この手法が 分散システムを構築するための自然な方法をとなるという事です。 資源がファイルとして提供されていて、しかもリモートファイルシステムが あるのなら、それはすでに分散システムなわけです。ある場所で利用 できる資源は、別の場所からも利用できるわけです。

導入



Styx プロトコルは 9P と呼ばれるプロトコルの一種です。 9P は Plan 9 オペレーティングシステム [9man] のために開発されました。 簡単のために、ここでは Styx という名前を使うことにしますが、この二つは 接続開始時の部分が違うだけです。

Styx の背景にあるもともとのアイディアは、クライアントとファイルシステムの 間にあるファイル操作を、コンピュータネットワークで転送するための メッセージに符号化するというものでした。この技術によって、Plan 9 は ファイルサーバ-長期保存のファイルを集約的に貯蔵する場所- を、 CPU サーバ-大規模な共有メモリのマルチプロセッサ- とユーザの利用する端末 から分離しています。このように、役割が異なるものを物理的に分離するという 考え方がこのシステムの基本設計の中心にありました。 従来ファイルシステムに関係ないと考えられていた様々な問題を 解決するのに、このモデルを用いることができるというのは、 我々も予期していませんでした。

ネットワークを介して計算資源を利用可能にするのに生じる困難の多くが、 資源をファイルという形で提供することで、自然に解決されるということに 気付いたのが大きな一歩となりました。これは、Styx がファイルという資源を 透過的に外部に提供することができたからです。例えば、Plan9 のウィンドウ システムである [Pike91]は、ローカルなハードウェアへの アクセスに対し、 /dev/mouse/dev/screen といったファイルを提供する動的なファイルサーバとして実装されています。 例えば /dev/mouseは、UNIXTM のデバイスファイルと 同じように、通常のファイルとしてオープン、読み込みが行なえますが、 ではこのファイルが多重化されます。それぞれのクライアントプログラムは 自分用の /dev/mouse を持っており、自分のウィンドウがディスプレイの中でアクティブな時にのみ マウスのイベントが返されます。このような設計によって、マウスへの アクセスを制御する仕組が簡潔でわかりやすいものになります。 しかしながら、その本当の長所は、ウィンドウシステムの資源をファイルで 表現することで、Styx がそれらのファイル(=資源)をネットワークを 介しても提供できるようになることなのです。 例えば、CPU サーバ上でグラフィックを利用したインタラクティブなプログラムを 実行したいときには、単純に が適当なファイルをそのサーバに提供すれば良いわけです。 Styx によって公開される資源はファイル-資源にはファイル名、ファイル パーミッション、ファイルアクセスの方法が与えられます-のように 振舞いますが、 それらがディスク上に実際のファイルとして存在する必要はないことに 注意してください。 /dev/mouse ファイルは通常の I/O 機能を介してアクセスされますが、これは実際には 一時的なもので、実行中のプログラムによって動的に作りあげられている ものなのです。それ自体には恒久的な実体は存在しません。

この手法をシステム全体に渡って進めていくことで、Plan 9 は 資源開放の透過性について、目をみはるようなレベルを実現しました[PPTTW93]。 インタラクティブなグラフィックの他にも、デバッグや保守、ファイルバックアップ、 果ては下層のネットワークハードウェアへのアクセスですら、Styx によって ネットワークを介して利用することができます。そして、単なるファイルの I/O 以上に高度な技術を使うことなく、分散アプリケーションや分散サービスを 構築することができるのです。

Styx プロトコル



Styx が占める位置というのは、Sun の NFS [RFC][NFS] や、Microsoft の CIFS[CIFS] に類するものでしょう。しかしながら、Styx はこれらのものよりも 単純で簡単に実装できます[Welc94]。 さらに、NFS や CIFS はディスク上にある通常のファイルを共有するために 設計されています。中でも NFS は、その下にある UNIX ファイルシステムの 実装とキャッシュ方法と密接に結びついています。また、NFS や CIFS は Styx と異なり、 /dev/mouse といったような、動的に変化するデバイス的なファイルを外部に提供するのに 向いていません。

Styx は階層的な木構造をしたファイルシステムの名前空間[Nee89]に加え、 ファイルに関するアクセス情報(パーミッション、サイズ、日付)や、 ファイルを読み書きするための手段を提供します[Nee89]。 ユーザ(つまりアプリケーションプログラムを書く人たち) がそのプロトコルを 直接知る必要はなく、かわりに彼らはファイルを参照して、それらの 読み書きを行います。これで情報を提供したり変更したりしたことになるのです。

実際の運用では、他と通信を確立する、一台のマシン上で動作している Styx のクライアント と、その通信相手である サーバ が 同じマシンで動作していても、また 違うマシンで動作していてもかまいません。クライアント側の機能は、 Plan 9 や Inferno のようにオペレーティングシステムに作り込まれていても いいですし、またアプリケーションのライブラリでもかまいません。 サーバもまた、オペレーティングシステムの一部であってもいいですし、 まったく同様に、他のマシンで動作するアプリケーションであってもいいのです。 どちらにしろ、クライアントとサーバはメッセージを交換することで通信します。 そしてその結果、サーバに存在する階層的なファイルシステムが、クライアント から参照できるというわけです。Styx プロトコルは、この交換される メッセージに関する規格なのです。

ある階層では、Styx は以下のように分類される 13 種類のメッセージに よって構成されています。
*
通信を開始する (ファイルシステムに接続する);
*
ファイルシステム内を探索する (つまり、必要なファイルの名前を指定し、 それに対するハンドルを得る);
*
ファイルに対する読み書きを行う;
*
ファイルの情報に対する照会、変更を処理する。


しかしながら、アプリケーションのプログラマはファイルに対するオープン、 読み込み、書き込みの操作を記述するだけです。ライブラリあるいは オペレーティングシステムがこれらの要求を必要なバイト列に変換し、 通信チャネルを通じて転送します。Styx プロトコルはこのバイト列の 解釈をきちんと定義しています。このプロトコルは、ISO の OSI で 言えば、だいたいセッション層に相当するものです。その仕様は マシンアーキテクチャの詳細とはほとんど無関係であり、実際、 様々な命令セットやメモリレイアウトのマシンの間でうまく 動作しています。プロトコルの 概要を Table.1 に示します。
名前 説明
attach 接続するユーザを認証する; FID を返す
clone FID をコピーする
walk FID を一つしたの階層に移動する
open ファイル I/O のパーミッションをチェックする
create 新しいファイルを作成する
read ファイルの中身を読む
write ファイルの中身を書く
close FID を開放する
remove ファイルを削除する
stat ファイル情報を得る: パーミッションなど
wstat ファイル情報を変更する
error 失敗した操作のエラー状態を返す
flush 未実行の I/O 要求を無視する
Table.1 Styx メッセージの概要

実際は、次のような操作は複数の Styx メッセージ列へと、システムの下層部分に よって変換されます。
open("/usr/rob/.profile", O_READ);
ファイルサーバへの接続が初めて確立されると、 attach メッセージによってユーザ(ファイルをアクセスしようとしている人、あるいは エージェントプログラム)が認証され、 FID (file ID) と呼ばれるオブジェクトが返されます。この FID はそのサーバの階層の ルートを表わしています。 open() が実行されると、次のように処理が進みます。
*
ルートへの接続を保ったまま階層内を移動できるように、 clone メッセージによってルートの FID がコピーされ、 新しい FID が返されます。
*
次に、 walk メッセージが複数発行され、この新しい FID がパスの中身を一つづつ移動 (usr, rob, .profile) してゆき、 /usr/rob/.profile ファイルへと辿りつきます。
*
最後に、このファイルを読み込めるかどうか open メッセージによって ユーザのパーミッションがチェックされ、続く read あるいは write メッセージによる操作をこの FID に対して行うことが許可されます。
*
I/O 操作が終了したら、 close メッセージによって FID は開放されることになるでしょう。


Styx の実装が一つ下の層に対して要求するのは、バイトストリームでの 信頼できるトランスポート通信層だけです。例えば、Styx は インターネットプロトコル標準の転送制御プロトコルである TCP/IP か、 IP パケットを利用した、信頼できる順序ありデータグラムプロトコルである インターネットリンク (IL) プロトコルの、どちらの上でも動作します。 しかしながら、モデル自体は、構成要素を結ぶための実在するネットワークを 必要としているわけではないことに注意してください。Styx は Unix のパイプや 共有メモリ上でも十分動作します。この手法の強みは、ネットワーク上で動作する ということではなく、ネットワークを通した場合でも、ローカルに実行される 場合でも、そのどちらでも同じ動作をするということにあるのです。

アーキテクチャの手法



Styx はファイルシステムプロトコルの一つですから、資源をファイルとして 提供するという、さらに大きなシステム設計手法を構成する要素でしか ありません。この手法について議論するために、これからいくつかの例を 挙げていきたいと思います。

ネットワーク通信の例



この例では、TCP/IP ネットワークへのアクセスが、Inferno や Plan 9 システムの中で、ファイルシステムの一部として、次のような構成で 表現されていることを示しています(一部省略されています) [PrWi93]。
/net/
	dns/
	tcp/
		clone
		stats
		0/
			ctl
			status
			data
			listen
		1/
			...		
		...
	ether0/
		0/
			ctl
			status
			...
		1/
			...
	...
これは、 /net/dns/net/tcp/clone/net/tcp/0/ctl といった「ファイル名」によって、ファイルを指定したり 読み書きが行えるファイルシステムを表わしています。 /net/tcp/net/ether0 といったディレクトリもみられます。 実際のネットワークインタフェースを持つマシンの場合であれば、 これらファイルのように見えるものはすべて、TCP/IP スタックを 処理するカーネルのドライバによって構成されます。つまり、 これらのファイルは実際にディスク上にあるファイルではないのです。 これらの「ファイル」に対する操作はデバイスドライバへの操作へと 変換されます。

あるアプリケーションが TCP/IP によって www.bell-labs.com との通信を確立しようとするとします。 まず最初に必要な処理は、 www.bell-labs.com というドメインネームを数字で表わされるインターネットアドレスへと 変換することです。これは複雑な処理で、通常、ローカルあるいはリモートの ドメインネームサーバとの通信を必要とします。 Styx のモデルでは、この処理は /dev/dns というファイルをオープンし、そのファイルに対して www.bell-labs.com という文字列を書き込むことになります。 次にそのまま同じファイルに対して読み込みを行うと、 検索の結果が204.178.16.5 という 12 文字の文字列として返されるはずです。

こうしてインターネットアドレスが得られると、そのアドレスに対する 通信路を確立しなくてはなりません。このためには、 /net/tcp/clone というファイルを開き、 /net/tcp/43 というような、ディレクトリ名をあらわす文字列を読み込みます。 このディレクトリは、新規に作成された一本の TCP/IP チャネルを あらわしています。次に、 connect 204.178.16.5 というメッセージを、このディレクトリにある /net/tcp/43/ctl ファイルに書き込むことで、このチャネルによる通信路を確立します。 これ以降、 www.bell-labs.com との通信はすべて、 /net/tcp/43/data というファイルを読み書きすることで行えます。

この手法について、目をとめてもらいたい点がいくつかあります。
*
すべてのインタフェースはファイルのようにみえ、すでに C や C++、Java といったプログラム言語から利用できるのと同じ I/O 機能を使ってアクセス できます。しかしながら、これらのインタフェースを提供するファイルには、 対応してディスク上に存在するデータファイルはありません。そのかわり、 これらのファイルはミドルウェアのプログラムによって提供されている ものです。
*
基本的に、インタフェースとのやりとりはバイナリによる表現ではなく、 できるかぎり表示可能な文字列を使って行うことになっています。 これはつまり、インタフェースとのやりとりのシンタックスが、 CPU アーキテクチャや言語の細かい部分に依存しないということです。
*
ネットワーク通信機能へのインタフェースである /net の例のように、 インタフェースが階層ファイルシステムの一部であるため、これを 遠く離れた場所にあるリモートマシンへと開放するのは簡単で、ほぼ 自動的に実現されます。


特に、Styx の実装は、きちんと制御されたネットワークへのアクセスを、 自然な方法で提供するのを助けます。 他の多くの組織と同様 Lucent にも、国際的なインターネットへは 接続できない内部ネットワークと、内外ネットワークの間に置かれた 数個のゲートウェイがあります。ゲートウェイのマシンだけが 内外両方のネットワークに接続され、安全と保証のために、そのマシンの 上で管理制御が実現されています。Styx モデルの持つ長所を利用することで、 内側から外部のインターネットを利用するのがより簡単に なります。上でのべた /net 以下のファイル構造がゲートウェイのマシン上で提供されれば、 それは内側のマシンからリモートファイルシステムとして使用する ことができます。内側のマシンは外部へのネットワークインタフェースを 参照できますが、その逆はできない一方通行の通信なので、これは 安全と言えます。

デバッギングの例



UNIX システムからとりこまれ、さらに一般化された方法 [Kill] ですが、 オペレーティングシステムで実行中のプロセスの状態を取得したり、 これを制御したりするのも、同様なやりかたで実現できます。 /proc というディレクトリ内には、システム上で実行中のプロセスそれぞれに 対応するサブディレクトリが置かれています。サブディレクトリ名は 対応するプロセスのプロセス ID になります。
/proc/
	1/
		status
		ctl
		fd
		text
		mem
		...
	2/
		status
		ctl
		...
	...
プロセスがもつ様々な要素に対応するファイルが、各プロセスの ディレクトリ内に存在します。 status ファイルにはプロセスの状態に関する状態が保持されています。 ctl に書きこみを行うことで、プロセスの一時停止や実行再開、 強制終了などの操作を行うことができます。 fd はそのプロセスによって使用されているファイルについて、 その名前などを保持しています。 textmem はそれぞれ、プログラムのテキストセグメントやデータセグメントの 内容を保持しています。

これらの情報や制御コマンドもまた、できるかぎりテキスト文字列に よって表現されています。例として、典型的なプロセスの status ファイルから一行抜き出してみると、次のようになるでしょう。
samterm dmr Read 0 20 2478910 0 0 ...
これらはプログラムの名前、プロセスのオーナと状態、消費した CPU 時間を あらわすいくつかの数字などです。

繰り返しますが、この手法にはいくつかの特長があります。 プロセス情報がファイルの形で提供されるため、他のマシン上にある /proc をリモートマウントすることで、即座にリモートデバッギング (他のマシン上のプログラムをデバッグすること) が可能になると いうことです。 マシンに依存しない形で情報を提供することはつまり、デバッグを 行っているマシンとリモートマシンが異なる CPU アーキテクチャを 持つものだったとしても、だいたいの操作は正しく動作するという ことになります。 プロセスの状態を操作したり、制御をおこなったりするプログラムの ほとんどはマシンに依存しないものであり、これらは完全に移植可能 なのです(もちろん例外もあります。メモリ上のデータや命令コードを マシンに依存しない形で提供しようとはしていません)。

PathStarTM アクセスサーバの例



Lucent 社製 PathStar アクセスサーバ[PATH] のデータシェルフは、 シェルフに差された回線接続ボードや他のデバイス等を制御コンピュータと 接続するの Styx を使用しています。実は、バックプレーンでの上位通信 プロトコルが Styx なのです。制御コンピュータによって提供される ファイルシステム階層の一部は、次のようになっています。
/trip/
	config
	admin/
		ospfctl
		...
	boot/
		0/
			ctl
			eeprom
			memory
			msg
			pack
			alarm
			...
		1/
			...
/net/
	...
/net 以下のディレクトリは Plan 9 や Inferno と同様、外部 IP ネットワークへの インタフェースとなっています。 /trip 以下の階層は、シェルフの制御をおこなうためのものです。

/trip/boot サブディレクトリ以下は、シェルフに差された回線接続ボードや、その他の機器 それぞれへのアクセスを提供します。 例えば、あるボードを初期化するためには、 reset という文字列をそのボードの ctl ファイルへと書きこみます。一方、制御用のソフトウェアをそのボードの memory ファイルへとコピーし、 reset メッセージを ctl ファイルに書きこむことで、ブートストラッピングが行えます。 いったん回線接続ボードが動作しはじめると、他のファイルによってさらに上位の システムに対するインタフェースが提供されます。 pack は IP パケットをボードと受け渡しするためのポートになります。また、 ボードの状態に特に目立ったことがないか調べるため、 alarm から読み込みを行う等々です。

これらの階層はすべて、シェルフ自体からも Styx によって外部に開放されます。 外部の構成機器管理ソフトウェア (EMS) は Styx によってシェルフの監視や 制御を行います。例えば、EMS は /trip/boot/7/alarm を読むことで、ボードが診断を必要とする状態にあると判断するかもしれません。 そして、EMS を実行しているシステムから /trip/boot/7/ 以下にある他のファイルを読み書きすることで、 このボードの動作を停止し、診断を行い、おそらくはリセットをかけるか、 他のボードに動作を移すといった操作が全ておこなえます。この EMS は ネットワークのどこにあってもかまわないわけです。

別の例として、PathStar アクセスサーバでの SNMP の実装例があげられます。 SNMP を動作させている機器は、ネットワーク内の様々な構成要素として分散して いるのが普通です。ここで、SNMP の要求を Styx の操作へと変換する、ごく単純な 変換プロセスを、ネットワーク内で一つ動作させます。これは実装を非常に 単純なものにできるだけでなく、このように自然な形で集約をおこなえる 機能があることで、SNMP アクセスを提供するたった一つのプロセスによって、 どのように複雑なネットワークサブシステムにも対応することができます。 しかしながら、この操作の本質はファイル操作にもとづくため、標準的な 認証を行い、信用できるグループだけが SNMP によるアクセスを許可されるよう 保証することが簡単に実現できます。ですから、この構造は安全なものと 言えます。

ローカルな部分でもまた、このアーキテクチャによって得られる利点があります。 それは、下位の具体的な構成機器の詳細と制御部分を切り分ける個所を、 設計上の一点に限定することができるということです。 これによって、相互の変更を隠蔽することができます。 構成機器を柔軟に組み合わせることができるようになりますし、 ハードウェア部分に隠れている依存性を気にすることなく、 ソフトウェアをアップグレードできます。 また、上位の制御ソフトウェアをアップデートすることなく、 新しいハードウェアを追加することもできます。

セキュリティの問題



故意であれ偶然であれ、システムの動作を阻害するような行為から、 システムを守るための機能を Styx は提供します。

下位で動作しているファイル通信プロトコルには、サーバが認証に利用するための ユーザとグループを識別する情報が含まれています。例えば、ファイルを オープンするという要求に対して、その要求を発したユーザの ID が、その 操作を行なうことが許可されているかどうか、サーバは確認することができます。 この機能は汎用目的のオペレーティングシステムに見られるもので、その 使い方についてもすでによく知られています。この機能は、パスワードや、 さらに安全な方法によって、クライアントの実体が認証される事に依存して います。

Styx がファイルシステムをリモートな資源として、ネットワークを介して 開放すために採用した手法は、アプリケーションと、それが 利用する資源の両方ともが、認証のためのやりとりをせずにすむよう、 資源に対するアクセスを、アプリケーションから透過的に完全に保護する 大きな助けとなります。 たとえば Inferno では、クライアント-サーバ間での最初の通信確立時に、 通信路を監視するための暗号化、あるいはメッセージダイジェストの プロトコルを数種類のうちから自由に選択できるようになっています。 サーバ上の資源を利用するアプリケーションは全て妨害から保護され、 また、サーバ側は機能が適切な方法で使用されているという保証を確実に 得ることができるわけです。 以上は一般的なファイルサーバに有効なだけでなく、電話通信業界における 安全なリモート管理の実現にも特にあてはまります。

まとめ



資源をファイルシステムの一部として提供し、それがリモートファイルシステムと して扱われても構わないというのは、分散システムを構築する際、次のような 両極端の間を行く、とても有望な手法です。
  1. システム外との通信は全て、構成要素間でメッセージを明示的に送ることで 行う。この通信は、ローカルな資源を利用するときとは違った方法で アプリケーションから使用される。
  2. 通信は全て、密接に共有された資源を利用して行われる。具体的には CPU からアクセスできる様々なメモリ領域を、大規模なネットワークを 介して直接参照できるようにする。アプリケーションは遠隔地のオブジェクトを、 自分が実行されている CPU のように、同じマザーボード上にあるかのように 読み書きできる。


一つめにあげられているのは、現在のシステムでごく普通に見られるものですが、 その機能を利用するオペレーティングシステムやソフトウェアは、大雑把な範囲を カバーするだけです。次にあげられているものを実現するのはさらに難しいです。 ネットワークの信頼性は(インターネットのように大きなものは特にそうですが) 特に高いというわけではありませんし、さらに、ネットワーク上にある マシンでは様々なアーキテクチャのプロセッサやソフトウェアが利用されて いるからです。

これまで述べられ、主張されてきた設計は、この両極端の間に位置するもので、 次のような特長を持っています。
*
簡単で馴染のあるプログラミングモデルによる、名前で指定される ファイルの読み書き。ファイルシステムにはしっかりと定義された 名前付け、アクセス、許可の構造があります。
*
プラットフォームや言語に無関係である。 資源を参照する下位構造はファイルレベルにありますから、どのシステムでも ほぼ利用することが可能で、特定の言語やオペレーティングシステムの機能に 依存しません。この機能を利用するための、C++ や Java のクラス、C 言語の ライブラリを作ることもできます。
*
階層化された名前付けおよびアクセス制御構造。 資源の名前付け、アクセスの設計をわかりやすく、良く構造化されたものにする 助けになります。
*
簡単な試験とデバッグ作業。 細かく規定された、限定されたインタフェースをファイルレベルで利用することで、 分散されたもの同士の通信を簡単に観察することができます。
*
低コスト。 サポートソフトウェアは数千行のプログラムで作成でき、機器の容量を 少し占有するだけですみます。これはクライアントとサーバ両方を合計しての 話です。


以上のシステム設計手法は、汎用システムである Plan 9 と Inferno において 有効に働き、また電話通信に特化した Mantra[MAN] や PathStar アクセスサーバを 製作するのにも利用されました。この手法は、単一のシステム内での通信と、 大規模なディジタルネットワークを構成する異なる機器同士の外部通信両方に、 統一された拡張可能な構造を提供します。

参考文献
[NFS]
R. Sandberg, D. Goldberg, S. Kleiman, D. Walsh, and B. Lyon, ``Design and Implementation of the Sun Network File System'', Proc. Summer 1985 USENIX Conf., Portland, Oregon, June 1985, pp. 119-130.
[RFC]
Internet RFC 1094.
[9man]
Plan 9 Programmer's Manual, Second Edition, Vol. 1 and 2, Bell Laboratories, Murray Hill, N.J., 1995.
[Kill84]
T. J. Killian, ``Processes as Files'', Proc. Summer 1984 USENIX Conf., June 1984, Salt Lake City, Utah, June 1984, pp. 203-207.
[PPTTW93]
R. Pike, D.L. Presotto, K. Thompson, H. Trickey, and P. Winterbottom, ``The Use of Name Spaces in Plan 9'', Op. Sys. Rev., Vol. 27, No. 2, April 1993, pp. 72-76.
[PrWi93]
D. L. Presotto and P. Winterbottom, ``The Organization of Networks in Plan 9'', Proc. Winter 1993 USENIX Conf., San Diego, Calif., Jan. 1993, pp. 43-50.
[Nee89]
R. Needham, ``Names'', in Distributed systems, edited by S. Mullender, Addison-Wesley, Reading, Mass., 1989, pp. 89-101.
[CIFS]
Paul Leach and Dan Perry, ``CIFS: A Common Internet File System'', Nov. 1996, http://www.microsoft.com/mind/1196/cifs.htm.
[INF1]
Inferno Programmer's Manual, Third Edition, Vol. 1 and 2, Vita Nuova Holdings Limited, York, England, 2000.
[INF2]
S.M. Dorward, R. Pike, D. L. Presotto, D. M. Ritchie, H. Trickey, and P. Winterbottom, ``The Inferno Operating System'', Bell Labs Technical Journal Vol. 2, No. 1, Winter 1997.
[MAN]
R. A. Lakshmi-Ratan, ``The Lucent Technologies Softswitch-Realizing the Promise of Convergence'', Bell Labs Technical Journal, Vol. 4, No. 2, April-June 1999, pp. 174-196.
[PATH]
J. M. Fossaceca, J. D. Sandoz, and P. Winterbottom, ``The PathStar Access Server: Facilitating Carrier-Scale Packet Telephony'', Bell Labs Technical Journal, Vol. 3, No. 4, October-December 1998, pp. 86-102.



Portions copyright © 1995-1999 Lucent Technologies Inc. All rights reserved.
Portions copyright © 2000 Vita Nuova Holdings Limited. All rights reserved.