\chapter{分散デバッグ機能と評価}
４章にてJava言語によるLindaサーバーとLinda APIの実装を行った事を報告した。
Java言語による実装を得た事により、Federated Lindaへの機能拡張を比較的容易に行う事が可能となった。

Federated LindaによるCompact Routingの実験においては、ルーティングテーブルの構築を例に、
分散環境でのスケーラビリティをもった実装を確認しようとしたが、現状のLindaの実装では個々のノードが
どのような通信状態をもってスケーラビリティを達成するのか明確に確認することが困難なばかりか、
meshトポロジにおける実験においてはどのような通信状態によってノード全体のスケーラビリティが低下
しているのかを確認するすべが存在しなかった。これを解決する為には、Federated Lindaの通信を阻害せずに
大域的な情報でデバッグが行えるインターフェースが必要である。

よって本章では分散環境におけるデバッグの難しさと分散デバッグに必要な機能について説明し、
そのうちから通信状態のスケーラビリティを確認するという点において、
Federated Lindaでの分散開発環境におけるデバッグ機能の追加を行う。
本論文でFederated Lindaに追加する分散デバッグ機能のアプローチは、
4章で必要性を述べた通信状態のデバッグをJava版Linda サーバーへの拡張を行う事で実現するものである。

%分散アルゴリズムのデバッグの難しさ
%逐次アルゴリズムのデバッグ手法　ーー二分法
%gdbの全ノードへの手法による限界、ログをprintfするのではダメ
%デバッグする対象　デッドロック、ライブロック、スケーラビリティ、通信の集中、大量のパケット（ACK）
%個々の部品が正しく動いていても全体として正しく動かない場合がある。二分法は無力、
%スナップショットがあれば二分法が使える、量はかなり多い、デッドロックの検出も可能、循環した依存性の検出
%分散デバッガでおかしなぶぶんを見つけて、入力タプルと出力タプルを特定
%そうすれば逐次型でデバッグできる
%重要なのはスナップショット、便利
%分散デバッグアルゴリズム自体がスケールしなければいけない、一カ所にデータを集めるのはいけない
%通信の集中は統計で見れる-> 今回はコレ
%ビジュアライゼーション、意味不明なprintfを視覚的に

\section{分散環境におけるデバッグ}
分散環境における分散プログラムのデバッグは逐次型プログラムに比べて困難である。
それは、一般的に用いられるgdbやIDE(統合開発環境)のデバッガが逐次プログラムをデバッグする為に
機能を提供するのに対して、分散プログラムには、一般的なデバッガではデバッグが困難な特徴が
存在する為である。

ここでは一般的なデバッガを用いた二分法によるデバッグ手法と、分散プログラム開発での
シーケンシャルなデバッグ手法では解決困難な問題点について説明する。
\newpage
  \subsection{二分法による逐次アルゴリズムのデバッグ}
一般的なgdbやIDEのデバッガ等を用いた二分法での逐次アルゴリズムのデバッグは、
プログラムの単体試験や結合試験工程では大変有効な手法である。

特にこの手法を用いるのにおいて適している状況は、プログラムにおけるバグの存在が既知であり、
そのバグを生じさせることが確実であるという場合である。以下に二分法の基本的な方法を示す。

\begin{center}
\begin{itembox}[l]{二分法によるデバッグ}
{\small
\begin{center}
\begin{verbatim}
[条件定義]
・バグは既知であり、再現性があること
・バグはプログラムの状態（大域変数と局所変数の値）から判断できること

[二分法]
1. プログラムの初期実行をα = s0とする
2. バグが発生している時点の実行ステートメントを β = sN とする
3. N' = N/2 とし sN'のプログラムの状態にバグがあるかどうかを調べる
4. バグがあるかないかによってα = sN'またはβ = sN'とする

5. 上記を繰り返す事により α +1 = β となる
6. これにより、バグが存在する時点の実行ステートメントとプログラムの状態を得る 
\end{verbatim}
\end{center}
}
\end{itembox}
\end{center}

上記の手法は簡単ながらも非常に強力なデバッグ手法であり、半ば自動化された作業によってバグの特定を
可能とする。
しかし、分散プログラムの開発工程においては、上記の手法では解決困難な状況が存在する。
次は、そのような状況についてFeederated Lindaの通信状態のデバッグを例に説明する。
  \subsection{シーケンシャルなデバッグ手法の問題点}
二分法を用いたシーケンシャルなデバッグ手法を前述したが、分散アルゴリズムの開発においては、
二分法では解決できない状況が存在する。

その状況とは、分散環境の各ノード、つまり全体を構成する個々の部品が正しく動いていても、全体としては
正しく動かないという状況が存在する事を指す。

ここで、Federated Lindaの通信状態を例にシーケンシャルなデバッグ（つまり単体の部品のデバッグ）が
有効な場合と、単体のシーケンシャルなデバッグでは全体の動作の正しさをデバッグできない例をそれぞれ
示す。

\newpage
\subsubsection{単体のデバッグが有効な例}
図ref{seqdeb}に示すのはFederated Lindaにおける通信にて、単体のプロセスに対する逐次デバッグが
有効な場合の通信状態である。
この通信の場合においては１つのInputに対して1つのOutputを持つプロセスのデバッグを行う事で、
全体の動作に関係する通信の流れをとらえることが可能であるからである。
\begin{figure}[htbp]
\begin{center}
\includegraphics[width=8cm]{fig/pdf/seqdeb.pdf}
\caption{単体のデバッグが有効なFederated Lindaの通信}
\label{seqdeb}
\end{center}
\end{figure}

\vspace{-1cm}
\subsubsection{単体のデバッグでは全体の正しさをデバッグできない例}
続いて図\ref{nonseqdeb}に示すのはFederated Lindaにおける通信で、単体のデバッグでは全体の正しさを
デバッグできない例である。なぜ全体の動作に対する正しさをデバッグできないかというと、
図に示すデバッガを接続したプロセスが１つのInputに対して1つのOutputを正しく出力する事がデバッグ
できても、デバッグを行ったプロセスとは関係しない通信の流れが存在する為に、プロセスの全体の通信に対
する依存性をデバッグできない為である。

\begin{figure}[htbp]
\begin{center}
\includegraphics[width=8cm]{fig/pdf/nonseqdeb.pdf}
\caption{単体ではデバッグが困難なFederated Lindaの通信}
\label{nonseqdeb}
\end{center}
\end{figure}

このような個々のプロセスをデバッグしただけでは全体の正しさが分からない場合、gdbやIDEのデバッガとい
った逐次デバッガを全ノードに対して接続することが考えられるが、このような手法は全体を構成するノード
が大規模化した場合においてその手間やリソースの集中におけるスケーラビリティの低下や、一度に大量の
デバッグ情報が取り扱われる為に、その中から求めている情報を取捨選択することの困難さ等が問題となる
ので、全ての分散環境におけるデバッグの手法としては正しくない。

また、デバッガによるプロセスの停止によってネットワークの遅延や送信データの喪失が起これば、
全体の通信の同期に必要とされるデータが揃わないまま同期を取ることになる。
そうなると本当の意味での同期が取られていないということになり、バグ再現の為の条件が一定の通信状態
を要求する場合において問題がある。

\section{分散デバッグ機能の検討}
これまで二分法による逐次アルゴリズムのデバッグと分散環境におけるデバッグの問題点を述べた。
ここでは、Federated Lindaに必要なデバッグ機能を提案するために、分散アルゴリズムにおいてデバッグ
すべき要素を挙げ、それらをデバッグ可能な機能としてスナップショットを用いた分散デバッグを説明する。
%また、Federated Lindaを用いる事でスケーラビリティを持った分散デバッグ機能を実現することについても
%述べる。
  \subsection{分散アルゴリズムにおいてデバッグすべき対象}
%デバッグする対象　デッドロック、ライブロック、スケーラビリティ、通信の集中、大量のパケット（ACK）
分散アルゴリズムにおいてデバッグすべき対象には以下のものがある。
{\large
\begin{center}
\begin{verbatim}
・デッドロック
・ライブロック
・スケーラビリティ
・通信の集中
・大量のパケットの送信
\end{verbatim}
\end{center}
}
   \subsubsection{デッドロック}
   デッドロックとは、あるプロセスが永遠にブロックされている状態を示す。そのプロセスはある条件が
   真になる（例えばある資源がreadできるようになる）のを待っているが、その条件を真にするはずの別の
   プロセスがその条件を執行しないが為に、どちらも何もできなくなるのである。

   Federated Lindaにおけるプロセスの通信は、porlingベースの通信ループを持ち、
   通信のパケットは一旦キューに溜め、ある一定のタイミングでまとめて通信を行うことから明確な「待ち」
   というプロセス状態は発生しないが、ユーザープログラムによる「待ち」処理記述の可能性からデッド
   ロックの検出は必要である。

   \subsubsection{ライブロック}
   ライブロックはデッドロックと異なり、プロセスは実行状態にあるものの、適用されるべきプログラム状態
   の変化が何も成し遂げられない状態を指す。

   例としてFederated Lindaにおけるプロセス間通信で説明すると、あるルーティングテーブルの構築に対
   して２つのプロセスがそれぞれルーティング情報を保持しており、それぞれが相手のプロセスの
   保持するルーティング情報を必要としている場合に、両者が相手のルーティング情報を得る為に自身
   の保持する情報を解放した場合が考えられる。当然ながら、この両方のプロセスは相手の情報を期待して
   いる為に実質的に何も達成できないという状態になる。

   \subsubsection{スケーラビリティ}
   スケーラビリティとは、サービスを受けるユーザー数が小規模から大規模に変化しても同じ様に同等
   の能力を発揮できるという性能基準のことである。

   Federated Lindaにおけるスケーラビリティの確認は、前提としてはノード数の増加に対する
   プログラムの実行速度やサービス提供能力のパフォーマンスを、実際のアプリケーションを用いて
   行う事があるが、現在の様に開発途中の段階では、部分的なプログラムの動作を見てその領域における
   スケーラビリティを検証することが必要である。その点においてデバッグインターフェースによる
   スケーラビリティの測定を可能とする事は重要であると考えられる。

   \subsubsection{通信の集中}
   分散プログラムの開発段階においては、通信の集中によるバグの発生は常に起こりうる事態である。
   事実、Federated LindaによるCompact Routingの実装では、ある１つのノードに対してルーティング情報が
   集中的に転送されるというバグが発生した。しかもそのようなバグは通常の逐次デバッガを用いた
   デバッグ手法では、パケット集中を行っている複数のノードに対して複合的なバグ原因を検証することは
   困難である。やはりこのような事態をデバッグするには従来の逐次デバッグとは異なる、分散デバッグ
   インターフェースをもってデバッグを行う事が必要と考える。

   \subsubsection{大量のパケットの送信}
   前述した通信の集中とは逆に、大量のパケットを単体、または複数のノードに対して通常とは異なる
   量で送信するバグも起こりうる。このような場合、大量のパケットによる多ノードへの通信集中はもち
   ろん、送信したノードからのACKnowledgementが大量にネットワーク内に流れる事による、通信効率の
   低下や輻輳の発生を生み出す可能性がある。この問題をデバッグする為には、
   プログラムが停止してからではデバッグできない事から、
   輻輳を発生させているプロトコルを動的に検知する必要がある。%###シスコのルーターはそうやってる###
   やはり、この場合も通常の逐次デバッガでは検知が困難なことから、分散デバッグインターフェースを
   用いてデバッグを行う事が望ましいと考える。


  \subsection{スナップショットによる分散デバッグ}
%スナップショットがあれば二分法が使える、量はかなり多い、デッドロックの検出も可能、循環した依存性の検出
%分散デバッガでおかしなぶぶんを見つけて、入力タプルと出力タプルを特定
%そうすれば逐次型でデバッグできる
%重要なのはスナップショット、便利
%分散デバッグアルゴリズム自体がスケールしなければいけない、一カ所にデータを集めるのはいけない

現在主に用いられている単体の逐次デバッガは分散環境用に作られていないことから、
分散環境でのデバッグの場合、１プロセスに対してデバッガを動かすか、
複数プロセスに対してそれぞれデバッガを動かしてデバッグを行うかの
どちらかのスタイルがとられると述べたが、これではデバッグすべきプロセスが増えるとその
手間はかなりの物になり、現実的なデバッグ手法とは言えない。

また、分散プログラム環境下ではプログラム状態の非決定性が存在するため通常のデバッグには無い
問題があることも述べた。
シーケンシャルなデバッグ手法では、通信の到着順序によっても分岐が変化してしまうことから、
デバッグ対象のエラーに対して再現性を確保するのが難しいという問題である。
通常、分散環境下でのデバッグではこれらの点をふまえて、

\begin{itemize}
\item {通信におけるプログラムの状態が決定的になるようテストする}
\item {非決定性をシミュレートする}
\item {バリア同期で通信を止めてメモリ等の状態を調べる}
\item {各ノードでスナップショットを取得し、ログを解析する}
\end{itemize}

といった方法がとられる。

今回、Federated Lindaを用いた分散プログラム開発の為のデバッグインターフェースを考えるにあたって、
上記のうちから「各ノードでスナップショットを取得し、ログを解析する」という手法が最も適している
と考える。

その理由は、スナップショットを用いる事で、Federated Lindaにおける各ノードの通信を止める事無く
デバッグに必要なプログラムの状態を確認できるという点と、各ノードの大域的な状態を保存する事で
先に述べた「分散アルゴリズムにおいてデバッグすべき対象」をそれぞれデバッグすることが可能となる
からである。

以下で大域的な状態とはどのような物かを説明し、どのようにスナップショットを用いたデバッグインタ
ーフェースを用いるべきかを説明する。

\subsubsection{大域的なプログラム状態とは}
Federated Lindaにおける大域的なプログラム状態には二つの要素があり、各ノードのメモリ状態
（あるいはそれに類するデータ構造）を持つ事を第一としている。
このメモリ状態を各スナップショットでのタイミングごとに正確に
取得することにより、プログラムの大域変数や局所変数を用いたバグの特定を可能とする。

例えば、
先に述べた様なデッドロックの原因となる排他ロックの要求及び保持を検出する検出器の作成を行い、
スナップショットのログからデッドロックの追跡を行う事。または、二分法を用いてバグの存在するプロ
グラムの実行ステートメントとプログラム状態を取得する事が可能となる。

また、大域的なプログラム状態の要素として第二に、スナップショットを取るタイミングで実行中の
プロセスが発行した通信に対する状態についても取得すべきと考える。スナップショット取得のタイミングで
考えられる通信の状態は４つのパターンに分類され、そのパターンとは、
\\
\begin{itembox}[l]{-}
{\large
\begin{center}
\begin{verbatim}
スナップショット取得のタイミング = T
通信受信先でのスナップショット取得のタイミング = T'
\end{verbatim}
\end{center}
}
\end{itembox}

とすると、
\begin{itembox}[l]{-}
\begin{itemize}
\item {Tの前にパケットを送信し、T'よりも早くパケットを受け取る場合}
\item {Tの前にパケットを送信し、T'よりも遅くパケットを受け取る場合}
\item {Tの後にパケットを送信し、T'よりも早くパケットを受け取る場合}
\item {Tの後にパケットを送信し、T'よりも遅くパケットを受け取る場合}
\end{itemize}
\end{itembox}

という４つのパターンである。

この、スナップショット取得のタイミングに対する通信の状態は、プロセスの再現性や、
プロセスの状態がある時点でどのように保たれているかを検知する上での同期処理に密接に関わってくる。
通信の状態を同期する処理が行えなければ、ネットワークを介し他のノードと通信を行っている分散
プログラムの大域的状態を取得する事は、プログラム状態の決定性に欠けることとなる。
よって、分散環境でのスナップショットを考えるにあたっては、上記４パターン通信状態を
どのように同期するかが重要である。

\subsubsection{スナップショットを用いた分散デバッグ手法}
%スナップショットがあれば二分法が使える、量はかなり多い、デッドロックの検出も可能、循環した依存性の検出
%分散デバッガでおかしなぶぶんを見つけて、入力タプルと出力タプルを特定
%そうすれば逐次型でデバッグできる

ここまで、スナップショットを用いて分散デバッグを行う事と、そのための大域的プログラム状態について
説明した。ここでは、分散環境で取得したスナップショットをどのように用いてデバッグを行うべきかを
検討する。

\subsubsection{スナップショットのモニターツールと逐次デバッガによるデバッグ}
スナップショットを取得した場合、そのスナップショット・ログは膨大である。
よって、実際にスナップショット・ログからデバッグを行う為には様々な切り口で
情報を取捨選択できるモニターツールが必要であると考える。
図\ref{snapdeb}にスナップショットのモニタツールを用いたデバッグの様子を示す。

\begin{figure}[htbp]
\begin{center}
\includegraphics[width=12cm]{fig/pdf/snapdeb.pdf}
\caption{スナップショット・ログを用いたデバッグ}
\label{snapdeb}
\end{center}
\end{figure}

上記の図ではスナップショット・ログより、大域的プログラム状態の項で
説明したプログラムのメモリー状態とスナップショット取得のタイミングにおける通信状態を同期させる
ことによってFederated Lindaの大域的状態を取得している。
また、同期されたスナップショット・ログをモニタツールという、ユーザーが必要なデバッグ情報を取捨
選択するツールを用いる事を考える。ユーザーはモニタツールを用いて（例えば二文法によるバグ箇所の
検知などを利用）、どのプロセスから出力と入力があったタプルにバグの原因があるのかを特定するこ
とができる。そうすれば、その後のバグの修正においては逐次デバッガによるデバッグが可能となる。

\subsection{分散デバッグ機能のスケーラビリティ}
全ノードに対してデバッグプロセスを走らせてデバッグを行うような
手法は、デバッグのインターフェースにおけるスケーラビリティを考慮してはいない。

事実、システム資源の異なるノードに対してネットワークを介したリモートデバッグの手法は
数多く開発されていても、それが大規模システムを想定した分散プログラムに対してスケーラビリティを
保ったままデバッグ可能という解を得てはいない。

Federated Lindaはタプルのリレーという、より分散プログラムを意識したモデルであることから、デバッグ
インターフェースの大域的状態の取得にもスケーラビリティを持った実装を目指す。
その基本的なアイデアは、デバッグ情報を取得するインターフェースに対してもLindaプロトコルによるタプ
ルの伝搬を利用して実装するというものである。

下図\ref{FDLindaDebug}に示すように、Federated Lindaを用いたデバッグインターフェースは、デバッガ
プロセスからあるノードに対してデバッグ情報の取得を指示するオペレーションを発行し、デバッグ情報の
取得を行うデバッグプロトコルとしてタプル間を伝搬させる。
デバッガが受け取る結果はFederared Linda内のスナップショットとしての大域的状態であり、それを元に
デバッグを行う。このような仕組みをとる事で、大規模な分散プログラム環境であってもスケーラビリティ
を保ったままデバッグを行う事が可能となる。

\begin{figure}[htbp]
\begin{center}
\includegraphics[width=14cm]{fig/pdf/FDLindaDebug.pdf}
\caption{スケーラビリティを意識したデバッグインターフェース}
\label{FDLindaDebug}
\end{center}
\end{figure}

%\newpage
\section{通信状態デバッグインターフェースの実装}
ここまで、Federated Lindaを用いた分散環境環境における分散デバッグインターフェースの機能の検討
を行った。その結果、Federated Lindaで用いられるべき分散デバッグインターフェースはスナップショット
を用いて、デッドロック、ライブロック、スケーラビリティ、通信の集中、大量のパケットの送信、といった
要素のデバッグを行う事が必要との結論を得た。

しかし、検討したスナップショットでのデバッグインターフェースの実装の為には、現実装の
Federated Lindaで用いられるProtocol Engineには更なる改良が必要である。なぜならば、現在のProtocol
 Engineはルーティングテーブルを内部データとして保持することから、Federated Lindaの大域的状態を
取得するにはProtocol Engineまでのスナップショットが必要となるからである。
これを解消する為にはProtocol Engineの内部状態をステートレスに実装し、その挙動はやり取りするXML
に全て埋め込むという実装が求められる。

本論文では、前述した分散アルゴリズムにおいてデバッグすべき対象のうちから、
通信の集中を検知するデバッグインターフェースについて実装を行った。
このデバッグインターフェースを用いる事により、３章で提示したCompact Routingを用いるFederated Linda
において、meshトポロジで起こったデバッグ困難な通信の集中を伴う状態の検知を行う事を目標とする。
以下にその詳細を示す。


  \subsection{Java版Linda サーバーへの機能実装}
通信状態デバッグインターフェースとしてJava版のタプルサーバーへの機能拡張を行った。
この実装はFederated Lindaの通信を止めずに、通信のログを取りたい時に各Java版Lindaサーバーへデバッグ
タスクを投入し、デバッグタスクを切断してもFederated Lindaの通信状況は変化せず続く、というように
Federated Lindaを動かしながらのConnect,Disconnectに対応する。
図\ref{comdebug1}にその様子を示す。
\begin{figure}[htbp]
\begin{center}
\includegraphics[width=16cm]{fig/pdf/comdebug1.pdf}
\caption{デバッグタスクのConnect,Disconnect処理}
\label{comdebug1}
\end{center}
\end{figure}

Federated Lindaの通信を止める事無く通信のデバッグタスクを投入できることで、通信ログが欲しい
状況に適宜、通信デバッグタスクを投入することができる。また、Federated Linda全体の通信状態の
遷移が知りたい場合は、Federated Lindaを構成するLindaサーバーの全てに対して通信デバッグタスクを
投入し、Federated Linda内部のシーケンス番号や時系列情報を添付したログにおいてその整合を行う。
図\ref{comdebug2}に実装したデバッグインターフェースの動作の様子を示す。
\begin{figure}[htbp]
\begin{center}
\includegraphics[width=16cm]{fig/pdf/comdebug2.pdf}
\caption{通信状態のデバッグインターフェース}
\label{comdebug2}
\end{center}
\end{figure}

\newpage
  \subsection{実装の詳細}
今回、Java版タプルサーバーへの機能拡張として追加した、通信状態のデバッグインターフェースは、
以下のクラスから構成される。
\begin{figure}[htbp]
\begin{center}
\includegraphics[width=14cm]{fig/pdf/comdebugClass.pdf}
\caption{通信デバッグインターフェースのクラス図}
\label{comdebugClass}
\end{center}
\end{figure}

class ComDebugはJava版Lindaサーバーにおける通信状態のデバッグインターフェースを提供する。
通信状態のログはハッシュテーブルであるCom\_Hashtableに蓄えられ、デバッグインターフェースの
接続先を表すリンクドリストのReport\_Channellistに対して、Report()メソッドを用いてデバッグクライア
ントにLindaのタプルとして送信される。

class ComDebug\_Clientは通信状態のデバッグインターフェースにおけるクライアントプログラムであり、
その実行時にLindaサーバーのホストネームとポート番号を指定して接続する。クライアントプログラムの
通信ループはclass FederatedLinda.java, class PSXlinda.javaで定義されたSelectorベースのLinda APIの
通信ループを用いる。クライアントプログラムが受け取る通信パケットはLindaのタプルデータである。

\subsubsection{機能拡張を行ったLindaサーバーの通信ループ}
以下に、今回の通信状態デバッグインターフェース拡張を行った、Java版Lindaサーバーの通信ループ
を示す。
\begin{center}
\begin{itembox}[l]{ComDebug機能拡張部分}
{\footnotesize
\begin{verbatim}
        if (debug) {
           System.out.println("data from : "+key.channel());
        }
        if((mode == '!') || (len == 0)) {
           Connection_Close(key);
           com_debug.reportCh_remove(key, reportCh_list);
        }
        else if(mode == PSX_CHECK) {
            Check(key, command);
        }
        else if(mode == PSX_IN || mode == PSX_RD){
            In_Rd(key, command, mode);
        } 
        else if (mode == PSX_WAIT_RD) {   
            Wait_Rd(key, command, mode);   
        } else if(mode == PSX_OUT) {
            Out(command, data);      
        } else {
            System.out.println("Uncorrect buffer");
            System.exit(1);
        }

        //COM_DEBUG
        if(id > PRIVILEGED_ID_START && id < PRIVILEGED_ID_END){
            ComDebug.addChannel(key, reportCh_list);
        }
        //DEBUG用カウンタ
            ComDebug.Com_inc(key, com_Loggingtable, mode);
        //DEBUG用レポート
            ComDebug.Report(reportCh_list, command, com_Loggingtable.toString());

\end{verbatim}
}
\end{itembox}
\end{center}
通信ループ内において、通信状態のデバッグインターフェースを受け付けるのは要求があったidが、
PRIVILEGED(特権的な)\_IDとして確保した領域であった場合である。今回は1〜65535までのタプルスペースID
のうちidが32769以降の場合において、その要求をデバッグインターフェースの為の特権IDとして用いた。
特権IDでの要求を検知した場合、ComDebug.addChannelを行い、通信状態の報告を行うセッションのリストに
追加を行う。また、報告を行っていたセッションが切断された場合はコネクションのクローズ処理と共に、
reportCh\_remove()メソッドによって報告セッションリストから対象の削除を行う。これにより、
デバッグインターフェースの動的な接続と切断が実現される。

ComDebug.Com\_inc(),ComDebug\_Report()においては通信状態の更新と報告を行う。
これらのコードの追加によって、Java版Lindaサーバーへの通信状態のデバッグインターフェース機能拡張
を行った。

  \subsection{視覚的に通信状態を確認するツールの開発}
Lindaサーバーへの通信状態デバッグ機能の追加と、その為のクライアントプログラムによって、Federated L
indaの通信状態のログを取得する事ができた。しかし、取得したログはそれだけではどのような通信状態の
変化があったのかを直感的に知る事は難しい。よって、前述したデバッグインターフェースを用いて取得した
ログを視覚的に確認できるツールの開発を行った。

このツールは、Federated LindaのConfigurationに用いたOmni Graffleファイル、同じくConfigurationに
用いたノードリスト、そしてデバッグインターフェースで取得した通信状態のログ、をもとにその通信状態
をモニターする為のツールである。図ref{}にその様子を示す。

\begin{figure}[htbp]
\begin{center}
\includegraphics[width=14cm]{fig/pdf/comdeb.pdf}
\caption{通信状態の表示ツール利用}
\label{comdeb}
\end{center}
\end{figure}


\begin{figure}[htbp]
\begin{center}
\includegraphics[width=10cm]{fig/pdf/visual01.pdf}
\caption{通信量のグラフィカルな表示ツール}
\label{visual01}
\end{center}
\end{figure}

\section{Compact Rotingの実装を用いた評価}

  \subsection{通信量のスケーラビリティ}

  \subsection{評価}

\section{考察}



%\subsection{Federated Lindaのデバッグ}
%現在主流なデバッグ手法はプレークポイント等を用いてプログラムを停止し、その地点からの前後でプログ
%ラムの状態を確認する、二分法によるデバッグ手法である。
%Federated Lindaを用いた開発環境においてもこのような手法は大変有効ではあるが、通信の状態によって、
%デバッグが可能な場合と困難な場合とが存在する。

%以下の図\ref{seqdeb}に通常用いられるデバッグが有効なFederated Lindaの通信状態を示す。


%\begin{figure}[htbp]
%\begin{center}
%\includegraphics[width=8cm]{fig/pdf/seqdeb.pdf}
%\caption{デバッグ可能なFederated Lindaの通信}
%\label{seqdeb}
%\end{center}
%\end{figure}

%\begin{figure}[htbp]
%\begin{center}
%\includegraphics[width=10cm]{fig/pdf/nonseqdeb.pdf}
%\caption{デバッグが困難なFederated Lindaの通信}
%\label{nonseqdeb}
%\end{center}
%\end{figure}


%\subsection{分散環境におけるデバッグ}


%今回は、Fedarated Lindaを用いた分散プログラム開発としてCompact Routingを用いるFederated Lindaの
%分散アルゴリズムの開発を行った経験にて、通信状態や通信量をデバッグできる機能が必要であるとの知見
%を得たことから、通信量のデバッグインターフェースを実装する。
%このデバッグインターフェースはLinda サーバーやクライアント(Protocol Engine)間での通信を止めずに、
%動いているFederated Lindaの通信量をデバッグする（すなわち、通信量のスケーラビリティを見る）
%インターフェースである。

%\subsection{Java版タプルサーバーへの通信量デバッグ機能の実装}



%\newpage
%\subsection{通信ログ情報のグラフィカルな表示ツール}

%\section{通信量デバッグインターフェースによる評価}