Mercurial > hg > Papers > 2020 > itsuki-thesis

changeset 11:b8149a449b7d

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
forget .DS_Store & add thankc & others
author ichikitakahiro <e165713@ie.u-ryukyu.ac.jp>
date Fri, 14 Feb 2020 20:11:28 +0900
parents 5ddb3e41e515
children 4c36edd103dc
files final_main/bibliography.tex final_main/chapter1/chapter1.tex final_main/chapter2/.DS_Store final_main/chapter2/chapter2.log 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_main/src/.DS_Store final_main/src/HelloWorld/.DS_Store final_main/thanks.tex final_pre/images/.DS_Store
diffstat 13 files changed, 129 insertions(+), 95 deletions(-) [+]
line wrap: on
line diff
--- a/final_main/bibliography.tex	Wed Feb 12 19:40:35 2020 +0900
+++ b/final_main/bibliography.tex	Fri Feb 14 20:11:28 2020 +0900
@@ -9,37 +9,25 @@
 %URLを載せる人は参考にした年月日を最後に記入すること。
 
 \bibitem{christie}
+赤堀 貴一. Christieによるブロックチェーンの実装, Merch 2019
+
+\bibitem{christie}
 河野 真治. 分散フレームワークChristieと分散木構造データベースJungle, IPSJ SIG Technical Report, May 2018.
 
 \bibitem{christie}
 照屋のぞみ. 分散フレームワークChristieの設計, Master’s thesis, 琉球大学 大学院理工学研究科, 2018.
 
-\bibitem{bitcoin}
-Bitcoin: A Peer-to-Peer Electronic Cash System \\
-\url{https://bitcoin.org/bitcoin.pdf}\\
-(Accessed: 2019/2/15)
+\bibitem{christie}
+安村恭一. 巡回トークンを用いた複数人テキスト編集とセッション管理, Merch 2004
 
-\bibitem{ethereum}
-Ethereum Homestead Documentation \\
-\url{http://www.ethdocs.org/en/latest/}\\
-(Accessed: 2019/2/17)
+\bibitem{christie}
+Kaito TOKKMORI and Shinji KONO. Implementing continuation based language in llvm and clang. LOLA 2015, July 2015.
 
 
-\bibitem{paxos}
-Paxos made Simple \\
-\url{https://lamport.azurewebsites.net/pubs/paxos-simple.pdf}
-(Accessed: 2019/2/17)
+\bibitem{christie}
+宮城健太. Remote editing protocol の実装, Merch 2008.
 
-\bibitem{torque}
-TORQUE Introduction. \\
-\url{http://docs.adaptivecomputing.com/torque/4-2-8/help.htm#topics/0-intro/introduction.htm\%3FTocPath\%3DWelcome\%7C_____1}\\
-(Accessed: 2019/2/15)
-
-
-\bibitem{qsub-doc}
-qsub document. \\
-\url{http://docs.adaptivecomputing.com/torque/4-0-2/Content/topics/commands/qsub.htm}\\
-(Accessed: 2019/2/15)
-
+\bibitem{command patern}
+結城浩. デザインパターン入門, 2004.
 
 \end{thebibliography}
--- a/final_main/chapter1/chapter1.tex	Wed Feb 12 19:40:35 2020 +0900
+++ b/final_main/chapter1/chapter1.tex	Fri Feb 14 20:11:28 2020 +0900
@@ -14,10 +14,13 @@
 
 そこで,セッションに参加するユーザー全員が各々好きなエディタを使用することができるリモートエディタアプリケーションを開発することにした. 
 開発のための環境に手間を使うことなく, かつユーザーが慣れ親しんだエディタを利用できるようにすることでリモートワークやペアプログラミングの取り組みやすさを高めることを狙う. 
+
 また, 最終的にはVScodeのリモートセッションとの接続も目指す.
 アプリケーションの形に作成することにより, 手軽に同時編集が行えるようにしたい. 
-先行研究 [1] ではネットワークをリング型で構成しトークンを巡回させていたが, ノードごとの整合性の確立が難しい, ネットワーク全体の障害に対する脆弱性の弱さといった問題点が見られた. 
+
+先行研究ではネットワークをリング型で構成しトークンを巡回させていたが, ノードごとの整合性の確立が難しい, ネットワーク全体の障害に対する脆弱性の弱さといった問題点が見られた. 
 これらの反省点を踏まえ本研究では スター型ネットワークを用いることで remote editor の障害耐性を高める. 
+
 また新しく, 本研究室で開発している分散フレームワークChristieを使用することにより簡潔な実装と, Christie自体の性能と信頼性の向上も目指す. 
 
 
Binary file final_main/chapter2/.DS_Store has changed
--- a/final_main/chapter2/chapter2.log	Wed Feb 12 19:40:35 2020 +0900
+++ b/final_main/chapter2/chapter2.log	Fri Feb 14 20:11:28 2020 +0900
@@ -1,59 +0,0 @@
-This is e-pTeX, Version 3.14159265-p3.8.2-190131-2.6 (utf8.euc) (TeX Live 2019) (preloaded format=platex 2019.10.15)  6 FEB 2020 00:25
-entering extended mode
- restricted \write18 enabled.
- file:line:error style messages enabled.
- %&-line parsing enabled.
-**chapter2.tex
-(./chapter2.tex
-pLaTeX2e <2019-10-01> (based on LaTeX2e <2019-10-01> patch level 1)
-(./chapter2.aux)
-\openout1 = `chapter2.aux'.
-
-LaTeX Font Info:    Checking defaults for OML/cmm/m/it on input line 4.
-LaTeX Font Info:    ... okay on input line 4.
-LaTeX Font Info:    Checking defaults for T1/cmr/m/n on input line 4.
-LaTeX Font Info:    ... okay on input line 4.
-LaTeX Font Info:    Checking defaults for OT1/cmr/m/n on input line 4.
-LaTeX Font Info:    ... okay on input line 4.
-LaTeX Font Info:    Checking defaults for OMS/cmsy/m/n on input line 4.
-LaTeX Font Info:    ... okay on input line 4.
-LaTeX Font Info:    Checking defaults for OMX/cmex/m/n on input line 4.
-LaTeX Font Info:    ... okay on input line 4.
-LaTeX Font Info:    Checking defaults for U/cmr/m/n on input line 4.
-LaTeX Font Info:    ... okay on input line 4.
-LaTeX Font Info:    Checking defaults for JY1/mc/m/n on input line 4.
-LaTeX Font Info:    ... okay on input line 4.
-LaTeX Font Info:    Checking defaults for JT1/mc/m/n on input line 4.
-LaTeX Font Info:    ... okay on input line 4.
-
-
-./chapter2.tex:4: LaTeX Error: The font size command \normalsize is not defined
-:
-               there is probably something wrong with the class file.
-
-See the LaTeX manual or LaTeX Companion for explanation.
-Type  H <return>  for immediate help.
- ...                                              
-                                                  
-l.4 \begin{document}
-                    
-? 
-./chapter2.tex:4: Emergency stop.
- ...                                              
-                                                  
-l.4 \begin{document}
-                    
-Your command was ignored.
-Type  I <command> <return>  to replace it with another command,
-or  <return>  to continue without it.
-
- 
-Here is how much of TeX's memory you used:
- 9 strings out of 492763
- 321 string characters out of 6140193
- 63896 words of memory out of 5000000
- 4549 multiletter control sequences out of 15000+600000
- 7511 words of font info for 31 fonts, out of 8000000 for 9000
- 929 hyphenation exceptions out of 8191
- 9i,0n,6p,60b,28s stack positions out of 5000i,500n,10000p,200000b,80000s
-No pages of output.
--- a/final_main/chapter2/chapter2.tex	Wed Feb 12 19:40:35 2020 +0900
+++ b/final_main/chapter2/chapter2.tex	Fri Feb 14 20:11:28 2020 +0900
@@ -9,14 +9,18 @@
 この章ではリモートエディタの実装の上で踏んだプロセスや, 開発の上で問題となる点と解決策について説明する。
 
 \section{document listenerによる編集オフセット番号の読み取り}
-    エディタ同士の基本通信環境の構成のため, Chrisitie と同様のjava 言語で作成したエディタのインスタンスを使い, 異なるマシン同士の同期の実現を目指した. 
+    エディタ同士の基本通信環境の構成のため, Chrisitie と同様にjava 言語で作成したエディタのインスタンスを使い, 異なるマシン同士の同期の実現を目指した. 
 自作エディタは java. swingの機能で構成されており, コードをオフセット番号で取り扱っている. 
 
 追記または削除されたオフセット位置とその内容の取得はDocumentListenrを使用した. 
 DocumentListenerのクラスはswingで実装したエディタ部分の入力と削除を検知し, 動作するメソッドであり, DocumentEvent内に入力されたオフセットとその長さや文字列が入力されるため, それをChrisitie側で検知し処理を行った. 
+
 insertUpdateメソッドではバッファに入力が行われた際に自動的に実行され, removeUpdateメソッドは同様にバッファ内の文字のいずれかが削除が行われた際に実行される. 
 他ノードから送信されてきた命令によるバッファの変更によっても実行され, 意図しないループが発生したため, 受信した命令では実行されないように記述をおこなった. 
+
 コード\ref{code:DocumentListener}はinsertUpdate, removeUpdateの記述部分である. 
+ 
+ \newpage
     
 \lstinputlisting[caption=DocumentListenerのコード部分, label=code:DocumentListener]{./src/DocumentListener.java}
 
@@ -59,8 +63,9 @@
 \end{itemize}
 
 javaのバージョンを下げたのは応急的な処置となってしまったが, これらの処置により問題なくCommandパターンでの命令実装を行うことができた. 
-javaのバージョンに左右されずリモートエディタを実装するには, シリアライズの機能について他のパッケージを使うか, 自信で作成する必要が生まれた。
+javaのバージョンに左右されずリモートエディタを実装するには, シリアライズの機能について他のパッケージを使うか, 自身で作成する必要が生まれた。
 
+\newpage
 
 \section{編集位置の相違}
 セッション中のエディタ間の通信で生じうる, 編集結果の相違について説明する. 
@@ -69,8 +74,9 @@
  例としてエディタが一対一の接続となっている時に発生しうる相違を図\ref{fig:difference} を使用して解説する.
  編集対象は各オフセット番号に同じ値の数字が入っているものとする. 
  EditorA ではオフセット番号 3 の 3 という 要素を削除 (テキストエディタ上のため削除されたオフセットにはその後ろの要素が繰り上げられる.), EditorB では オフセット番号 2 に A という要素を挿入するという編集をしたとする. 
+ 
  この編集を共通プロトコルとして互いに送信しあった際, 本来編集する予定だったオフセットの中身が異なってしまい編集結果に違いが生じてしまう. 
- これらの問題を解決することのできるエディタ同士の通信手法を作成しなければならない。
+ これらの問題を解決することのできるエディタ同士の通信手法を作成しなければならない.
 
 \begin{figure}[H]
 \centering
@@ -92,6 +98,77 @@
 
 が挙げられる. 
 
+そこで, すれ違いが発生したか否かを検知するために、ノード同士が送信し合うコマンドにそれぞれ番号を割り振る方法を考案した.
+図\ref{fig:Fix}を用いて解説する.
+
+以下の図はコマンド番号を実装し, すれ違いを検知する際の動作の想定図である.
+また, 本説明のコマンドは文字列の書き込み命令であり, バッファの指定されたオフセットにinsertされるため, それ以降のオフセット内の文字列は, 一つずつ後方オフセットへ移動する.
+
+命令コマンドはクラスのインスタンスを用いて作られており, 中には1オフセット分(文字数分)の文字列, 入力するオフセット, コマンド番号, コマンドを発行したノード名が記録されている. 
+
+二つのノードserver とnode は同じファイルのバッファを開いており, そのバッファには何も記述されていないとする.
+また, serverが送信するコマンドは他のノードから送られてきたコマンドであるとする.
+加えて各サーバー, ノードは実行したコマンドをスタック領域に保持しておいている.
+
+コマンドとコマンド番号について以下の特性が存在する.
+\begin{itemize}
+\item 各ノードは最後に実行した数値を変数(図ではserverがcNum, nodeがnodeCNum) に保持している.
+\item いずれかのノードがコマンドを発行したら, そのコマンドのコマンド番号は前に実行したコマンドの番号+1となる. そしてそれは送信されてきたコマンドか自分が発行したコマンドであるかは問わない.
+\item 送信されてきたコマンドのコマンド番号が自身が保持しているコマンド番号+1でなければ、自身が先に発進したコマンドとすれ違いが発生していることが判明できる. (保持コマンド番号より同値以下の場合)
+\end{itemize}
+
+\newpage
+
+つまり, 送信されたコマンドNo.102を実行したらそれぞれのノードは実行済みコマンド番号を102へ書き換えなければならない.
+そして続いて自らがバッファに変更を加えたとき, その変更をコマンドNo103として作成し, 送信と実行済みコマンド番号を103に書き換える処理が必要となる.
+
+以上の処理でコマンド送信のすれ違いを検知する.
+
+\begin{figure}[H]
+\centering
+  \fbox{
+   \includegraphics[scale=0.85]{./fig/FixCommand.pdf}
+  }
+\caption{コマンド番号を利用した相違の解消}
+\label{fig:Fix}
+\end{figure}
+
+\newpage
+
+コマンドのすれ違いを検知した際の処理は以下のように行う.
+\begin{itemize}
+\item 前提としてノードよりサーバーの整合性を維持したいため優先度は常にサーバーが高い.例えば同じオフセットにそれぞれのノードが別の文字列に変更した場合, サーバーノード共にサーバー側が発進したコマンドの文字列が書き込まれる.
+\item すれ違いが発生したら, 各ノードはコマンドを記録しているスタックを参照し, 受け取ったコマンドのオフセットのズレを集計しそのコマンドを修正する.
+\end{itemize}
+
+図上ではserverからのinsert B for offset:2 とnodeからのinsert Z for offset:2の命令がすれ違いを起こしている. 
+この場合, serverのバッファ状態が優先されるため, server側がnodeからの命令のoffset位置を調整してやらなければならない. 
+この処理はserverと全ての接続しているノード間で独立して行われる.
+
+コマンドのオフセットの修正は
+\begin{itemize}
+\item 受け取ったコマンドのオフセット ＞ 受信コマンドとすれ違ったコマンドのオフセット のとき, 受診したコマンドのオフセットに+1する. 
+\item 受け取ったコマンドのオフセット ＜ 受信コマンドとすれ違ったコマンドのオフセット のとき, 受診したコマンドのオフセットを変えずにそのまま実行できる. 
+\item 受け取ったコマンドのオフセット = 受信コマンドとすれ違ったコマンドのオフセット のとき, サーバー側の文字列が優先される. 
+\end{itemize}
+と言った方法で行うことができる.
+これを削除, 文字列の置き換えにもそれぞれ対応する方法を作ることによりズレの修正を行う.
+
+しかし, テストコードを書き上げる中でこの方法でも網羅できていない問題点や実装上の問題がみられた.
+\begin{itemize}
+\item 既存のエディタ(emacsやvim)のバッファ処理はオフセット単位で行われていない.
+\item コマンドのput(送信)失敗についての想定ができていない.
+\item 現在のChristieでは リスト型や Stack型がputできない.
+\item コマンドを保持し続けるとメモリ容量に無駄が発生する.
+\end{itemize}
+と言った問題点が露見した. 
+これらの問題についての対応方法を模索する必要がある.
+また実装した際に初めて判明する通信速度や複数の独立した処理による影響も対処しなければならない可能性がある.
+. 
+
+
+
+
 
 
 %%文書終了****************************
--- a/final_main/chapter3/chapter3.tex	Wed Feb 12 19:40:35 2020 +0900
+++ b/final_main/chapter3/chapter3.tex	Fri Feb 14 20:11:28 2020 +0900
@@ -5,7 +5,9 @@
 %%**************************************
 \chapter{スター型接続によるネットワーク通信}
 リモートエディタのセッションに参加するノード(ユーザ)はスター型で接続を行い, リモートエディタの通信部分の障害に対する耐性を保障する.
- スター型とは中心となるノードから放射状に他のノードにそれぞれ一対一の接続を行う接続であり, 図:\ref{fig:star} はスター型接続をグラフ化した物である. 
+
+ スター型とは中心となるノードから放射状に他のノードにそれぞれ一対一の接続を行う接続であり, 図\ref{fig:star} はスター型接続をグラフ化した物である. 
+ 
  図で説明すると, node0がハブノード(サーバーの役割)として他のnode1, 2, 3, 4 と接続する.
  例えばここに新しくnode5が接続に加わると仮定すると, 他のノードと同様にnode0と接続するのみでセッションに参加ができる.. 
 
--- a/final_main/chapter4/chapter4.tex	Wed Feb 12 19:40:35 2020 +0900
+++ b/final_main/chapter4/chapter4.tex	Fri Feb 14 20:11:28 2020 +0900
@@ -19,9 +19,10 @@
 \item DataGearManager(以下 DGM)
 \end{itemize}
 
-CodeGearはクラスやスレッドに相当しする. DataGear は変数データに相当し, javaのアノテーション機能を用いて記述する. 
+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 として保管される. 
@@ -37,21 +38,28 @@
 
 \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 するコードである. 
 当然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し続ける無限ループが起こってしまう. 
 
+\newpage
+
 \lstinputlisting[caption=StartHelloWorld,label=code:nStartHelloWorld]{./src/HelloWorld/StartHelloWorld.java}
 
 \lstinputlisting[caption=HelloWorldCodeGear,label=code:HelloWorldCodeGear]{./src/HelloWorld/HelloWorldCodeGear.java}
 
+\newpage
+
 CGM は起動し続けていると処理が自動的に終了しないという問題点がある. 
 そこで役目がなくなったCGM を終了させるための処理を行わなければならない.
+
  CGMを終了させるためのプログラムはソースコード\ref{code:FinishHelloWorld} であり, 二つのkeyが揃ったらcgm.getLocalDGM().finish() の処理でcgmを終了させるよう記述されている.
 
 \lstinputlisting[caption=FinishHelloWorld, label=code:FinishHelloWorld]{./src/FinishHelloWorld.java}
@@ -62,10 +70,14 @@
 
 \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 が実行され, ノード数が合わないとエラーが表示
-される. 
+静的Topologyはソースコード:  \ref{code:dotFile} のようなdotファイルを与えることでノードの接続を図 \ref{fig:dot} のように接続することができる. 例えばnode0 からはnode1 はright という名前で参照することができ, それぞれのノードが同じCG を実行してもlabel の与え方次第で想定したDG の差し合いを実現することができる. 
+
+静的Topologyはdotファイルのノード数と同等のTopologyNodeがあって初めて, CodeGear が実行され, ノード数が合わないとエラーが表示される. 
+
+\newpage
 
 \lstinputlisting[caption=ringを構成するdotファイル, label=code:dotFile]{./src/ring.dot}
 
@@ -86,15 +98,20 @@
 \item Topologyの要素に構成されたノードはそれぞれ親, 子のノードを特定の名前(parent, child[n])で参照できる.
 \item 途中参加したノードは, 木の末端要素として接続する.
 \end{enumerate}
-以上の形でTopologyが形成される. \\
+以上の形でTopologyが形成される. 
+
+\newpage
+
 コード:\ref{code:SRTE} はTopologyManagerを使用してTopologyを構成するコードである. 
 String型のリスト(今回はmanagerArg)に構成したいTopologyの形状をdotファイル, もしくは実装済みの動的Topologyの構成型を設定し, TopologyManagerCondfigを起動することでTopologyManagerが起動できる. 
+
 ソースコードではTreeを構成しており, for文でnodeNum 個分のノードを生成し, それぞれmanagerPortを記憶させている. 
 これによりノードすべてがTopologyManagerによりTreeの構成要素として接続される.
 
+現状では通信アルゴリズムの構成のため, dotファイルにより接続を行なっているが, 最終的にはStar型の動的Topology機能を作成し, 途中で参加してきたノードを接続が行えるようにする必要がある.
+
 \lstinputlisting[caption=TopologyManagerによるTree型Topologyを構成するコード, label=code:SRTE]{./src/StartPrefixTree.java}
 
-現状では通信アルゴリズムの構成のため, dotファイルにより接続を行なっているが, 最終的にはStar型の動的Topology機能を作成し, 途中で参加してきたノードを接続が行えるようにする必要がある.
 
 
 
--- a/final_main/chapter5/chapter5.tex	Wed Feb 12 19:40:35 2020 +0900
+++ b/final_main/chapter5/chapter5.tex	Fri Feb 14 20:11:28 2020 +0900
@@ -9,6 +9,7 @@
 \section{既存エディターに対する編集方法}
 ユーザーが自身の好みなエディタを選択し、リモートセッションが行えるためには各種類のエディタのプロトコルをリモートエディタに対応させなければならない. 
 まずはemacs 続いてはvimの実装を予定している. 
+
 ただし, emacsやvimはバッファの構成がjavaによる自作エディタとは異なり, オフセットによる管理を行なっていないため, 対応させる方法を模索する必要がある.  
 加えて, emacsにリモートエディタを対応させる際にはemacs-lispを用いる必要があることが予測される. 
 java言語で構成されたChristieからemacsの操作をするまでの処置の方法も模索しなければならない. 
@@ -16,19 +17,24 @@
 
 \section{編集するファイルの共有方法}
 現段階では編集位置とその文字列, もしくは削除されたかどうかという情報の送り合いしか実装しておらず, 編集対象のファイルの共有が行えていない. 
+
 ファイルの共有方法としてファイルの中身をそのまま送信すると言った方法が考えられるが, ファイル要領や通信への負担といった要因を考えると最適な手段とは言えない.
 そのためユーザが編集するファイルの一部部分のみ送信するといった方法を考案する必要がある.
 
+\newpage
 
 \section{動的なStar型Topologyの構成機能}
 現開発段階では, 編集位置の相違の解消方法の設計のため, Star型の接続をdotファイルを用いて静的に行っている.
  先述したが静的Topologyの構成では参加ノードの数が想定と一致しなければ動作しないという問題点がある.
+
  作成するリモートエディタは不特定数のユーザの参加を前提としているため, 動的にStar型のTopologyを構成する機能を作成する. 
+
  また, リモートエディタのセッションでは,セッション開始者とは別にサーバーを立て, そのサーバーに開始者を含めた他のユーザを接続する予定である.
 
 \section{複数のマシンがセッションに参加した際の動作}
 現在は一つのマシン上にポートを複数立て, 実際の動作を確認している. 
 これを実際に複数のマシンからセッションを参加した際の通信上でどのような問題や利便性の低下が起きるかが確認できていない.
+
  また, セッション参加者にも上限が存在することが予測される.  
 
 %%文書終了****************************
Binary file final_main/main.pdf has changed
Binary file final_main/src/.DS_Store has changed
Binary file final_main/src/HelloWorld/.DS_Store has changed
--- a/final_main/thanks.tex	Wed Feb 12 19:40:35 2020 +0900
+++ b/final_main/thanks.tex	Fri Feb 14 20:11:28 2020 +0900
@@ -13,9 +13,9 @@
 %順番は重要なので気を付けるように．(提出前に周りの人に確認してもらう．)
 
 \hspace{1zw}
-本研究を行うにあたり, 日頃より多くの助言, ご指導いただきました河野真治准教授に心より感謝申し上げます。
-
-また, 本研究で使用するツールを作成いただいた照屋のぞみ先輩, 本実験の測定にあたり, torqueの環境構築に協力してくださった前城健太郎先輩, 並列信頼研究室の全てのメンバーに深く感謝いたします。最後に、物心両面で支えてくれた両親に深く感謝いたします。
+本研究を行う上で, 多くの教鞭と助言を頂きました河野真治准教授, 並びに琉球大学工学部知能情報コース教員, 職員の方々に心より感謝申し上げます.
+また, 研究進行の上で快くお手伝いや助言を行なってくださった並列信頼研配属の全てのメンバー, 忙しい中研究ツールについての伝授を行ってくれた赤堀 貴一先輩, Christieを作成していただいた照屋希先輩に感謝します.
+最後に
 
 %% \begin{flushright}
 %% % 2019年 3月 赤堀貴一
Binary file final_pre/images/.DS_Store has changed