\documentclass[twocolumn,twoside,9.5pt]{jarticle}
\usepackage[dvipdfmx]{graphicx}
\usepackage{picins}
\usepackage{fancyhdr}
\usepackage{abstract}
\usepackage{here}
\usepackage{url}
\usepackage{float}
\usepackage{listings}
%\pagestyle{fancy}
\lhead{\parpic{\includegraphics[height=1zw,keepaspectratio,bb=0 0 251 246]{pic/emblem-bitmap.pdf}}琉球大学主催 工学部情報工学科 }
\rhead{}
\cfoot{}

\setlength{\topmargin}{-1in \addtolength{\topmargin}{15mm}}
\setlength{\headheight}{0mm}
\setlength{\headsep}{5mm}
\setlength{\oddsidemargin}{-1in \addtolength{\oddsidemargin}{11mm}}
\setlength{\evensidemargin}{-1in \addtolength{\evensidemargin}{21mm}}
\setlength{\textwidth}{181mm}
\setlength{\textheight}{261mm}
\setlength{\footskip}{0mm}

\pagestyle{empty}
\lstset{
  language=C, 
  tabsize=2, 
  frame=single, 
  basicstyle={\ttfamily\footnotesize}, % 
  identifierstyle={\footnotesize}, % 
  commentstyle={\footnotesize\itshape}, % 
  keywordstyle={\footnotesize\bfseries}, % 
  ndkeywordstyle={\footnotesize}, % 
  stringstyle={\footnotesize\ttfamily}, 
  breaklines=true, 
  captionpos=b, 
  columns=[l]{fullflexible}, % 
  xrightmargin=0zw, % 
  xleftmargin=1zw, % 
  aboveskip=1zw, 
  numberstyle={\scriptsize}, % 
  stepnumber=1, 
  numbersep=0.5zw, % 
  lineskip=-0.5ex, 
}


\begin{document}
\title{分散フレームワークChristieを用いたremote editor\\ Remote editor using distributed framework Christie}

\author{165713F 一木貴裕 {}{} 指導教員 : 河野真治}
\date{}
\maketitle
\thispagestyle{fancy} 

\section{複数人によるファイルの同時編集}
ペアプログラミングを行う際に有効的手法の一つとして, 同じファイルを複数人が場所を問わずに同時編集することができるリモートエディタをあげられる.

複数人の編集がリアルタイムに同期されるリモートエディタには, 既存の物としてVisual Studio Code(以下VScode)のremote session がある. 
しかし, 編集のセッションに参加するユーザ全員がVSCodeを使うことになり, またVSCodeの環境を導入する必要がある.

セッションに参加するユーザー全員が各々好きなエディタを使用することができるリモートエディタアプリケーションを作成したい. 
アプリケーションの形に作成することにより, 開発のための環境に手間を使うことなく, ユーザーが慣れ親しんだエディタを利用できるようしたい.

先行研究ではネットワークをリング型で構成しトークンを巡回させていたが, ノードごとの整合性の確立が難しい, ネットワーク全体の障害に対する脆弱性の弱さといった問題点が見られた. 
これらの反省点を踏まえ本研究では スター型ネットワークを用いることで remote editor の障害耐性を高める. 

また新しく, 本研究室で開発している分散フレームワークChristieを使用することにより簡潔な実装と, Christie自体の性能と信頼性の向上も目指す. 

\section{remote editor}
リモートエディタは共通プロトコルが対応するエディタが保持するバッファを開いて編集することができる.
ネットワーク上の一つのバッファが編集されると他のバッファにも変更が反映され, お互いのバッファを編集し合うことができる. 
バッファの変更のやり取りでは, 互いのバッファに起こった変更を一つの命令として他のノードへ送信することで実現する.

\section{コマンドパターンでの実装}
命令はコマンドパターンを用いて実装した.
コマンドパターンとは命令を一つのオブジェクトとして扱うものであり, 命令に必要な情報が含まれたクラスのインスタンスを作成することで命令を作成する.

\begin{itemize}
\item インスタンスを利用して命令を作成するため, 後述のChristieのGearの概念と相性が良い. 
\item 命令に必要な内容をまとめて送信するため, 相違の発生を防ぐことができる. 
\item 命令の管理が行いやすい, 行列に並ばせ命令の順番を管理したり, 命令の際, 実行, 取り消しが容易になる. 
\end{itemize}
と言った利点がある.
クラスのインスタンスを作成し, msgpackパッケージを用いてシリアライズしてから送受信する。

\section{msgpackの対応修正}
msgpackを使用し, コマンドを送信しようとしたところエラーの発生が見られた. 
原因はmsgpackのバージョンの進行によりシリアライズ機能が削除されたことによることが判明した.

そこでjavaのバージョンを11から8へ下げる, シリアライズするクラスに対してフィールドをpublicにするといった処理を行うことで対処した. 
msgpackはバージョンの更新が途絶えているため, 最新のjavaで開発を進めるためにはmsgpackに対応する機能を自身で開発する必要が生じた.

\section{編集位置の相違とその解消}
エディタ間の通信で生じる相違について説明する.
エディタ同士のコマンドの送信はそれぞれが独立して行うため、編集対象の領域にエディタ間で相違が生じる場合がある。
すれ違いが発生したか否かを検知するために、ノード同士が送信し合うコマンドにそれぞれ番号を割り振る方法を考案した.
図\ref{fig:Fix}はコマンド番号を用いてバッファの相違を解決する過程の図である.

コマンドとコマンド番号について以下の特性が存在する.
\begin{itemize}
\item 各ノードは最後に実行した数値を変数(図ではserverがcNum, nodeがnodeCNum) に保持している.
\item いずれかのノードがコマンドを発行したら, そのコマンドのコマンド番号は前に実行したコマンドの番号+1となる. そしてそれは送信されてきたコマンドか自分が発行したコマンドであるかは問わない.
\item 送信されてきたコマンドのコマンド番号が自身が保持しているコマンド番号+1でなければ、自身が先に発進したコマンドとすれ違いが発生していることが判明できる. (保持コマンド番号より同値以下の場合)
\end{itemize}
以上の仕組みで相違の解消を図る.

\begin{figure}[htpb]
 \begin{center}
  \scalebox{0.4}{\includegraphics{fig/FIxCommand.pdf}}
 \end{center}
 \caption{コマンド番号による編集相違の解消}
 \label{fig:Fix}
\end{figure}

\section{スター型ネットワーク}
リモートエディタのセッションに参加するノード(ユーザ)はスター型で接続を行い, リモートエディタの通信部分の障害に対する耐性を保障する.
 スター型とは中心となるノードから放射状に他のノードにそれぞれ一対一の接続を行う接続であり, リング型と比較した際のスター型の利点として, 

\begin{itemize}
\item ノードの中心(サーバー)が正しいファイル状況を保持するため,整合性を保つことが容易である.
\item どこかのノードの接続が切断されても, 障害の範囲をそのノードのみに抑えることができる.
\item 新しいノードが参加した, もしくはノードの再接続の際にはサーバーのファイル状況を参照するのみで参加, 復帰ができる.
\end{itemize}
が挙げられる.

\section{分散フレームワークChristie}
ChristieはJava言語で構成された本研究室独自の分散フレームワークである. 
同じく本研究室で開発を行っているGearsOSのファイルシステムに組み込む予定があるため, GearsOSを構成している本研究室の独自の言語Continuation based C (以下CbC言語)とにた, Gearというプログラム概念が存在する.

\begin{itemize}
\item CodeGear(以下 CG)
\item DataGear(以下 DG)
\item CodeGearManager(以下 CGM)
\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 のアノテーションには Take, Peek, TakeFrom, PeekFrom の 4 つがあり, TakeはDGが一度読み込まれると中身が削除されるが, Peekは削除されない.
Fromをつけるとリモート先を指定してDGを得ることができる. 

\section{今後の課題}
本研究ではリモートエディタを制作する上で必要となる構造と, 土台となる分散フレームワークChristieについて述べた. 

現時点ではリモートエディタのコマンドを送り合う上での基盤となるコマンドパターンでの送受信を実装し, 命令コマンドのやり取りにて問題となってくる編集の相違の発生をテスト作成することまでができた.
リモートエディタを動かすまでの最低限の構造制作までは終わっていない. 
現時点から最低限のセッションができるようになるためには, 複数人が参加できるStar型Topologyを構成すると編集ファイルの共有方法を作成しなければならない. 
加えて, 本研究の制作物が実用的になるには既存のエディタを動作できるようになることは絶対条件である.
これらを踏まえて, 今後も制作を続け, 本研究で述べた構成が実際に実用性に応えられるか, ユーザに苦痛なく使ってもらえる処理速度を得られるか検証していきたい.

\nocite{*}
\bibliographystyle{junsrt}
\bibliography{reference}
\end{document}