\chapter{まとめ}
本研究では、Christieの概要について説明を行い、Unityで使用可能な通信ライブラリの特徴を挙げた上で、ChristieをC\#に書き換える意義について述べた。
C\#での再実装時に発生した問題である、attributeの実装、CodeGearの処理をThreadからTaskへの変更、MessagePackのバージョン変更、
MessagePackを使用する際の送信パケットの変更について述べた。
また、ChristieとChristie Sharpの記述方法の違いと、UnityでChristie Sharpを動作させた際の記述について説明した。

他の通信ライブラリとの比較では、PUN2とMirrorとの比較を行い、Christie SharpはUnity APIは未対応であるが、OSSにする予定のため拡張や改良が可能である。
また、p2pで通信を行うため強力なServerを使用する必要はなく、Topology ManagerのHostをServerで動作させることで、クライアントサーバ方式に変更が可能である。
さらに他のライブラリにはない特徴として、単体でも並列処理が可能であり、外部の並列ライブラリを導入せずに済む。
参照すべきデータをPeekで取得することで通信切断時にも、ゲームロジックが停止せずに続行可能であり、Topology Managerの機能を拡張することによって、
切断された際にゲームに再接続できるのではないかと考察した。

\section{今後の課題}
Topology Managerの再実装が完了しておらず、機能を十分に使用することができていない。
特にTopology Managerが動作しているHostと親node同士の接続はできているが、子nodeからの接続がうまくできていない。
また、現状ではTree型のTopologyのみ対応しているため、Star型など他のTopologyも対応する必要があると考える。

DGはC\#でサポートされている全ての型を指定可能であるが、TreeMapを使用することがある。
しかしTreeMapをデータとして通信を行うと、巨大なデータ構造となって送信してしまい分散通信のバフォーマンスを低下させる要因になる。
そこで、TreeMapのkeyを使用してPut/Takeを行うように修正を行う必要があると考える。
keyの他に接続先のhostname:portを2nd keyとして指定しTreeMap内のデータの通信を行う。

Sockt通信を行っているのはTaskによりThread Poolで実行されているが、これのCodeGear化を行いたい。
Topology Managerの実装はその大半がCodeGearとして処理されているため、Socket通信部分もCodeGear化が可能であると考える。
必要なデータはTake/Peekを利用して渡すことで実行可能である。