Mercurial > hg > Papers > 2020 > itsuki-thesis
changeset 10:5ddb3e41e515
remove .DS_Store
| author | ichikitakahiro <e165713@ie.u-ryukyu.ac.jp> |
|---|---|
| date | Wed, 12 Feb 2020 19:40:35 +0900 |
| parents | a37b7bd13be9 |
| children | b8149a449b7d |
| files | .DS_Store .hgignore final_main/.DS_Store final_main/chapter1/chapter1.tex final_main/chapter2/chapter2.tex final_main/chapter3/chapter3.tex final_main/chapter4/chapter4.tex final_main/chapter5/chapter5.tex final_main/main.pdf final_pre/.DS_Store |
| diffstat | 10 files changed, 114 insertions(+), 34 deletions(-) [+] |
line wrap: on
line diff
--- a/.hgignore Tue Feb 11 21:59:14 2020 +0900 +++ b/.hgignore Wed Feb 12 19:40:35 2020 +0900 @@ -17,6 +17,7 @@ *.cb *.cb2 .*.lb +.DS_Store ## Intermediate documents: *.dvi @@ -356,7 +357,7 @@ # nuxt.js build output .nuxt -# react / gatsby +# react / gatsby public/ # vuepress build output
--- a/final_main/chapter1/chapter1.tex Tue Feb 11 21:59:14 2020 +0900 +++ b/final_main/chapter1/chapter1.tex Wed Feb 12 19:40:35 2020 +0900 @@ -9,9 +9,16 @@ % 序論の目安としては1枚半ぐらい． -複数人がリアルタイムにファイルの操作を行うことができるリモートエディタには, 既存の物としてVisual Studio Codeのremote session がある. しかし, 編集のセッションに参加するユーザ全員がVSCodeを使うことになり, またVSCodeの環境を導入する必要がある. +複数人がリアルタイムにファイルの操作を行うことができるリモートエディタには, 既存の物としてVisual Studio Code(以下VScode)のremote session がある. +しかし, 編集のセッションに参加するユーザ全員がVSCodeを使うことになり, またVSCodeの環境を導入する必要がある. -そこで,セッションに参加するユーザー全員が各々好きなエディタを使用することができるリモートエディタアプリケーションを買いはすることにした. アプリケーションの形に作成することにより, 手軽に同時編集が行えるようにしたい. 先行研究 [1] ではネットワークをリング型で構成しトー クンを巡回させていたが, ノードごとの整合性の確立が難しい, ネットワーク全体の障害に対する脆弱性の弱さといっ た問題点が見られた. これらの反省点を踏まえ本研究では スター型ネットワークを用いることで remote editor の障害 耐性を高める. また新しく, 本研究室で開発している分散フレームワークChristieを使用することにより簡潔な実装と, Christie自体の性能と信頼性の向上を目指す. +そこで,セッションに参加するユーザー全員が各々好きなエディタを使用することができるリモートエディタアプリケーションを開発することにした. +開発のための環境に手間を使うことなく, かつユーザーが慣れ親しんだエディタを利用できるようにすることでリモートワークやペアプログラミングの取り組みやすさを高めることを狙う. +また, 最終的にはVScodeのリモートセッションとの接続も目指す. +アプリケーションの形に作成することにより, 手軽に同時編集が行えるようにしたい. +先行研究 [1] ではネットワークをリング型で構成しトークンを巡回させていたが, ノードごとの整合性の確立が難しい, ネットワーク全体の障害に対する脆弱性の弱さといった問題点が見られた. +これらの反省点を踏まえ本研究では スター型ネットワークを用いることで remote editor の障害耐性を高める. +また新しく, 本研究室で開発している分散フレームワークChristieを使用することにより簡潔な実装と, Christie自体の性能と信頼性の向上も目指す.
--- a/final_main/chapter2/chapter2.tex Tue Feb 11 21:59:14 2020 +0900 +++ b/final_main/chapter2/chapter2.tex Wed Feb 12 19:40:35 2020 +0900 @@ -4,31 +4,47 @@ \begin{document} %%************************************** \chapter{リモートエディタ} -リモートエディタとは他のマシン上に存在するファイルのバッファを別デバイスから開いて編集, 保存することができる機能である. 加えてこのリモートエディタを複数人が同時に同じファイルを編集し, その上変更がリアルタイムに反映されるように設計する. +リモートエディタとは他のマシン上に存在するファイルのバッファを別デバイスから開いて編集, 保存することができる機能である. +加えてこのリモートエディタを複数人が同時に同じファイルを編集し, その上変更がリアルタイムに反映されるように設計する. この章ではリモートエディタの実装の上で踏んだプロセスや, 開発の上で問題となる点と解決策について説明する。 \section{document listenerによる編集オフセット番号の読み取り} - エディタ同士の基本通信環境の構成のため, Chrisitie と同様のjava 言語で作成したエディタのインスタンスを使い, 異なるマシン同士の同期の実現を目指した. 自作エディタは java. swingの機能で構成されており, 追記または削除されたオフセット位置とその内容の取得はDocumentListenrを使用した. DocumentListenerのクラスはswingで実装したエディタ部分の入力と削除を検知し, 動作するメソッドであり, DocumentEvent内に入力されたオフセットとその長さや文字列が入力されるため, それをChrisitie側で検知し処理を行った. -insertUpdateメソッドではバッファに入力が行われた際に自動的に実行され, removeUpdateメソッドは同様に削除が行われた際に実行される. 他ノードから送信されてきた命令によるバッファの変更によっても実行され, 意図しないループが発生したため, 受信した命令では実行されないように記述をおこなった. + エディタ同士の基本通信環境の構成のため, Chrisitie と同様のjava 言語で作成したエディタのインスタンスを使い, 異なるマシン同士の同期の実現を目指した. +自作エディタは java. swingの機能で構成されており, コードをオフセット番号で取り扱っている. + +追記または削除されたオフセット位置とその内容の取得はDocumentListenrを使用した. +DocumentListenerのクラスはswingで実装したエディタ部分の入力と削除を検知し, 動作するメソッドであり, DocumentEvent内に入力されたオフセットとその長さや文字列が入力されるため, それをChrisitie側で検知し処理を行った. +insertUpdateメソッドではバッファに入力が行われた際に自動的に実行され, removeUpdateメソッドは同様にバッファ内の文字のいずれかが削除が行われた際に実行される. +他ノードから送信されてきた命令によるバッファの変更によっても実行され, 意図しないループが発生したため, 受信した命令では実行されないように記述をおこなった. +コード\ref{code:DocumentListener}はinsertUpdate, removeUpdateの記述部分である. \lstinputlisting[caption=DocumentListenerのコード部分, label=code:DocumentListener]{./src/DocumentListener.java} \section{Command パターンによる命令オブジェクトの作成} -リモートエディタを実装する上において, 各エディタは自身に起きたバッファの変更を対応した他ノードに送信する必要がある. この変更の送り合いをCommand パターンとして実装した. Command パターンとは, 命令を一つのオブジェクトとして表現する方法である. コマンドパターンの利点として, +リモートエディタを実装する上において, 各エディタは自身に起きたバッファの変更を他ノードに送信する必要がある. +この変更の送り合いをCommand パターンとして実装した. +Command パターンとは, 命令を一つのオブジェクトとして表現する方法である. +コマンドパターンの利点として, + \begin{itemize} -\item インスタンスを利用して命令を作成するため, ChristieのGearの概念と相性が良い. +\item インスタンスを利用して命令を作成するため, 後述のChristieのGearの概念と相性が良い. \item 命令に必要な内容をまとめて送信するため, 相違の発生を防ぐことができる. -\item 命令の管理が行いやすい, 行列に並ばせ命令の順番を管理したり, 命令の際実行, 取り消しが容易になる. +\item 命令の管理が行いやすい, 行列に並ばせ命令の順番を管理したり, 命令の際, 実行, 取り消しが容易になる. \end{itemize} -といった点が挙げられる. ソースコード:\ref{code:Command}は書き込み, 送信を行う際の命令をクラスとして作成したものである. このクラスのインスタンスを命令オブジェクトとして送信し合う. + +といった点が挙げられる. +ソースコード:\ref{code:Command}は書き込み, 送信を行う際の命令をクラスとして作成したものである. +このクラスのインスタンスを命令オブジェクトとして送信し合う. \lstinputlisting[caption=Commandパターンとして実装した命令, label=code:Command]{./src/Command.java} \section{命令オブジェクトを実装する際に起きた問題} -インスタンス化した命令を他ノードに送信する際にエラーが発生し, 送信に失敗してしまうという問題が発生した. クラスの送信の際のシリアライズはmsgpackクラスを利用していた. -msgpackクラスは,シリアライズしたいクラスにMessage アノテーションをつけることにより, シリアライズ化を行う. 原因を調査した結果, 以下の原因が見つかった. - +インスタンス化した命令を他ノードに送信する際にエラーが発生し, 送信に失敗してしまうという問題が発生した. +クラスの送信の際のシリアライズはmsgpackクラスを利用している. +msgpackクラスは,シリアライズしたいクラスにMessage アノテーションをつけることにより, シリアライズ化を行う. + 原因を調査した結果, 以下の原因が見つかった. + \begin{itemize} \item Christieのjavaバージョンは11を使用していたが, msgpackバージョン0.6.12はjava11に対して対応していなかった. \item msgpackの最新版0.8.20はシリアライズ機能が含まれなくなった. @@ -42,12 +58,19 @@ \item javassistのバージョンを最新版へ変更した. \end{itemize} -javaのバージョンを下げたのは応急的な処置となってしまったが, これらの処置により問題なくCommandパターンでの命令実装を行うことができた. javaのバージョンに左右されずリモートエディタを実装するには, シリアライズの機能について他のパッケージを使うか, 自信で作成する必要が生まれた。 +javaのバージョンを下げたのは応急的な処置となってしまったが, これらの処置により問題なくCommandパターンでの命令実装を行うことができた. +javaのバージョンに左右されずリモートエディタを実装するには, シリアライズの機能について他のパッケージを使うか, 自信で作成する必要が生まれた。 \section{編集位置の相違} -セッション中のエディタ間の通信で生じうる, 編集結果の相違について説明する. エディタ同士のコマンドの送信はそれぞれが独立して行うため, 編集対象の領域にエディタ間で相違が生じる場合がある. 例としてエディタが一対一の接続となっている時に発生しうる相違を図\ref{fig:difference} を使用して解説する. - 編集対象は各オフセット番号に同じ値の数字が入っているものとする. EditorA ではオフセット番号 3 の 3 という 要素を削除 (テキストエディタ上のため削除されたオフセットにはその後ろの要素が繰り上げられる.), EditorB では オフセット番号 2 に A という要素を挿入するという編集をしたとする. この編集を共通プロトコルとして互いに送信しあった際, 本来編集する予定だったオフセットの中身が異なってしまい編集結果に違いが生じてしまう. これらの問題を解決することのできるエディタ同士の通信手法を作成しなければならない。 +セッション中のエディタ間の通信で生じうる, 編集結果の相違について説明する. +エディタ同士のコマンドの送信はそれぞれが独立して行うため, 編集対象の領域にエディタ間で相違が生じる場合がある. + + 例としてエディタが一対一の接続となっている時に発生しうる相違を図\ref{fig:difference} を使用して解説する. + 編集対象は各オフセット番号に同じ値の数字が入っているものとする. + EditorA ではオフセット番号 3 の 3 という 要素を削除 (テキストエディタ上のため削除されたオフセットにはその後ろの要素が繰り上げられる.), EditorB では オフセット番号 2 に A という要素を挿入するという編集をしたとする. + この編集を共通プロトコルとして互いに送信しあった際, 本来編集する予定だったオフセットの中身が異なってしまい編集結果に違いが生じてしまう. + これらの問題を解決することのできるエディタ同士の通信手法を作成しなければならない。 \begin{figure}[H] \centering @@ -59,11 +82,14 @@ \end{figure} \section{編集位置の相違解消方法} -編集するオフセットに相違が発生する条件として, サーバーとノードがお互いにコマンドを送り合った際, その命令コマンドが相手に到着する前に相手が自身のバッファに変更を加えてしまった場合に起きる. したがって, 相違の解消に必要なことは +編集するオフセットに相違が発生する条件として, サーバーとノードがお互いにコマンドを送り合った際, その命令コマンドが相手に到着する前に相手が自身のバッファに変更を加えてしまった場合に起きる. +したがって, 相違の解消に必要なことは + \begin{itemize} \item サーバーとノード間のコマンド送信のすれ違いが発生したということを検知する方法 \item すれ違いが発生した際に編集したオフセットのズレを修正する方法 \end{itemize} + が挙げられる.
--- a/final_main/chapter3/chapter3.tex Tue Feb 11 21:59:14 2020 +0900 +++ b/final_main/chapter3/chapter3.tex Wed Feb 12 19:40:35 2020 +0900 @@ -4,7 +4,10 @@ \begin{document} %%************************************** \chapter{スター型接続によるネットワーク通信} -リモートエディタのセッションに参加するノード(ユーザ)はスター型で接続を行い, リモートエディタの通信部分の障害に対する耐性を保障する. スター型とは中心となるノードから放射状に他のノードにそれぞれ一対一の接続を行う接続であり, 図:\ref{fig:star} はスター型接続をグラフ化した物である. 図で説明すると, node0がハブノード(サーバーの役割)として他のnode1, 2, 3, 4 と接続する。ここに新しくnode5が接続に加わると仮定すると, 他のノードと同様にnode0と接続する. +リモートエディタのセッションに参加するノード(ユーザ)はスター型で接続を行い, リモートエディタの通信部分の障害に対する耐性を保障する. + スター型とは中心となるノードから放射状に他のノードにそれぞれ一対一の接続を行う接続であり, 図:\ref{fig:star} はスター型接続をグラフ化した物である. + 図で説明すると, node0がハブノード(サーバーの役割)として他のnode1, 2, 3, 4 と接続する. + 例えばここに新しくnode5が接続に加わると仮定すると, 他のノードと同様にnode0と接続するのみでセッションに参加ができる.. \begin{figure}[H] @@ -18,31 +21,42 @@ \section{スター型の利点と比較} -先行研究においてはノードの通信をリング型, つまりノード同士を円となる形で接続することで実装を試みていた. +先行研究においてはノードの通信をリング型, つまりノード同士を円となる形で接続し, そこに巡回トークンを巡らせコマンドを回収することで実装を試みていた. しかし, リング型には以下の欠点が見られた. + \begin{itemize} \item ノードごとのもつファイルの整合性の維持が難しい. \item どこかのノード同士の通信が切断された際の再接続が難しく, また障害が全体に影響してしまう. \item 障害からの復帰が難しい. \end{itemize} -などの問題が見られた. リング型と比較した際のスター型の利点として, + +リング型と比較した際のスター型の利点として, + \begin{itemize} \item ノードの中心(サーバー)が正しいファイル状況を保持するため,整合性を保つことが容易である. \item どこかのノードの接続が切断されても, 障害の範囲をそのノードのみに抑えることができる. \item 新しいノードが参加した, もしくはノードの再接続の際にはサーバーのファイル状況を参照するのみで参加, 復帰ができる. \end{itemize} + と言ったことが挙げられる. -TopologyManagerの接続相手にラベルをつける機能により, サーバーでは各nodeすべてをまとめて一つの名前で処理をすることができる. 反対に各ノードもラベルを利用することで, CG内に大きな工夫をつけることなくサーバーとの通信を行うことができる. \\ + +TopologyManagerの接続相手にラベルをつける機能により, サーバーでは各nodeすべてをまとめて一つの名前で処理をすることができる. +反対に各ノードもラベルを利用することで, CG内に大きな工夫をつけることなくサーバーとの通信を行うことができる. + 懸念点として + \begin{itemize} \item 通信がサーバーのみに集中するため, それを原因に遅延が発生する可能性がある. \item サーバーと他ノードとの一対複数という通信形式から発生する, 予期せぬ編集誤差の危険性. \end{itemize} + と言った点が挙げられる. これらの発生を防ぐため, + \begin{itemize} \item 送信するデータ量や頻度を減らす工夫などを凝らし, 通信の負荷がなるべく少ない設計を構築する. \item サーバーを中心とした整合性維持のための設計をする. \end{itemize} + と言った対策が考えられる.
--- a/final_main/chapter4/chapter4.tex Tue Feb 11 21:59:14 2020 +0900 +++ b/final_main/chapter4/chapter4.tex Wed Feb 12 19:40:35 2020 +0900 @@ -4,11 +4,13 @@ \begin{document} %%************************************** \chapter{分散フレームワークChrisiteについて} -ここでは本研究室で開発している分散フレームワークChrisiteについて解説する. Chrisiteは複雑な分散プログラムを簡潔に書くことのできる構成となっている. +ここでは本研究室で開発している分散フレームワークChrisiteについて解説する. +Chrisiteは複雑な分散プログラムを簡潔に書くことのできる構成となっている. \section{Chrisiteとは} -ChristieはJava言語で構成された本研究室独自の分散フレームワークである。同じく本研究室で開発を行っているGearsOSのファイルシステムに組み込む予定があるため, GearsOSを構成している本研究室の独自の言語Continuation based C (以下CbC言語)とにた, Gearというプログラム概念が存在する. +ChristieはJava言語で構成された本研究室独自の分散フレームワークである. +同じく本研究室で開発を行っているGearsOSのファイルシステムに組み込む予定があるため, GearsOSを構成している本研究室の独自の言語Continuation based C (以下CbC言語)とにた, Gearというプログラム概念が存在する. \begin{itemize} \item CodeGear(以下 CG) @@ -17,8 +19,14 @@ \item DataGearManager(以下 DGM) \end{itemize} -CodeGearはクラスやスレッドに相当しする. DataGear は変数データに相当し, javaのアノテーション機能を用いて記述する. CG内に記述したKeyに全てのDGが揃った際に初めてそのCGが動作するという仕組みになっている. CodeGearManager はいわゆるノードに相当し、CG, DG ,DGM を管理する. DataGearManager は DG を管理するもので, put という操作により DG , 要するに変数データを格納することができる。DGM の put 操作を行う際には Local と Remote と 2 つのどちらかを選び, 変数の key とデータを引数に書く. Local であれば, Local の CGM が管理している DGM に対し, DG を格納していく. Remote であれば接続した Remote 先の CGM の DGM に DG を格納できる. put 操作を行ったあとは, 対象の DGM の中に queue として保管される. \\ -DG を取り出す際には, CG 内で宣言した変数データにアノテーションをつける. DG のアノテーションには Take, Peek, TakeFrom, PeekFrom の 4 つがある. +CodeGearはクラスやスレッドに相当しする. DataGear は変数データに相当し, javaのアノテーション機能を用いて記述する. +CG内に記述したKeyに全てのDGが揃った際に初めてそのCGが動作するという仕組みになっている. CodeGearManager はいわゆるノードに相当し, CG, DG ,DGM を管理する. +DataGearManager は DG を管理するもので, put という操作により DG , つまり変数データを格納することができる. +DGM の put 操作を行う際には Local と Remote と 2 つのどちらかを選び, 変数の key とデータを引数に書く. +Local であれば, Local の CGM が管理している DGM に対し, DG を格納していく. +Remote であれば接続した Remote 先の CGM の DGM に DG を格納できる. put 操作を行ったあとは, 対象の DGM の中に queue として保管される. + +DG を取り出す際には, CG 内で宣言した変数データにアノテーションをつける必要がある. javaのアノテーションとは注釈, 注記を意味し, java.lang.Annotationインターフェースを継承して独自のアノテーションを作成できる. DG のアノテーションには Take, Peek, TakeFrom, PeekFrom の 4 つがある. \begin{description} \item[Take] 先頭のDGを読み込み, そのDGを削除する. DGが複数ある場合, この動作を用いる. @@ -28,12 +36,23 @@ \end{description} \section{プログラムの例} -以下のソースコード\ref{code:nStartHelloWorld} , \ref{code:HelloWorldCodeGear}のプログラムはChrisitieの基本動作となる DGM による put 操作を用いた hello world の出力プログラムである. メソッド sreateCGM でポート番号を指定した上で CGM を作成しする. CGM にCG (クラスファイル)を指定した上でsetupすることでCGMが CGを動作させることができる. HelloWorldCodeGear()とFinishHelloWorld()がここではCGに当たる. HelloWorldCodeGear() クラスには String型の"helloWorld" という key が用意され, "helloWorld"に入力された DG(String型の変数データ) をprint するコードである. "helloWorld" に hello と worldというDGをputすることで出力結果がhello world となる. +以下のソースコード\ref{code:nStartHelloWorld} , \ref{code:HelloWorldCodeGear}のプログラムはChrisitieの基本動作となる DGM による put 操作を用いた hello world の出力プログラムである. +メソッド sreateCGM でポート番号を指定した上で CGM を作成しする. +CGM にCG (クラスファイル)を指定した上でsetupすることでCGMが CGを動作させることができる. HelloWorldCodeGear()とFinishHelloWorld()がここではCGに当たる. +HelloWorldCodeGear() クラスには String型の"helloWorld" という key が用意され, "helloWorld"に入力された DG(String型の変数データ) をprint するコードである. +当然key:helloWorldにはString型しか当てはめられない. +"helloWorld" に hello と worldというDGをputすることで出力結果がhello world となる. またhelloWorldのkeyはアノテーションがTakeである. +従って, 一度目にhelloをputし, hello をprintした後, helloWorldのkeyの中身はなくなるため, 二度目のCG:HelloWorldCodeGearをsetupした際はworldを問題なくkeyにputできる. + +もしhelloWorldのkeyがPeekアノテーションがついていた場合, 一度目のputにて入力されたhelloがkey:helloWorldに残り続けるため, CG:HelloWorldCodeGearをsetupするたびにCGが動作し, 以下のコード\ref{code:HelloWorldCodeGear}ではhelloをprintし続ける無限ループが起こってしまう. + \lstinputlisting[caption=StartHelloWorld,label=code:nStartHelloWorld]{./src/HelloWorld/StartHelloWorld.java} \lstinputlisting[caption=HelloWorldCodeGear,label=code:HelloWorldCodeGear]{./src/HelloWorld/HelloWorldCodeGear.java} -CGM は起動し続けていると処理が自動的に終了しないという問題点がある. そこで役目がなくなったCGM を終了させるための処理を行わなければならない. CGMを終了させるためのプログラムはソースコード\ref{code:FinishHelloWorld} であり, 二つのkeyが揃ったらcgm.getLocalDGM().finish() の処理でcgmを終了させるよう記述されている. +CGM は起動し続けていると処理が自動的に終了しないという問題点がある. +そこで役目がなくなったCGM を終了させるための処理を行わなければならない. + CGMを終了させるためのプログラムはソースコード\ref{code:FinishHelloWorld} であり, 二つのkeyが揃ったらcgm.getLocalDGM().finish() の処理でcgmを終了させるよう記述されている. \lstinputlisting[caption=FinishHelloWorld, label=code:FinishHelloWorld]{./src/FinishHelloWorld.java} @@ -44,7 +63,8 @@ \section{TopologyManager について} ここではChrstie上でノード同士の接続をより簡潔にするために使われるTopologyManagerという機能について説明する. TopologyManagerとはTopologyを形成するために, 参加を表明したノード, TopologyNodeにlabel を与え, 必要があればノード同士の配線も自動で行う機能である. -TopologyManagerのTopologyの形成方法として静的Topologyと動的Topologyの二つの方法がある. 静的Topologyはソースコード: \ref{code:dotFile} のようなdotファイルを与えることでノードの接続を図 \ref{fig:dot} のように接続することができる. 例えばnode0 からはnode1 はright という名前で参照することができ, それぞれのノードが同じCG を実行してもlabel の与え方次第で想定したDG の差し合いを実現することができる. 静的Topologyはdotファイルのノード数と同等のTopologyNodeがあって初めて, CodeGear が実行され, ノード数が合わないとエラーが表示 +TopologyManagerのTopologyの形成方法として静的Topologyと動的Topologyの二つの方法がある. +静的Topologyはソースコード: \ref{code:dotFile} のようなdotファイルを与えることでノードの接続を図 \ref{fig:dot} のように接続することができる. 例えばnode0 からはnode1 はright という名前で参照することができ, それぞれのノードが同じCG を実行してもlabel の与え方次第で想定したDG の差し合いを実現することができる. 静的Topologyはdotファイルのノード数と同等のTopologyNodeがあって初めて, CodeGear が実行され, ノード数が合わないとエラーが表示 される. \lstinputlisting[caption=ringを構成するdotファイル, label=code:dotFile]{./src/ring.dot} @@ -58,7 +78,8 @@ \label{fig:dot} \end{figure} -動的Topologyは参加を表明したノードを順番にTopologyの構成要素として接続していく物である. 現在時点で実装済みのTreeの構成を例とすると +動的Topologyは参加を表明したノードを順番にTopologyの構成要素として接続していく物である. +現在時点で実装済みのTreeの構成を例とすると \begin{enumerate} \item 参加したノードを順にroot(根)に近い要素として接続する. @@ -66,7 +87,10 @@ \item 途中参加したノードは, 木の末端要素として接続する. \end{enumerate} 以上の形でTopologyが形成される. \\ -コード:\ref{code:SRTE} はTopologyManagerを使用してTopologyを構成するコードである. String型のリスト(今回はmanagerArg)に構成したいTopologyの形状をdotファイル, もしくは実装済みの動的Topologyの構成型を設定し, TopologyManagerCondfigを起動することでTopologyManagerが起動できる. ソースコードではTreeを構成しており, for文でnodeNum 個分のノードを生成し, それぞれmanagerPortを記憶させている. これによりノードすべてがTopologyManagerによりTreeの構成要素として接続される. +コード:\ref{code:SRTE} はTopologyManagerを使用してTopologyを構成するコードである. +String型のリスト(今回はmanagerArg)に構成したいTopologyの形状をdotファイル, もしくは実装済みの動的Topologyの構成型を設定し, TopologyManagerCondfigを起動することでTopologyManagerが起動できる. +ソースコードではTreeを構成しており, for文でnodeNum 個分のノードを生成し, それぞれmanagerPortを記憶させている. +これによりノードすべてがTopologyManagerによりTreeの構成要素として接続される. \lstinputlisting[caption=TopologyManagerによるTree型Topologyを構成するコード, label=code:SRTE]{./src/StartPrefixTree.java}
--- a/final_main/chapter5/chapter5.tex Tue Feb 11 21:59:14 2020 +0900 +++ b/final_main/chapter5/chapter5.tex Wed Feb 12 19:40:35 2020 +0900 @@ -7,21 +7,29 @@ ここではリモートエディタの実装において今後開発, 修正しなければならないことについて解説する. \section{既存エディターに対する編集方法} -ユーザーが自身の好みなエディタを選択し、リモートセッションが行えるためには各種類のエディタのプロトコルをリモートエディタに対応させなければならない. まずはemacs 続いてはvimの実装を予定している. ただし, emacsやvimはバッファの構成がjavaによる自作エディタとは異なり, オフセットによる管理を行なっていないため, 対応させる方法を模索する必要がある. 加えて, emacsにリモートエディタを対応させる際にはemacs-lispを用いる必要があることが予測される. java言語で構成されたChristieからemacsの操作をするまでの処置の方法も模索しなければならない. +ユーザーが自身の好みなエディタを選択し、リモートセッションが行えるためには各種類のエディタのプロトコルをリモートエディタに対応させなければならない. +まずはemacs 続いてはvimの実装を予定している. +ただし, emacsやvimはバッファの構成がjavaによる自作エディタとは異なり, オフセットによる管理を行なっていないため, 対応させる方法を模索する必要がある. +加えて, emacsにリモートエディタを対応させる際にはemacs-lispを用いる必要があることが予測される. +java言語で構成されたChristieからemacsの操作をするまでの処置の方法も模索しなければならない. \section{編集するファイルの共有方法} -現段階では編集位置とその文字列, もしくは削除されたかどうかという情報の送り合いしか実装しておらず, 編集対象のファイルの共有が行えていない. ファイルの共有方法としてファイルの中身をそのまま送信すると言った方法が考えられるが, ファイル要領や通信への負担といった要因を考えると最適な手段とは言えない. +現段階では編集位置とその文字列, もしくは削除されたかどうかという情報の送り合いしか実装しておらず, 編集対象のファイルの共有が行えていない. +ファイルの共有方法としてファイルの中身をそのまま送信すると言った方法が考えられるが, ファイル要領や通信への負担といった要因を考えると最適な手段とは言えない. そのためユーザが編集するファイルの一部部分のみ送信するといった方法を考案する必要がある. \section{動的なStar型Topologyの構成機能} 現開発段階では, 編集位置の相違の解消方法の設計のため, Star型の接続をdotファイルを用いて静的に行っている. 先述したが静的Topologyの構成では参加ノードの数が想定と一致しなければ動作しないという問題点がある. - 作成するリモートエディタは不特定数のユーザの参加を前提としているため, 動的にStar型のTopologyを構成する機能を作成する. また, リモートエディタのセッションでは,セッション開始者とは別にサーバーを立て, そのサーバーに開始者を含めた他のユーザを接続する予定である. + 作成するリモートエディタは不特定数のユーザの参加を前提としているため, 動的にStar型のTopologyを構成する機能を作成する. + また, リモートエディタのセッションでは,セッション開始者とは別にサーバーを立て, そのサーバーに開始者を含めた他のユーザを接続する予定である. \section{複数のマシンがセッションに参加した際の動作} -現在は一つのマシン上にポートを複数立て, 実際の動作を確認している. これを実際に複数のマシンからセッションを参加した際の通信上でどのような問題や利便性の低下が起きるかが確認できていない. また, セッション参加者にも上限が存在することが予測される. +現在は一つのマシン上にポートを複数立て, 実際の動作を確認している. +これを実際に複数のマシンからセッションを参加した際の通信上でどのような問題や利便性の低下が起きるかが確認できていない. + また, セッション参加者にも上限が存在することが予測される. %%文書終了**************************** \end{document}