Mercurial > hg > Papers > 2019 > ikki-midterm

changeset 9:10910b380fe4

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
tweak
author ichikitakahiro <e165713@ie.u-ryukyu.ac.jp>
date Mon, 21 Oct 2019 18:03:00 +0900
parents 7edffff4840b
children feb9b9fdebcc
files mid-thesis.pdf mid-thesis.tex
diffstat 2 files changed, 15 insertions(+), 15 deletions(-) [+]
line wrap: on
line diff
Binary file mid-thesis.pdf has changed
--- a/mid-thesis.tex	Mon Oct 21 14:57:12 2019 +0900
+++ b/mid-thesis.tex	Mon Oct 21 18:03:00 2019 +0900
@@ -29,15 +29,15 @@
 \thispagestyle{fancy} 
 
 \section{研究背景}
-近年、情報社会の発展にともないプログラミングを始めとしたIT技術に対する注目が集まっている。特定の場所に赴かずとも仕事を行うことができるリモートワークの増加、互いのいる場所を問わず画面越しに対話が行える遠隔会議、小学校教育の一環にプログラミングを取り組むといった動きがその一例と言える。これらの取り組みをより発展させる方法としてremote editorの開発を考案した。\\
-　開発するremote editorは異なるマシン上のtext editorをを接続し、異なるエディタ間でも通信が行えるよう編集コマンドを統一する共通プロトコルを用いる。接続された一つのマシン上のエディタで編集を行うと、編集位置と内容を逐次 共通の編集コマンドに変換する。変換されたコマンドを接続ネットワークに送信することで遠隔でのテキスト編集を行う。\\
-　このremote editorは先行研究として参考文献\cite{rep}が存在する。先行研究ではネットワークをリング型で構成しトークンを巡回させていたが、芳しい結果が得られなかった。これらの反省点を踏まえ本研究ではスター型ネットワークを用いることでremote editorの高速化を計る。また当研究室で開発している分散フレームワークChristieを用いることにより、エディタ間の通信の構成を行い、Christieの実用性の検討と証明を行う。\\
-　Christieはユーザーが分散プログラムを行う際、並列で動く資源など複雑性を緩和しながらプログラムを書き上げることができる構造となっている。Christieは接続された異なるノード間において互いのキーの差し合いだけで通信を行うことができ、remote editorの通信を手軽に実現することができる。\\
+近年、情報社会の発展にともないプログラミングを始めとしたIT技術に対する注目が集まっている。特定の場所に赴かずとも仕事を行うことができるリモートワークの増加、互いのいる場所を問わず画面越しに対話が行える遠隔会議、小学校教育の一環にプログラミングを取り組むといった動きがその一例と言える。これらの取り組みをより発展させる方法としてremote editorの開発を行うことにした。\\
+　開発するremote editorは異なるマシン上のtext editorを接続し、異なるエディタ間でも通信が行えるよう編集コマンドを統一する共通プロトコルを用いる。接続された一つのマシン上のエディタで編集を行うと、編集位置と内容を逐次、共通の編集コマンドに変換する。変換されたコマンドを接続ネットワークに送信することで遠隔でのテキスト編集を行う。\\
+　このremote editorは先行研究が存在する\cite{rep}。先行研究ではネットワークをリング型で構成しトークンを巡回させていたが、芳しい結果が得られなかった。これらの反省点を踏まえ本研究ではスター型ネットワークを用いることでremote editorの高速化を計る。また新しく、当研究室で開発している分散フレームワークChristieを用いることにより、エディタ間の通信の構成を行い、Christieの実用性の検討と証明を行う。\\
+　Christieはユーザーが分散プログラムを行う際、並列で動く資源などの複雑性を緩和しながらプログラムを書き上げることができる構造となっている。Christieは接続された異なるノード間において互いのキーの差し合いだけで通信を行うことができ、remote editorの通信を手軽に実現することができる。\\
 \section{テキストエディタ}
 リモートエディタは共通プロトコルが対応するエディタが保持するバッファを開いて編集することができる。ネットワーク上の一つのバッファが編集されると他のバッファにも変更が反映され、お互いのバッファを編集し合うことができる。\\
 
 \subsection{共通プロトコルのコマンド}
-共通プロトコルの編集コマンドはinsertとdeleteの二種類しか存在しない。この二種のコマンドを用いエディタ間の協調動作を実現する。
+共通プロトコルの編集コマンドはinsertとdeleteの二種類しか存在しない。この二種のコマンドを用いてエディタ間の協調動作を実現する。
 \begin{itemize}
   \item insert:
   バッファに挿入された内容とオフセット位置をキーとし、他のバッファへ送信し反映させる。
@@ -45,7 +45,7 @@
   バッファで削除されたオフセット位置をキーとし、他のバッファへ送信し反映させる。
 \end{itemize}
 \subsection{編集位置の相違とその解消}
-共通プロトコルとエディタ間で生じる相違の解消について説明する。エディタ同士のコマンドの送信はそれぞれが独立して行うため、編集対象の領域にエディタ間で相違が生じる場合がある。例としてエディタが一対一の接続となっている時の相違を図\ref{fig:diff_off}を使用して解説する。\\
+共通プロトコルとエディタ間で生じる相違の解消について説明する。エディタ同士のコマンドの送信はそれぞれが独立して行うため、編集対象の領域にエディタ間で相違が生じる場合がある。例としてエディタが一対一の接続となっている時に発生しうる相違を図\ref{fig:diff_off}を使用して解説する。\\
 　編集対象は各オフセット番号に同じ値の数字が入っているものとする。EditorAではオフセット番号3の３という要素を削除(テキストエディタ上のため削除されたオフセットにはその後ろの要素が繰り上げられる。)、EditorBではオフセット番号2にAという要素を挿入するという編集をしたとする。この編集を共通プロトコルとして互いに送信しあった際、本来編集する予定だったオフセットの中身が食い違ってしまい最終的に異なった内容となってしまう。これを防ぐためには
 \begin{itemize}
   \item 送信されたコマンドを巡回トークンを用いて一元化する。
@@ -66,7 +66,7 @@
 スター型ネットワークで接続されたリモートエディタにトークンを巡回させコマンドの送信と受信を行う。先行研究のリング型ネットワークと比較したスター型ネットワークの利点として
 \begin{itemize}
   \item リング型ではコマンドの一元化を保持するのが難しいが、スター型ではサーバーが中心となるため一元性の保持が容易である。
-  \item ノードが障害を起こしても影響がそのノードのみに限られる。
+  \item ノードが障害を起こしても影響がそのノードのみに限られる。また、再接続の際はサーバーを参照することで可能となる。
   \item リング型では速度が問題となり遅延が発生していたが、スター型にすることにより改善が期待できる。
 \end{itemize}
 が挙げられる。
@@ -74,18 +74,18 @@
 \section{分散フレームワークChristie}
 ここでは当研究室が開発している分散フレームワークChristieについて説明する。Christieはjava言語で開発されている。また同じく当研究室で開発している言語Continuation based C(以下CbC)で構成されているGearsOSに組み込まれる予定がある。そのため CbCと似たGearというプログラミング概念が存在する。Gearは以下の四種類が存在する。
 \begin{itemize}
-  \item CodeGear (以下CG)
-  \item DataGear (以下DG)
-  \item CodeGearManager (以下CGM)
-  \item DataGearManager (以下DGM)
+  \item CodeGear (CG)
+  \item DataGear (DG)
+  \item CodeGearManager (CGM)
+  \item DataGearManager (DGM)
 \end{itemize}
-CodeGearはクラス、メソッドに相当し、DataGearは変数データに相当する。CodeGearManagerはノードであり、CodeGear, DataGear, CodeGearManagerを管理する。 CodeGearManagerはDataGearを管理するものであり、putという操作により変数データ、つまりDataGearを格納できる。\\
-DataGearManagerにはLocalとRemoteの二種がある。Localであれば、LocalのCodeGearManagerが管理しているDataGearManagerに対し、DataGearを格納していく。Remoteであれば、Remote先のCodeGearManagerにDataGearを格納できる。\\
-　また、DataGearはアノテーションを付けデータの取り出し方を指定する必要がある。アノテーションにはTakeとPeekの二つがあり、Takeは読み込んだDataGearを保持せず消えるが、PeekはDataGearを保持し続ける。また、RemoteTake,RemotePeekというものもあり、リモート先を指定することにより、RemoteDataGearManagerからデータを取ることができる。\\
+CodeGearはクラス、メソッドに相当し、DataGearは変数データに相当する。CodeGearManagerはノードであり、CodeGear, DataGear, CodeGearManagerを管理する。 DataGearManagerはDataGearを管理するものであり、putという操作により変数データ、つまりDataGearを格納できる。\\
+DataGearManagerにはLocalとRemoteの二種がある。Localであれば、LocalのCodeGearManagerが管理しているDataGearManagerに対し、DataGearを格納する。Remoteであれば、Remote先のCodeGearManagerにDataGearを格納する。\\
+　また、DataGearはアノテーションを付けデータの取り出し方を指定する必要がある。アノテーションにはTakeとPeekの二つがあり、Takeは読み込んだDataGearを保持せず消えるが、PeekはDataGearを保持し続ける。また、RemoteTake,RemotePeekというものもあり、リモート先を指定することにより、RemoteのDataGearManagerからデータを取ることができる。\\
 　CodeGearはCodeGearManagerによって実行される。ただし、CodeGear内に記述されたDataGearが全て入力される必要がある。もしDataGearが揃わない場合、CodeGearManagerはDataGearが揃うまで待機状態となる。
 
 \section{今後の作業}
-現時点ではChristieと同じjava言語で作成したエディタをネットワーク接続し、エディタ同士のやりとりの動作を確立している。また、現在はオフセット番号を取得し同期を行なっているが、emacsなどのエディタは行単位で挿入と削除を行なっているため変更する必要がある。
+現時点ではChristieと同じjava言語で作成したエディタを作り、一対一のエディタ同士の通信を確認している。また、現在はオフセット番号を取得し同期を行なっているが、emacsなどのエディタは行単位での挿入と削除を行なっているため、将来的には行単位に統一する必要がある。
 
 \nocite{*}
 \bibliographystyle{junsrt}