Keio Media Space Board for KMSF-CODE
の
設計，実装，評価
大越匡1 岩本健嗣1 中澤仁2 永田智大2 望月祐洋3 徳田英幸1 ;3
1 慶應義塾大学環境情報学部 2 慶應義塾大学総合政策学部
3 慶應義塾大学政策・メデ ィア研究科
Keio Media Space Family (KMSF) プロジェクトでは，複数の主体間での知的協調作業を
支援する KMSF 環境を構築している．本稿では分散協調オブジェクトに基づく KMSF-CODE
(Collaborative Object on Distributed Environment) アーキテクチャ上での Keio Media Space
Board の設計，実装及びその評価について述べる．
1
はじめに
2
小型化，高性能化，低価格化に伴う計算機
の普及，通信機器の発達や無線通信網の整備
などに伴う，インターネットをはじめとする
分散ネットワークの普及によって，場所や時
間に限定されないネットワークの利用が可能
となり，人間のさまざまな活動の場での計算
機の利用機会が増加している．
計算機，ネットワークは，多様な情報やサー
ビスへのアクセスの道具であると同時に，人
間同士のコミュニケーションの手段としても
活用されている．
計算機ネットワークの利点の一つは世界規
模の情報共有が可能となる点であるが，既存
のファイルシステムでの情報共有から，複数
の主体間での対話的な情報の交換の中で，よ
り動的かつ柔軟な情報の創造，共有を提供す
る環境が重要となってきている．
Keio Media Space Family (以下 KMSF) プ
ロジェクトでは，分散実時間マイクロカーネ
ル，実時間ネットワークプロトコル，統合メ
ディアサーバ，連続メディアベースなどの技術
を利用し，複数の主体間での知的協調作業を
支援する KMSF 環境 [1, 2] を構築している．
本稿では分散協調オブ ジェクト に基づく
KMSF-CODE アーキテクチャ[4] 上での Keio
Media Space Board の設計，実装及びその評
価について述べる．
Keio Media Space Board for KMSF-CODE: Design,
Implementation, and Evaluation
1 Takeshi IWAMOTO1 , Hitoshi
2
2
Tomohiro
NAGATA ,
Masahiro
3
1; 3
MOCHIZUKI , and Hideyuki TOKUDA
1 Faculty of Environmental Information, Keio UniverTadashi OKOSHI ,
NAKAZAWA ,
sity
2 Faculty of Policy
3 Graduate School
University
Management, Keio University
of Media and Governance, Keio
2.1
KMSF
での知的協調作業
KMSF
KMSF は，Keio Media Space Board (以下
KMSB) と Keio Media Space Navigator (以下
KMSN) を中心にこれらと協調動作するハード
ウェア，ソフトウェアから構成される統合環境
であり，人間の物理的共同作業空間と，仮想
的共同作業空間とをシームレスに統合し，複
数の主体からなるグループの知的協調活動を
支援することを目標としている．
KMSB は，ネットワーク上の仮想的な掲示
板またはホワイトボード として位置付けられ，
サーバとして情報の蓄積，提供，管理を行な
う．KMSN は，KMSB 上の情報を参照し，ユー
ザの知的活動を支援するためのナビゲータで
ある．
ユーザは KMSF 上の情報を，各個人の用い
る携帯端末からネットワークを通して任意に知
覚1 ，掲示，編集することができる．KMSF で
は，KMSB 上に情報を掲示する動作を post-it，
逆に KMSB から情報を取り出す動作を fetch-it
と呼ぶ．
2.2
既存のアーキテクチャ
既存のアーキテクチャとしては，受動型オ
ブジェクトモデルに基づく KMSF アーキテク
チャ[2] と，自律分散オブジェクトモデルに基
づく KMSF アーキテクチャ[3] が開発されて
いる．
受動型オブジェクトモデルに基づく KMSF
アーキテクチャは，クライアント・サーバモデ
ルによる KMSB, KMSN からなるアーキテク
チャで，テキストデータを中心としたメッセー
ジング環境である．画像，音声などのマルチ
メディアデータへの対応は行なわれていない．
1 文字や映像の情報の視覚での認識だけでなく，音声情
報などの聴覚での認識も含む．
一方，自律分散オブジェクトモデルに基づ
く KMSF アーキテクチャは，クライアント
・サーバモデルを用いず，計算機ごとに実行
される複数の Connection Manager の協調に
よって KMSF 環境を実現している．複数の
Connection Manager 間に恒常的なトラフィッ
クが発生し，多人数のコミュニティによる利用
では，ネットワークに恒常的な負荷が生じる．
2.3
KMSF-CODE アーキテクチャ
KMSF-CODE (Collaborative Object on
Distributed Environment) アーキテクチャは，
マルチメディアデータの取り扱い，テキスト・
画像などのメデ ィア情報やソフトウェア部品
であるコンポーネントの「オブジェクト 」と
しての一元的な処理，ナビゲータのマルチプ
ラットフォーム化によるヘテロジニアスな分
散ネットワーク上における利便性の向上と言っ
た点を重視して設計された，分散協調オブジェ
クトに基づく KMSF アーキテクチャである．
KMSF-CODE アーキテクチャでは，テキス
ト，画像，音声などのメディア情報を \ MediaCO (Media Collaborative Object)"，各メディ
アの表示機能，編集機能その他のソフトウェ
ア部品を \Component-CO (Component Collaborative Object )"，CO の任意の組合せを
\HO (Hyper Object)" と呼び，これらを総称
して \オブジェクト " と呼ぶ．
3
post-it
fetch-it
list-it
info-it
Application
Application
HOTp
HOTp
SocketAPI
SocketAPI
TCP/IP
TCP/IP
Kernel
Kernel
図 1: KMSN-KMSB 間の通信モデル
Hyper Object Transfer Protocol
Hyper Object Transfer Protocol (以下
HOTp) は，KMSF-CODE 上で，オブジェク
トやそれに付随する情報を転送するための通
信プロトコルである．KMSN-KMSB 間の通信
オブジェクトを投稿する動作
オブジェクトを取り出す動作
Object Storage 中のオブジェクトの
リスト情報を取り出す動作
オブジェクトの属性情報を取り出す動作
は，KMSN から KMSB への４つのメソッド，
post-it，fetch-it，list-it，info-it からなる．表
1に示す．
これらメソッド は，表 2 に示す６つのメッ
セージを組み合わせることによって実現される．
表 2: HOTp メッセージ
1. オブジェクトを投稿する
POST <ObjectName>[CRLF]
Content-Length: <ObjectSize>[CRLF]
<Object>
2. オブジェクトの送信要求をする
FETCH <ObjectName>[CRLF]
3.Object Storage 内のオブジェクトの
リストを要求する
LIST <ObjectStorage/Directory>[CRLF]
4. オブジェクトの情報を要求する
INFO <ObjectName>[CRLF]
5. 各要求に対する回答を送る
REPLY[CRLF]
Content-Length: <MessageSize>[CRLF]
<Message>
KMSF-CODE における通信機構
KMSF-CODE における KMSN-KMSB 間の
通信は，クライアント・サーバモデルに基づく，
TCP/IP プロトコルによるコネクション指向
の通信である．また，Hyper Object Transfer
Protocol を開発し，既存の World Wide Web
(WWW)[5] との互換性も高めている．
3.1
表 1: HOTp メソッド
6. 各要求に対するエラーを送る
ERROR[CRLF]
<ErrorMessage>[CRLF]
3.2
post-it
post-it は表 3 の通信手順で行なわれる．
KMSN から KMSB へ CO-SGML を内包した
HO-SGML ファイルが投稿される．KMSB は
それを解析，必要な CO データファイルの送
信要求を KMSN へ送る．KMSN は CO デー
タファイルを KMSB に投稿する．
手順
1
2
3
4
表 3: post-it
通信方向
メッセージ
KMSN → KMSB POST HO-SGMLFile
KMSN ← KMSB FETCH CO-DataFile
KMSN → KMSB POST CO-DataFile
手順 2∼3 の繰り返し
3.3
fetch-it
3.7
fetch-it は表 4 の通信手順で行なわれる．
KMSN から KMSB へオブジェクトの送信要
求が送られる．KMSB はそのオブジェクトの
SGML ファイルを KMSN へ送信する．KMSN
はそれを解析し，必要な CO データファイル
の送信要求を KMSB へ送る．KMSB は CO
データファイルを KMSN へ送信する．
表:4 fetch-it
通信方向
メッセージ
KMSN → KMSB FETCH ObjectName
KMSN ← KMSB REPLY Object
KMSN → KMSB FETCH CO-DataFile
KMSN ← KMSB REPLY CO-DataFile
手順 3∼4 の繰り返し
手順
1
2
3
4
5
3.4
list-it
は 表 5 の通信 手順 で行な われ る．
KMSN から KMSB へ，指定 Object Storage，
指定デ ィレクト リ中にあるオブジェクト リス
ト情報の送信要求が送られる．KMSB はリス
ト情報を KMSN へ送信する．
list-it
手順
1
2
3.5
表 5: list-it
通信方向
メッセージ
KMSN → KMSB LIST Storage/Dir
KMSN ← KMSB REPLY ListingInfo
info-it
は表 6 の通信手順で行なわれる．
KMSN から KMSB へ，指定オブジェクトに関
する属性情報の送信要求が送られる．KMSB
は属性情報を KMSN へ送信する．
info-it
手順
1
2
3.6
表 6: info-it
通信方向
メッセージ
KMSN → KMSB INFO ObjectName
KMSN ← KMSB REPLY ObjectInfo
単一コネクションによる転送の効率化
TCP/IP を利用する HTTP は，各ファイル
転送にそれぞれコネクションを確立する．
個のファイルからなる WWW ページをダウン
ロード するには， 個のコネクションを張る
必要がある．この方式は，通信の単純化とい
う利点はあるものの，TCP の Slow Start，ま
た全通信量における各プロトコルヘッダの割
合の増加によるオーバーヘッド などによって，
ネットワーク資源，サーバ資源の浪費を招き，
転送速度低下などの問題を引き起こしている
[7, 8]．HOTp ではこの問題を考慮し，単一の
コネクションで複数のファイルを転送し，転
送終了後も一定時間はコネクションを維持す
る方式を採用している．通信が多少複雑にな
る点もあるが，無線 LAN など帯域の狭いネッ
トワークでの利用も想定される KMSF 環境に
おいては，望ましい通信方式と考えられる．
N
N
4
KMSB for KMSF-CODE
KMSB for KMSF-CODE は ，KMSFCODE アーキテクチャ上で，オブジェクトを
保存，管理し，KMSN に提供するサーバプロ
グラムである．
4.1
KMSB の構造
KMSB は，Connection Manager，Sesssion
Manager，Object Storage の 3 サブシステム
からなる構造である．
Connection Manager は KMSB 起動時より
KMSN からの接続要求を待つマスターサーバ
である．Session Manager は，起動時又は Connection Manager が KMSN からの接続を受理
した時に生成され，KMSN との通信を処理す
る．Object Storage は，各オブジェクトを保
存する空間である．
WWW・HTTP との互換性
知的協調作業を支援する環境としての
KMSF-CODE にとって，既存の World Wide
Web(以下 WWW) との透過性は重要である．
HOTp は，\POST"，\FETCH" などを使用
する「 メソッド 方式」を採用することにより，
WWW の通信プロトコルである Hyper Text
Transfer Protocol (HTTP)[6] との互換性を高
めている．
表 7: HTTP と HOTp の通信方式の比較
Protocol
通信例
HTTP
GET /index.html
HOTp
FETCH /date/19960927181114.
SampeGifPicture.mco/
Connection
Manager
HO
Storage
Media-CO
Storage
Component-CO
Storage
Object Storage
Session Manager
.......
KMSB
WAN/LAN/WirelessLAN
KMSN
.......
KMSN
図 2: KMSB の構成
KMSN
4.2
KMSB の機能
KMSB の機能は，以下の 2 つである．
KMSN との通信処理機能
オブジェクトの保存/管理機能
4.2.1
KMSN との通信処理機能
Session Manager は，実際の KMSN-KMSB
の通信を処理する．
KMSF-CODE アーキテクチャにおいては，
すべてのオブジェクトは SGML ファイルとし
て構造化される [4]．SGML ファイルには，オ
ブジェクトのタイトル，識別子，参照 URL，著
作権表示，コメント，Component-CO のパラ
メータ/ イベント処理情報などがタグとして記
述される．各 HO は単一の SGML ファイルか
ら構成され，各 Media-CO，Component-CO
は SGML ファイルと，テキスト・音声・画像な
どのデータファイルもしくはソフトウェア部
品である Java クラスファイルから構成される．
従って，Session Manager が KMSN-KMSB 間
の通信で扱うのは SGML ファイルもしくは CO
データファイルである．
表 8:
HO-SGML の記述構造
HO-SGML 全体
HO タイトル
<HO>
<TITLE>
<AUTHOR>
<COPYRIGHT>
<COMMENT>
<MCO>
<CCO>
<REF>
作者
著作権表示
コメント
Media-CO
Component-CO
CO-SGML の URL
表 9:
CO-SGML の共通記述構造
<MCO> Media-CO-SGML 全体
<CCO> Component-CO-SGML 全体
<TITLE> CO タイトル
<TYPE> MIME-Types
<AUTHOR>
<COPYRIGHT>
<COMMENT>
<REF>
表 10:
作者
著作権表示
コメント
データファイル・Java
クラスファイルの URL
Component-CO-SGML 独自の記述構造
<EVENT>
<METHOD>
<MESSAGE>
<MESSAGETO>
イベント処理
<EVENT>タグ
メソッド 名
送信メッセージ
メッセージ送信先
Session Manager は，KMSN から FETCH，
LIST，INFO 各メッセージを受信すると，それ
ぞれ指定されたファイル（ SGML ファイルも
しくは CO データファイル），指定された Object Storage 中のリスト情報，指定されたオブ
ジェクトの属性情報を REPLY メッセージと
して KMSN に送信する．
一方，Session Manager は KMSN から POST
メッセージを受信すると，受信した HO-SGML
ファイルを解析し，CO-SGML ファイルを抽
出する．CO-SGML 中の<REF>タグの値から
KMSN に格納されている CO データファイル
の場所情報を得，KMSN から CO データファ
イルを FETCH する．FETCH した CO デー
タファイル，CO-SGML は<REF>タグの情報が
URL に変換された後，CO-Storage に保存さ
れる．
HO-SGML ファイルは，<CO>タグ中の<REF>
タグに記述されている CO の参照情報が URL
に変換された後，HO-Storage に保存される．
4.2.2
オブ ジェクト の保存/管理機能
HO，Media-CO，Component-CO の各オブ
ジェクト は，HO Storage，Media-CO Storage， Component-CO Storage 内の，MIME
Types[9] 別のデ ィレクトリにそれぞれ保存さ
れる．
オブジェクトは，KMSB 各 Storage 内に作
られる，オブジェクトタイトル及び POST 日
付時刻に基づいたユニークな名前のデ ィレク
トリに保存されるため，KMSB 内でのその一
意性が保証される．KMSB はそのホスト名と
ポート番号によって，ネットワーク内で一意
に識別される．よってオブジェクトは，URL
表記で記述することによりネットワーク内で
一意に識別可能となる．
root
date
(link)
19960812060012.HO-Sample1.ho
19960812060145.Sample1.mco
19960812062039.AIFFPlay.cco
Date Storage
hyperobject
HO Storage
media-co
MCO Storage
component-co
CCO Storage
......
HO-Sample1.ho.19960812060012
HO-Sample1.ho
SampleHyper.ho.19960920122043
SampleHyper.ho
SampleHyper.ho.19960921101054
SampleHyper.ho
audio
aiff
Sample1.mco.19960812060145
Sample1.mco
image
au
aiff1.mco.19960920122043
AiffData.aiff
text
wav
aiff2.mco.19960921101054
aiff
AIFFPlay.cco.19960812062039
image
audio
au
DefaultComponent
text
wav
aiff2.cco.19960921101055
AIFFPlay.cco
AIFFPlay.class
図 3: Object Storage
Component-CO Storage の各 MIME Types
ディレクトリには，\DefaultComponent" ディ
レクトリがあらかじめ作られ，KMSB が標準
とする，MIME Types 別 Media-CO 再生用
Component-CO が置かれる．
オブジェクトは，タイトル順に HO，MediaCO，Component-CO それぞれの Storage に保
存されると同時に，POST された順番に Date
Storage にリンクが張られる．よってこれらの
Storage と list-it を使うことにより，ユーザは
オブジェクトを種類別，MIME Types 別，名
前順，時系列で検索することが可能となる．
実装
5
実装は，IBM 社の ThinkPad 530Cs，Sun
Microsystems 社 の SPARCstation 2，Ultra 1，Ultra 2 上で行ない，RMK95[10] と
4.4BSDLites サーバ [11] 上で C 言語で，Solaris2.5.1+JavaVM 上で Java 言語 [12] で
行なった．RMK95 上のスレッド パッケージ
は cthread パッケージを，Solaris2.5.1 上の
JavaVM は JDK1.0.2 を使用した．具体的に
は以下の 3 種のモデルを実装した．
1. 動的マルチプロセスモデル
(RMK95+4.4BSDLites)
2. 動的マルチスレッド モデル
(RMK95+4.4BSDLites,Solaris2.5.1+JavaVM)
3. 静的マルチスレッド モデル
(RMK95+4.4BSDLites)
5.1
動的マルチプ ロセスモデル
マスタープロセス (Connection Manager) は
accept() システムコールで KMSN からの接
続を受け付ける度に，fork() システムコール
でスレーブプロセス (Session Manager) を生
成する．KMSN との通信はスレーブプロセス
が処理し，マスタープロセスは他の KMSN か
らの接続を待つ．
5.2
動的マルチスレッド モデル
マスタースレッド (Connection Manager) は
accept() システムコールで KMSN からの接
続を受け付ける度に，cthread_fork() 関数で
スレーブスレッド (Session Manager) を生成
する．KMSN との通信はスレーブスレッド が
処理し，マスタースレッド は他の KMSN から
6.1
環境条件
評価は以下の条件で行なった．
1. C 言 語 の 実 装 の 評 価 に は ，IBM 社
の ThinkPad530Cs (intelDX4 75MHz,
20MB) を使用し，RMK95 + 4.4BSDLites サーバ上で行なった．
2. Java 言語の実装の評価には，Sun Microsystems 社 の SPARCstation 2 を使
用し，Solaris2.5.1 + JDK1.0.2 上で行な
った．
3. post-it，fetch-it には 100bytes のファイル
を使用した．
4. 測定は各 1000 回行ない加重平均した．
5. 時間測定には RMK95 の Realtime Clock，
JavaVM の System.currentTimeMillis()
を使用し，1ms 単位まで測定した．
6.2
基本操作 (post-it) の性能評価
図 5 は実装別の post-it の性能を表す．\Slave
Create" はスレーブプ ロセス又はスレーブス
レッド 生成の所要時間，\String" は SGML 解
析などメモリ操作の所要時間を表す．UNIX 動
的マルチプロセスモデルと，Mach 動的マルチ
スレッド モデルを比較すると，ネットワーク，
デ ィスク性能はほとんど変わらないが，メモ
リ操作は約 560%，スレーブ生成は約 1200%の
性能向上を実現している．ただ処理全体にお
けるデ ィスク操作部分の割合が大きく，全体
として高速化は顕著ではない．
ÊòéñæÑåïâÞá
¥Ç¾Ó¾¦
の接続を待つ．
5.3
評価
6
Áæðè
静的マルチスレッド モデル
Ðñïæëä
マスタースレッド (Connection Manager) は
起動時に，あらかじめ設定した数のスレーブス
レッド (Session Manager) を生成する．KMSN
からの接続を受け付けると，マスタースレッド
はすでに生成済みのスレーブスレッドに KMSN
との通信処理を担当させる．
Ëâñôìïè
ÐéÞóâÀïâÞñâ
ÊòéñæÍïìàâðð¥À¦
ÊòéñæÑåïâÞá¥À¦
KMSB
Master
Process
Master
Thread
KMSB
Slave
Thread
KMSN
KMSN
6.3
Connect
Connect
KMSN
KMSN
KMSN
KMSN
KMSN
±
³
µ
®©
®©¯
図 5: 各モデルの post-it 測定結果
Slave
Thread
Connect
¯
Ñæêâ¥êð¦
cthread
_fork()
fork()
Slave
Process
KMSB
Master
Thread
KMSN
KMSN
図 4: モデルによるサーバの処理方式
基本操作 (fetch-it) の性能評価
図 6 は実装 別の fetch-it の性能 を表す．
\Slave Create" はスレーブプロセス又はスレー
ブスレッド生成の所要時間，\String" は SGML
の解析などの メモリ操作の所要時間を表す．
UNIX 動的マルチプロセスモデルと，Mach 動
的マルチスレッド モデルを比較すると，ネット
ワーク，メモリ操作に所要の時間はほとんど変
化がない．一方，スレーブ生成では約 1200%，
ディスク操作では約 310%の高速化がみられる．
post-it と比較して全体の処理時間が短いため，
スレーブ生成部分の高速化が全体性能に大き
く影響し，fetch-it 全体で約 100%の高速化を
実現している．
に基づく設計，実装があげられる．その際，現
在の KMSF-CODE 上での通信プロトコルであ
る HOTp ではその通信方式ゆえに連続メデ ィ
アの取り扱いが難しいため，効率の良い連続
メデ ィアの転送を実現するために新しい通信
機構が必要となる．ネットワークの過負荷を防
ぐための，複数の KMSB の協調による連続メ
ディアデータのリレー送信などが考えられる．
謝辞
ÊòéñæÑåïâÞá
¥Ç¾Ó¾¦
Áæðè
Ðñïæëä
Ëâñôìïè
本プ ロジェクトを遂行するにあたり，協力
していただいた慶應義塾大学環境情報学部 徳
田・村井・楠本研究室の皆様に感謝いたします．
ÐéÞóâÀïâÞñâ
ÊòéñæÍïìàâðð
¥À¦
参考文献
ÊòéñæÑåïâÞá¥À¦
¯
±
Ñæêâ¥êð¦
³
µ
図 6: 各モデルの fetch-it 測定結果
6.4
評価結果の考察
以上の性能評価から考察されることは，ス
レーブ生成におけるスレッド 生成のプロセス
生成に対する高速性である．100Bytes のファ
イルの fetch-it のように所要時間の短い処理ほ
ど，スレッド 生成とプロセス生成のコストの
差が処理全体の所要時間に影響し，高速化が
顕著となる．逆に post-it の性能評価からも分
かる通り，所要時間の長い処理ではスレッド 生
成の高速性はあまり生かされない．post-it に
おいて，投稿された CO ごとにスレーブスレッ
ド を生成し，1 回の通信処理を複数のスレッド
で行なうなどの改良により，一層の高速化を
現在研究中である．
7
まとめ
本稿では KMSF-CODE アーキテクチャに
基づく KMSB の設計およびその機能，KMSB
- KMSN 間の通信機構について解説し，3 種の
モデルで実装，評価，および考察を行なった．
今後の課題としては，まず実時間マイクロ
カーネルアーキテクチャに適したサーバとし
ての再設計・実装があげられる．より高度な
マルチスレッド 構造による通信処理の高速化，
実時間スレッド の使用による連続メデ ィアの
処理などを設計・実装していく予定である．
また，KMSF-CODE アーキテクチャ上で
映像，音声などの連続メデ ィアを扱うための，
連続的な post-it，fetch-it である \continuous
post-it"，\continuous fetch-it" の実時間処理
[1] 徳田，石川，望月，富田，川又，\Keio Media
Space Family プロジェクトにおけるシステム
アーキテクチャ"，情処研報，Vol.95，No.59，
95-OS-69，(1995).
[2] 望月，富田，川又，石川，徳田，\Keio Media
Space Board と Keio Media Space Navigator
上のプロトタイプサーバの実装と評価"，情処
研報，Vol.95，No.59，95-OS-69，(1995).
[3] 望月, 徳田, \MKng プロジェクトにおける自律
分散オブジェクトモデル", 第 53 回情処全大論
文集, 5B-9 (1996).
[4] 中澤，岩本，大越，永田，望月，徳田，\分散協調
オブジェクト環境に基づく Keio Media Space
Family の構築"，コンピュータシステムシンポ
ジウム論文集 (1996).
[5] C. Butts, C. Reilly, M. Speh, and Wang J,
\WWW and the global network academy",
Proceedings of the First International on the
World Wide Web, Paper no 36, CERN,
Geneva, Switzerland, May 25-27 (1994).
[6] I T. Berners-Lee, R. Fielding, H. Nielsen,
\Hypertext Transfer Protocol { HTTP/1.0",
RFC1945, May, (1996).
[7] Jerey C. Mogul. \The Case for PersistentConnection HTTP", Proceedings of the ACM
SIGCOMM Conference, Boston, MA, August, (1995).
[8] Venkata N. Padmanabhan, Jerey C. Mogul.
\Using Predictive Prefetching to Improve
World Wide Web Latency", Computer Communication Review, Volume26, Number3,
July, (1996).
[9] N. Borenstein, N. Freed, \MIME (Multipurpose Internet Mail Extensions)", RFC1341,
June, (1992).
[10] 和田, 河内谷, 緒方, 西尾, 追川, 徳田, \KeioMMP におけるマイクロカーネルアーキテク
チャ", 第 49 回情処全大論文集 (7R-08), (1994).
[11] Johannes Helander, \Unix under Mach
- The LITES Server", Master's thesis at
Helsinki University, (1994).
[12] Sun Microsystems Inc., \The JAVA Language Overview.", Sun Microsystems, Inc.,
(1995).
© Copyright 2024 ExpyDoc
