# HG changeset patch # User ichikitakahiro # Date 1571654320 -32400 # Node ID feb9b9fdebcc0f12ff963d9a8bd98238b9e4dcf4 # Parent 10910b380fe4caaa54f0a4120c8caaf380024be8 tweak diff -r 10910b380fe4 -r feb9b9fdebcc mid-thesis.pdf Binary file mid-thesis.pdf has changed diff -r 10910b380fe4 -r feb9b9fdebcc mid-thesis.tex --- a/mid-thesis.tex Mon Oct 21 18:03:00 2019 +0900 +++ b/mid-thesis.tex Mon Oct 21 19:38:40 2019 +0900 @@ -29,14 +29,16 @@ \thispagestyle{fancy} \section{研究背景} -近年、情報社会の発展にともないプログラミングを始めとしたIT技術に対する注目が集まっている。特定の場所に赴かずとも仕事を行うことができるリモートワークの増加、互いのいる場所を問わず画面越しに対話が行える遠隔会議、小学校教育の一環にプログラミングを取り組むといった動きがその一例と言える。これらの取り組みをより発展させる方法としてremote editorの開発を行うことにした。\\ -　開発するremote editorは異なるマシン上のtext editorを接続し、異なるエディタ間でも通信が行えるよう編集コマンドを統一する共通プロトコルを用いる。接続された一つのマシン上のエディタで編集を行うと、編集位置と内容を逐次、共通の編集コマンドに変換する。変換されたコマンドを接続ネットワークに送信することで遠隔でのテキスト編集を行う。\\ -　このremote editorは先行研究が存在する\cite{rep}。先行研究ではネットワークをリング型で構成しトークンを巡回させていたが、芳しい結果が得られなかった。これらの反省点を踏まえ本研究ではスター型ネットワークを用いることでremote editorの高速化を計る。また新しく、当研究室で開発している分散フレームワークChristieを用いることにより、エディタ間の通信の構成を行い、Christieの実用性の検討と証明を行う。\\ -　Christieはユーザーが分散プログラムを行う際、並列で動く資源などの複雑性を緩和しながらプログラムを書き上げることができる構造となっている。Christieは接続された異なるノード間において互いのキーの差し合いだけで通信を行うことができ、remote editorの通信を手軽に実現することができる。\\ -\section{テキストエディタ} -リモートエディタは共通プロトコルが対応するエディタが保持するバッファを開いて編集することができる。ネットワーク上の一つのバッファが編集されると他のバッファにも変更が反映され、お互いのバッファを編集し合うことができる。\\ +近年、情報社会の発展にともないプログラミングを始めとしたIT技術に対する注目が集まっている。特定の場所に赴かずとも仕事を行うことができるリモートワークの増加、互いのいる場所を問わず画面越しに対話が行える遠隔会議、小学校教育の一環にプログラミングを取り組むといった動きがその一例と言える。これらの取り組みをより発展させる方法としてremote editorの開発を行うことにした。 + +　開発するremote editorは異なるマシン上のtext editorを接続し、異なるエディタ間でも通信が行えるよう編集コマンドを統一する共通プロトコルを用いる。接続された一つのマシン上のエディタで編集を行うと、編集位置と内容を逐次、共通の編集コマンドに変換する。変換されたコマンドを接続ネットワークに送信することで遠隔でのテキスト編集を行う。 -\subsection{共通プロトコルのコマンド} +　このremote editorは先行研究が存在する\cite{rep}。先行研究ではネットワークをリング型で構成しトークンを巡回させていたが、芳しい結果が得られなかった。これらの反省点を踏まえ本研究ではスター型ネットワークを用いることでremote editorの高速化を計る。また新しく、当研究室で開発している分散フレームワークChristieを用いることにより、エディタ間の通信の構成を行い、Christieの実用性の検討を行う。 + +\section{remote editor} +リモートエディタは共通プロトコルが対応するエディタが保持するバッファを開いて編集することができる。ネットワーク上の一つのバッファが編集されると他のバッファにも変更が反映され、お互いのバッファを編集し合うことができる。 + +\section{共通プロトコルのコマンド} 共通プロトコルの編集コマンドはinsertとdeleteの二種類しか存在しない。この二種のコマンドを用いてエディタ間の協調動作を実現する。 \begin{itemize} \item insert: @@ -44,8 +46,10 @@ \item delete: バッファで削除されたオフセット位置をキーとし、他のバッファへ送信し反映させる。 \end{itemize} -\subsection{編集位置の相違とその解消} -共通プロトコルとエディタ間で生じる相違の解消について説明する。エディタ同士のコマンドの送信はそれぞれが独立して行うため、編集対象の領域にエディタ間で相違が生じる場合がある。例としてエディタが一対一の接続となっている時に発生しうる相違を図\ref{fig:diff_off}を使用して解説する。\\ + +\section{編集位置の相違とその解消} +共通プロトコルとエディタ間で生じる相違の解消について説明する。エディタ同士のコマンドの送信はそれぞれが独立して行うため、編集対象の領域にエディタ間で相違が生じる場合がある。例としてエディタが一対一の接続となっている時に発生しうる相違を図\ref{fig:diff_off}を使用して解説する。 + 　編集対象は各オフセット番号に同じ値の数字が入っているものとする。EditorAではオフセット番号3の３という要素を削除(テキストエディタ上のため削除されたオフセットにはその後ろの要素が繰り上げられる。)、EditorBではオフセット番号2にAという要素を挿入するという編集をしたとする。この編集を共通プロトコルとして互いに送信しあった際、本来編集する予定だったオフセットの中身が食い違ってしまい最終的に異なった内容となってしまう。これを防ぐためには \begin{itemize} \item 送信されたコマンドを巡回トークンを用いて一元化する。 @@ -61,9 +65,13 @@ \label{fig:diff_off} \end{figure} -\subsection{スター型ネットワークによる巡回トークン} -スター型で構成されたネットワーク上の巡回トークンについて解説する。スター型とは主要となるサーバーから、接続された他の全てのノードが直接接続される形のネットワークトポロジーである。\\ +\section{スター型ネットワークによる巡回トークン} +スター型で構成されたネットワーク上の巡回トークンについて解説する。 + +スター型とはネットワーク接続形態の一つであり、主要となるサーバー(ハブ)から接続された他の全てのノードが直接接続される形のネットワークトポロジーである。一般的なLANはスター型で接続されており、またハブ同士を接続したりtree型にノードを構成するといった自由性もある。 + スター型ネットワークで接続されたリモートエディタにトークンを巡回させコマンドの送信と受信を行う。先行研究のリング型ネットワークと比較したスター型ネットワークの利点として + \begin{itemize} \item リング型ではコマンドの一元化を保持するのが難しいが、スター型ではサーバーが中心となるため一元性の保持が容易である。 \item ノードが障害を起こしても影響がそのノードのみに限られる。また、再接続の際はサーバーを参照することで可能となる。 @@ -72,20 +80,26 @@ が挙げられる。 \section{分散フレームワークChristie} -ここでは当研究室が開発している分散フレームワークChristieについて説明する。Christieはjava言語で開発されている。また同じく当研究室で開発している言語Continuation based C(以下CbC)で構成されているGearsOSに組み込まれる予定がある。そのため CbCと似たGearというプログラミング概念が存在する。Gearは以下の四種類が存在する。 +ここでは当研究室が開発している分散フレームワークChristieについて説明する。 + +Christieはユーザーが分散プログラムを行う際、並列で動く資源などの複雑性を緩和しながらプログラムを書き上げることができる構造となっている。接続された異なるノード間において互いのキーの差し合いだけで通信を行うことができ、remote editorの通信を手軽に実現することができる。 +また、Christieはjava言語で開発されている。また同じく当研究室で開発している言語Continuation based C(以下CbC)で構成されているGearsOSに組み込まれる予定がある。そのため CbCと似たGearというプログラミング概念が存在する。Gearは以下の四種類が存在する。 \begin{itemize} \item CodeGear (CG) \item DataGear (DG) \item CodeGearManager (CGM) \item DataGearManager (DGM) \end{itemize} -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はクラス、メソッドに相当し、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などのエディタは行単位での挿入と削除を行なっているため、将来的には行単位に統一する必要がある。 +\section{今後の課題} +現時点ではChristieと同じjava言語で作成したエディタを作り、一対一のエディタ同士の通信を確認している。また、現在はオフセット番号を取得し同期を行なっているが、既在のエディタは行単位での挿入と削除を行なっているため、将来的には行単位に統一する必要がある。 \nocite{*} \bibliographystyle{junsrt}