1つの設計ドキュメント
1.1システムの概要
私たちは、クォーラムベースのプロトコルを使用して分散ファイルシステムを実装しました。このプロトコルの基本的な考え方は、クライアントがサーバーへのファイルの読み込みや書き込みのいずれかの前に、複数のサーバからの許可を取得する必要があるということです。このシステムを使用して、複数のクライアントがファイルを一緒に共有することができます。システム全体は1つのコーディネータ（またサーバ）、1つの以上のクライアント、およびいくつかの他のノードから構成されています。
私たちのシステムもサポートし、複数の同じファイルを読み込みます。
- 複数の書き込みまたは+読みが同じファイルへの書き込みは許可されていません。
- 要求シーケンスの順序で処理されるに単一のファイルに書き込みます。
クライアントは、ファイルシステムに（更新）ファイルを書き込む、またはファイルを読み込むことができます。ファイルシステムには、対応するファイル名が存在しない場合、クライアントは適切なエラーメッセージが表示されます。
ノードは、ファイルのレプリカが含まれており、クライアントからの要求に耳を傾けます。ノードは、ファイル・システムに参加したい場合は、その連絡先コーディネータは倹約を使用します。コーディネータは、サーバリストに追加されます。 クライアントからの要求を取得するファイルサーバは、操作を実行するためにコーディネーターに連絡します。それは、すべてのサーバーは、ユーザーからの読み出し/書き込み要求を受け取ることができ、彼らはコーディネータに要求を転送します、です。
コーディネーターは/同期読み出し/書き込みされ、サーバーからの要求に耳を傾け、そのファイルが無料であるかどうかの情報を記録することができます。コーディネーターは、定足数を構築し、サーバノードによって要求された操作を完了するための定足数に必要な他のランダムに選ばれたサーバーに接続します。コーディネーターは、すべてのファイルサーバによく知られているであろう。
PA3はクォーラムプロトコルベースの分散ファイルシステムを達成するために必要。システムは、クライアントノードと（またノードコーディネータとして機能する）組成物の複数の複数から構成されています。クライアントは2で動作します。
- 。ファイルシステム内に（更新）ファイルを書き込みます。（それは、<ファイル名、コンテンツ>キーと値のペアからなるものとして理解されるであろう）
- B。ファイルを読みます。ファイルシステムには、対応するファイル名が存在しない場合、クライアントはエラーメッセージをseeappropriateます。
各ファイルは、バージョン番号を持つ、バージョン番号は、ファイルの内容の後に1になります。複数のレプリカ間の同期（ユーザーが読んだときに、常にファイルの内容の最新バージョンを取得することが保証）、クォーラム議定書を達成するための必要性を達成するために。
クライアントは、ファイルシステム操作に任意のノードを接続することができます。ファイル書き込みノード・システムは、コーディネータに接続する必要がある場合、コーディネータは、定足数を含むマシンを決定します。パラメータNR及びNWクォーラム契約は、ユーザーが設定できるようにすることです。
クォーラム原則：
送信済み（ワンレプリカから）に操作されているサブセットは、レプリカの調理レプリカで行われるべきである。事業を読み、書きます。結果として、全体の定員の最新バージョンを選択するために時間を読み取ります。すべてのマシンでクォーラムを書く時間が書き込まれます。
Nレプリカについては、読むの定足数は、NRのレプリカが同意する必要があり、およびクォーラム必要性を書くNWは同意するレプリカ。満足する必要があります。
- NR + NW> N（NRを読み込み料理、読み書きの競合を避け、NWは最新バージョンを読み取ることができない、ちょうど別のしこりを書きます）
- NW> N / 2（NWが十分でないとき、書き込み書き込みの競合を避け、NWは同時に異なるバージョンかもしれ読ま2つの互いに素しこり）
1.2前提
私たちは、このシステムではこれらの仮定をしました。
•想定すべてのファイルは、テキストファイルのみであり、そのエンコーディング形式を無視します。
•あなたが処理するために必要なファイルの数は（<10）小さくなります。
•サーバーは他のサーバーを知っているとコーディネータの情報（IPとポート）。
•ファイルの内容は非常にシンプルになります（例えば、バージョン番号を持つファイル名）。
• コーディネータは、各ファイルのロックを保持します。
• 別のファイルへのアクセスが同時に行われている必要があります。
•システムがCSELabsマシン（別のマシン）、例えば、KH 4-250（csel-kh4250-xx.cselabs.umn.edu）で動作します。
1.3コンポーネントの設計
1.3.1共通部分
共通部分では、ノード（IP、ポート）を記述するために使用されるリサイクル構造体のアドレスを、定義されました。
1.3.2コーディネーター
コーディネーターは、次のデータ構造を維持します。
- int型NR、NW：プロトコルパラメータ記録クォーラム
- ConcurrentHashMapのFSLock：各ファイルの録音ロック状態（自由、読まれて、書き込みあり）
- ConcurrentHashMapのFSVersion：
- ConcurrentHashMapのFSCurrentReadNumber：スレッドの現在の数（ノード）の各ファイルのレコードを読んでいます
- ConcurrentLinkedDeque REQUESTQUEUE：到着コーディネーターのために、異なるノードからの記録要求。Coord_Readにおけるコーディネータ（）とCoord_Write（）REQUESTQUEUEタスクが順次復帰処理されます。
- ArrayListにいるserverList：ノードのすべてのノードの記録
スーパー、入力されたJavaの-cpを開始するには "：は/ usr / local /スリフト/ *" コーディネーターポートNR NW、例えば、「Javaの-cp "：は/ usr / local /スリフト/ *" コーディネーター9090 4 4” 。
コーディネータは、次のメソッドを実装します。
文字列1. Coord_Read（文字列のファイル名は）：読むためにノードAファイルは、ITのときウォンツコーディネーターで読み出し要求でSENDS内のモデルタイプでコーディネーターでウィルによって、この方法で...（書き込まれていない）場合には可能性が最初にすることができます読み取りファイルをチェックし、コーディネーターでNRサーバーとクォーラムを構築することで。コーディネーターで、その後、読み取りファイルにこれらのサーバーのACK ITサーバーでの取り戻すために最新のバージョンで選ぶ。対応するファイルロック状態でFSLockをチェックし、それは忙しい書き込みなど（無限ループの場合ロック解除されるまで）待ちます。そして、読み始め：読むためFSLockマークを、クォーラムを生成FSCurrentReadNumberを追加するために、クォーラム内のすべてのノード上のファイルのバージョン番号を読み込み、ファイルを返すために、各ノード上に存在しない場合（最新の情報を取得します-1 ）、サーバーのRPCコールの最新バージョンでマシン上のファイルの内容を読み取るDirectRead。リリースFSLockとFSCurrentReadNumber（FSCurrentReadNumber == 0セットFSLockの時間が空いている場合）した後、結果を返します。
ブール2. Coord_Write（文字列のファイル名、文字列含むFileContent）：ITは、ファイルの書き込みにノードAウォンツコーディネーターの書き込み要求でSENDS。ウィルによってモデルでチェックファイル内のタイプはまず（書き込まれていないか、読むに書き込むことができ、この方法でコーディネーター）。もしは、によってコーディネーターでNWサーバーとクォーラムを構築することができます。コーディネーターで、その後、これらのサーバーのACKするファイルに更新。書き込みや多忙などで読む（無限ループ待ち場合、対応するファイルにFSLockをチェックし、ステータスをロック）ロック解除されるまで（ダイレクトがヌルであるファイルが存在しないことを示している場合、それは直接ダウンを実行することができます）。、FSLockタグの書き込みにクォーラムを生成し、このクォーラム内のすべてのノード上のファイルのバージョン番号を取得し、（最新バージョン生成されたファイルを書き込むための）最新の情報を取得します、定員会内のすべてのノード：次に書き始め書き込みの両方で、バージョン番号を更新します。リリースFSLock後、成功に戻ります。
3.ボイド同期（）：定足数プロトコルでは、レプリカが同期から抜け出すことができます。それは読者が常にレプリカのいずれかから最新のファイル（すなわち、最新のバージョン）を取得することが保証されて、ですが、その保証はありませんアップデートの歴史は、すべてのレプリカで保存されますが。（其实感觉没有同期这一步、クォーラム也能一直正常运行下去.sync（）只是为了实现結果整合性、以及TA吃饱撑的HHHHH）この問題を解決するには、同期操作を実装した日付までのすべてのレプリカをもたらしますがお互いにバックグラウンドで定期的に呼び出すことができます。この操作は、（最終的に行われる最終的な一貫性）。これは、バックグラウンド同期機能。これは、最新バージョンにすべてのファイルを5秒ごとに更新されます。サーバーで[すべての最新のバージョンで取得し、それを配布します。すべてのサーバーノードに予定して同期機能では、加工時にファイルをされていない 別のスレッド、同期5秒に1回で同期します。FSLockマークは、書き込みに（この時間は、それは問題を中断するためのすべての読み取り/書き込み操作です）、すべてのノードをスキャン：すべてのファイルは、ファイルのステータスは無料ですFSLockあれば、それは同期し始めた、ファイルシステムをスキャン同期矛盾があるかどうかを確認（およびファイルのバージョン番号とコンテンツの最新バージョンを注意してください）するファイルのバージョン、すべてのノード上のファイルを更新することがある場合。リリースFSLock =自由後、シンク下の睡眠は5秒待ちます。
4.のConcurrentHashMap <文字列、整数> Coord_lsDir（）：この機能は、システム内のすべてのファイルとそのバージョン番号を返します。
5.ブールは、（アドレスサーバー）に参加：サーバ・ノードは、ファイル・システムに参加するコーディネーターを通知するために、この関数を呼び出します。
6.ブールリセット（NR、INT NWをINT）：関数は、NR及びNWの値をリセットするために使用されます。
ビジーウェイトが良好でないと実際には、...それはqwqを不利にされます
1.3.3クライアント
クライアントは、ユーザーインターフェースです。これは、任意のノードに接続します。
それを開始し、入力「のjava -cp "するには：は/ usr / local /スリフト/ *" クライアント<nodeIP> <nodePort>」、例えば、「Javaの-cp "：は/ usr / local /スリフト/ *" クライアントcuda02 7625” 。
クライアントは、次の操作を処理できます。
<のsetdir> local_dirname：ローカルの作業ディレクトリを設定します。
<GETDIR>：ローカルの作業ディレクトリを表示します。デフォルトの作業ディレクトリです./ClientDir/
remote_filenameを<読む>：リモートファイルをお読みください。クライアントは、サーバー上の（）関数を読んで呼び出します。
<書き込み> remote_filenameのlocal_filename：ローカルファイルの内容にリモートファイルを書きます。クライアントは、サーバー上の書き込み（）関数を呼び出します。
<lsremote>：ファイルシステム上のすべてのリモートのファイル（ファイル名とそのバージョン）のリストを表示します。クライアントは、サーバ上でlsDir（）関数を呼び出します。
<lslocal>：作業ディレクトリ内のすべてのローカルファイルのリストを表示します。
<ベンチ書き込み>：ベンチマークを実行します。リモートファイルシステムにローカルの作業ディレクトリ内のすべてのファイルを書き込みます。
<ベンチ読む>：ベンチマークを実行します。リモートファイルシステム内のすべてのファイルを読み込みます。
<ベンチマーク> TWのTR：ベンチマークを実行します：[ベンチ - 書き込み]のTW時間の後、TR回[ベンチを読みます]。
<setcod> NR NW：コーディネーターにNR / NWを設定します。クライアントは、サーバ上でCoord_reset（）関数を呼び出します。
<終了>：終了
1.3.4ノード
ノードConcurrentHashMapのローカルファイルは、ローカルのバージョン番号、およびファイルを保存するローカルの作業フォルダを格納します。どちらも、空から始めます。クライアントがノードに接続された後、クライアントが送信されるすべての読み取りおよび書き込み操作は（本当に怠惰に良い機会を....）完了するために、コーディネーターに転送され、その結果は、クライアントに転送されます。クライアントの機能に加えて、ファイルを読み書きするためのRPCコーディネーター、ローカルクライアントを提供します。
ノードは、ファイルのレプリカが含まれており、クライアントからの要求に耳を傾けます。ノードの作業ディレクトリは./ServerDir_xxxxx（xxxxxは毎回、ノードの起動時に作業ディレクトリは常に空であることを保証する乱数である）です。
ノード、入力の「Java -cp "を開始する：は/ usr / local /スリフト/ *" ノード<coordinatorIP> <coordinatorPort> <nodePort>」、例えば、「Javaの-cp」：は/ usr / local /スリフト/ *」ノードCSEL-kh1250-02 7625” 9090。
ノードには、次のメソッドを実装します。
文字列読む（1：文字列のファイル名）：クライアントがファイルを読むために）（Readを呼び出します。これは、コーディネーターにCoord_read（）を呼び出します。
I32書き込み（1：文字列のファイル名は、2：文字列含むFileContent）：クライアントコールの書き込みは（）ファイルを書き込みます。これは、コーディネーターにCoord_write（）を呼び出します。
ファイルを書き込むためのクライアント呼び出しの書き込み（）：マップの<string、I32> lsDir（）。これは、コーディネーターにCoord_lsDir（）を呼び出します。
バージョンの取得I32（1：文字列filename）： 。コーディネーターコールは、それがこれを返します。ファイルサーバーのこのバージョンにGET ローカル特定のローカルファイルのバージョン。ファイルの戻りが-1直接ローカルファイルを読み取れませ存在しない場合。バージョン番号は、（すべてのノードは、ローカルファイルのバージョン番号を格納するためのConcurrentHashMapを持っています）
文字列DirectRead（1：文字列のファイル名）：コーディネーターがファイルを読むためにDirectRead（）を呼び出します。それは戻りますローカル特定のローカルファイルの内容を。ファイルが存在しない場合は「NULL」を返します。直接读取本地文件
I32のDirectWrite（1：文字列filename、2：文字列含むFileContent、3：I32 FileNewVer）：コーディネーターがファイルを書き込むのDirectWrite（）を呼び出します。これは、上のファイルを書き込みますローカルサーバーを、そしてFileNewVerにそのバージョンを設定します。直接写本地文件
BOOL Coord_reset（1：I32のNR、2：I32 NW）：クライアントは、コーディネーターにパラメータをリセットするCoord_reset（）を呼び出します。それはなりコーディネーターにリセット呼び出します。
2ユーザー文書
コンパイルする方法2.1
私たちは、プロジェクト全体をコンパイルするメイクスクリプトを書かれています。
CDのPA3 / SRC
./make.sh
プロジェクトを実行する方法2.2
1 。ファイル名を指定して実行コーディネーター CD PA3 / SRC / Javaの -cp " ：は/ usr / local /スリフト/ * " コーディネーターポートNR NW <ポート> ：スーパーのポートは 、<NR>：定足数サイズのための読み出し動作 <NW>：定足数サイズについて操作書く のjava：例： -cp " ：は/ usr / local /スリフト/ * "コーディネーター9090 4 4 2 。実行計算ノード 7differentマシン上でスタート計算ノード。 CDのPA2 / SRC / Javaの -cp "。：は/ usr / local /スリフト/ * "ノード<coordinatorIP> <coordinatorPort> <nodePort> <coordinatorIP> ：コーディネーターのIPアドレス <coordinatorPort> ：コーディネーターのポート <NodePort> ：ノードのポート 例：javaの - CP " ：は/ usr / local /スリフト/ * "ノードCSEL-kh1250- 02 9090 7625 3 。実行してクライアント のCD PA2 / SRC / Javaの -cp " ：は/ usr / local /スリフト/ * "クライアント<nodeIP> < nodePort> <nodeIP> ： ノードのIPアドレス<nodePort>：ノードのポート 例：Javaの -cp " ：は/ usr / local /スリフト/ * "クライアントcuda02 7625
クライアント上のサンプルの操作：
実行後どうなるの2.3
その結果、ログ画面上に出力されます（動作復帰は、フラグ、費やした時間、同期条件、ファイルのバージョンを成功します）。あなたは、次のコマンドを入力するように求められます。
3テストドキュメント
3.1テスト環境
マシン：
我々は、一台のコーディネータマシン（チェロ-kh1250-01）6台のサーバマシン（チェロ-kh4250-03、チェロ-kh4250-01、チェロ-kh4250-22、チェロ-kh4250-25、ドリブルを含むテストを実行するために10台のマシンを使用します-kh4250-34）、3台のクライアントマシン（チェロ-kh1250-03）。
テストセット：
私たちは10項目、完全に314のバイトを含むテストセット（./ClientDir）を使用します。データは、NSFを介して共有ディレクトリを使用しています。
ロギング：
Logging (operation return, succeed flag, time spent, synchronization condition, file version) is output on the window.
Testing Settings:
We test:
3 clients
read-heavy/ write-heavy workloads
small/big value of NR/NW
3.2 read/write mixed (300 read, 100 read for each client, 300 write, 100 write for each client)
Unit: ms
1)NR = 4, NW = 4
Client 1, read time: 812, write time: 2007
Client 2, read time: 817 , write time: 1876
Client 3, read time: 809, write time: 1796
2)NR = 1, NW = 7
Client 1, read time: 531, write time: 2970
Client 2, read time: 565, write time: 3276
Client 3, read time: 706 , write time: 3606
3)NR = 7, NW = 7
Client 1, read time: 1081, write time: 2754
Client 2, read time: 774, write time: 2854
Client 3, read time: 644, write time: 2875
4)NR = 7, NW = 4
Client 1, read time: 802, write time: 1822
Client 2, read time: 946, write time: 1820
Client 3, read time: 1031, write time: 2225
When NR=1, the read time is the shortest. When NW=4, the write time is the shortest. NR = 4, NW = 4 reach the shortest total time. Maybe that’s because the size of the quorum is small, less time were spent in distributing updates to quorum and collect the latest version from Quorum. Also, we found that the time spent on single write operation is much longer than a single read operation.
3.3 write heavy (120 read, 40 read for each client, 480 write, 160 write for each client)
1)NR = 4, NW = 4
Client 1, read time: 284, write time: 2693
Client 2, read time: 228, write time: 2693
Client 3, read time: 262, write time: 2629
2)NR = 1, NW = 7
Client 1, read time: 180, write time: 4052
Client 2, read time: 248, write time: 4083
Client 3, read time: 266, write time: 4117
3)NR = 7, NW = 7
Client 1, read time: 310, write time: 4961
Client 2, read time: 453, write time: 4793
Client 3, read time: 374, write time: 4693
4)NR = 7, NW = 4
Client 1, read time: 301, write time: 2539
Client 2, read time: 317, write time: 2601
Client 3, read time: 361, write time: 2585
When NR=1, the read time is the shortest. When NW=4, the write time is the shortest. NR=4/NW=4 and NR=7/NW=4 reaches the best performance. Since this is the write heavy case, so minimal NW could get the best performance.
3.4 read heavy (480 read, 160 read for each client, 120 write, 40 write for each client)
1)NR = 4, NW = 4
Client 1, read time: 1114, write time: 781
Client 2, read time: 893, write time: 751
Client 3, read time: 818, write time: 539
2)NR = 1, NW = 7
Client 1, read time: 880, write time: 1252
Client 2, read time: 690, write time: 1028
Client 3, read time: 584, write time: 982
3)NR = 7, NW = 7
Client 1, read time: 1841, write time: 1646
Client 2, read time: 1740, write time: 1697
Client 3, read time: 1929, write time: 2082
4)NR = 7, NW = 4
Client 1, read time: 1205, write time: 729
Client 2, read time: 1233, write time: 876
Client 3, read time: 1503, write time: 1255
When NR=1, the read time is the shortest. When NW=4, the write time is the shortest. NR=4/NW=4 reaches the best performance. Since this is the read heavy case, so minimal NR could get the best performance.
3.5 Negative cases
We tested the 2 cases:
1. read a remote file, while the file does not exist in remote file system
2. write a local file to remote, while the file does not exist in client
