安田研究室　特別研究課程

2004年に理学部コンピュータ科学科に移って以来、特別研究課程を担当している。 これは学部学生が三年次からまるまる二年を掛けて取り組む、いわゆる卒業研究である。 ここには各卒業年度ごとのテーマと概要をまとめておく。 なお組織変更に伴い、2008年にコンピュータ理工学部、2018年に情報理工学部に移ったが、科目名が同じ特別研究課程であるため特に区別せず書く。

卒業研究報告

卒業・修了年度別インデックス： 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023

第1期（2005年度卒業）

1. P2P型多人数参加ペイントソフト （遠藤嵩之） [ summary ]
   多人数で共同作業を行うアプリケーションをP2Pモデルで試作したもの。P2P関連技術の典型的な問題として、ノードの参加、離脱、同期の問題などを扱っている。二年間の特別研究課程で学んだネットワークプログラミング及びP2P関連技術の総ざらい。
   
2. RSSデータの蓄積・検索システムの開発 （竹中悠喜・長井祐輔） [ summary ]
   一般にRSSデータに含まれる情報量は少なく、プロトコル上の制約から長くても10日程度で過去のものが削除されてしまう。この程度では検索・抽出してもその利用価値は低い。そこで本研究では多数のWebサイトからRSSデータを収集・蓄積し、事後にそれらをキーワード検索可能とすることを提案する。実際に動作するシステムを作成した。
   
3. IPsecを用いた多地点間接続の自動化システム （増田勝哉） [ summary ]
   IPsec で経路の暗号化を行うには、ペアごとにIPsec の設定を行う必要がある。技術的にはP2P のような分散システムでIPsec 接続を行うことは可能であるが、両端で共有する必要があることが問題である。つまり共通鍵の生成や管理方法はIPsec の仕様に含まれておらずユーザーが手作業で設定する必要があるため、多地点間でIPsec を構築する場合はユーザーの負担が大きい。本研究では SSL によって共通鍵の管理と共有処理を自動化し、参加ノードが増加した場合でも容易に運用できるシステムを開発した。暗号強度は SSL にまで下がるが、IPsec がもたらす利便性を享受することが可能である。
   

第2期（2006年度卒業）

1. インターネット電話の通話とトラフィックの関係 （稲上　雅一） [ summary ]
   この時期に利用が一般化しつつあったインターネット電話サービス（Skype, Google Talk, Windows Live Messenger）のトラフィック傾向を調査・分析し、インターネットに与える影響について考察した。無音時のパケット送信量やプロトコルなどさまざまな点で相違があることが分かった。
   
2. Firefoxの機能追加:サムネイルによる履歴表示 （植谷尚貴） [ summary ]
   [ スクリーンショット (PNG) ]
   
   ブラウザでは履歴をたどって過去に見たページを閲覧することが可能である。ブラウザの履歴表示は Web ページのタイトル文字列とページのアクセス順によってのみ表現されるが、Web ページを閲覧する際にページのタイトル文字列を覚えているとは限らず、あまり有効な提示方法ではない。そこで本研究ではページのサムネイルを用いた履歴表示の方法を提案し、実際に動作する Firefox 機能拡張を作成した。
   == note
   なお、実際にはもっと広大・高解像度なディスプレイを用い、コンテンツの周囲に大量にサムネイルが広がる状況を仮定している。近い将来そうなると想定していたが当時は手元にそれが無かった。ようやく 2014年あたりに長辺が 2500〜2000 画素程度のディスプレイが一般的に常用されるようになった。
   
3. ゴシッピングの改良:伝播時間の調整 （戸井健太） [ summary ]
   非構造化P2Pネットワークにおけるゴシッピングは、ネットワーク構造によってはネットワークの負荷が高いことや、探索が遅いといった問題が生じる。しかしこれをスモールワールドネットワーク構造を導入することで解決可能である。 またスモールワールドネットワーク構造の度合いによって探索時間とトラフィック負荷を調整することも可能である。本稿では、積極的に長距離のリンクを作成することによってスモールワールドネットワークへの自律的な変化を誘導し、探索時間を調整する手法を提案する。また提案手法の有効性をシミュレーションによって検証する。
   [ 加速結果 (+50%設定) (MPEG) ] スモールワールドネットワークに対して長距離リンクを作成することでゴシッピング伝播時間を設定した通りに加速している。
   
4. 初学者のためのSSL教材 - 分かりすいとは何か -（西川とき葉） [ summary ]
   本研究はシステムでは無く教材の作成である。難解な技術についてあきらめずに最後まで学ぶことができる分かりすい教材とは何か、既存の教材が持つ問題点を探し出し、改善提案を行う。また実際に提案に基づく教材を制作することにより、分かりすい教材が実現可能であることを検証した。とりあげた教材は身近で多くの危険が潜む「電子商取引における危険とその回避を事例で学ぶ」ものとした。
   
5. 位置情報管理ソフト - 街頭犯罪情報共有のために - （春若元俊） [ summary ]
   これは街頭犯罪の被害を回避するために、地域住民が街頭犯罪に関する情報を積極的に情報交換するシステムの試作である。残念ながら一般的な掲示板システムの実装にとどまった。
   
6. P2P向きBlog Systemの開発 （坊農啓史） [ summary ]
   [ スクリーンショット (PNG) ]
   
   Unstructured P2P環境に適した分散データ管理方式として提案されているWOODS (Write Once Oriented Data management Structure)と呼ばれるデータ管理モデルがある。本研究はこのWOODSに基づくデータ構造を用いたBlog Systemを試作するものである。実際にはシステムモデルを元にライブラリ(WOODS API)の設計・実装を行い、その後、Blog のデータモデルとアプリケーションの設計・実装を行った。実利用されていた mixi の日記データを用いて作成したBlog アプリケーションの動作テストも行った。
   
7. GPS携帯を利用した位置情報付きデータの共有 （森山晋介） [ summary ]
   本研究では GPS の位置情報を含んだ情報(写真、題名、コメント)を、携帯電話を利用して複数の利用者で共有できるシステムを構築するものである。実際には位置情報付きデータをアップロードする側は完成せず、指定した領域の地図画像を切り出してアノテーションをつけて表示する側だけを作成した。
   == note
   なお前年2月にGoogle Maps のベータ版サービスが開始されたばかりであり、iPhone (2G) の発表が2007年1月（まさに論文執筆当時）と、当時この種のものはまだ少なかった。
   

第3期（2007年度卒業）

1. イベント出欠確認システムの設計と開発 （中川岳郷） [ summary ]
   イベント出欠登録をするWebアプリケーションの開発である。当時スマートフォンはほぼ存在せず、100人近い部員の情報を効率良く集めるために「誰かが代理になって」登録できる機能を追加した点がユニーク。
   

第4期（2008年度卒業）

1. Flashによる画像検索システムの開発 （足立麻衣） [ summary ]
   [ 機能説明ビデオ (MPEG4) ]
   
   既存の画像検索システムは気に入った画像を見つけ出す際に 1)ユーザが覚えておくべき情報が多すぎ、2) 途中の操作に連続性がなく作業しづらい。本研究ではこれらの問題を解決するために、気に入った画像をより見つけやすい画像検索システムを試作し、手法の有用性を検証するために評価実験を行った。
   == note
   当時 Google にせよ Yahoo! にせよ画像検索は今のようにスクロールダウンすると自動的に画像を追加するようなものではなく、50画像ほどタイル状に表示して「次ページ」をめくるような提示方法だった。提案は操作の連続性に関しては先取りしており、2015年の今でもマップやトレース痕表示、マーク付けなど主要なアイディアの幾つかは新しさを失っていない。
   
2. 研究室を対象とした物品管理システムの設計と開発 （清水保宏） [ summary ]
   本や機材の管理を目的としたWebアプリケーションの試作である。研究室やスモールオフィスなど小規模での運用を対象とし、操作におけるわずらわしい確認メッセージを省略することを目標に設計、実装されている。
   
3. NATを越えた直接通信による仮想マシンの差分バックアップ （清水好浩） [ summary ]
   本研究は互いに異なるNAT以下にあるPCが、相互にデータを送るシステム（仮想マシンイメージの相互バックアップを仮定）を試作するものである。UDPホールパンチングを行うファイル転送プログラムの開発・設計・実装にとどまらず、UDPによる大量データ転送時の流量・輻輳制御などを行い、実際のインターネット環境において転送実験を行って実用性について評価した。
   
4. リモートアプリケーションの GUI 反応速度低下のキャッシュによる改善法 （中尾達也） [ summary ]
   リモートで GUI アプリケーションを利用する際、ネットワーク遅延によって操作の反応には遅れが生じる。本研究はGUIパーツの動的なキャッシュを行うことで反応速度の低下をどの程度抑えるのかをシミュレーションによって検証する。
   最終的には実際に機能するポータブルなGUIパーツのデータ構造の設計なども行い、実際のインターネット環境で実験を行った。
   
5. 画像ビューアの設計 （中村晃輔） [ summary ]
   ディスプレイの100倍といった巨大な画像を分割表示する画像ビューアの設計と実装を行った。
   == note
   当時既にGoogle Maps があり、類似のサービスも存在していた。これを参考にして通信環境ごとの最適な分割サイズの選択といったことを検討させたかったがそこまでは到達せず。
   
6. アドホックネットワークにおける経路探索時の通信量の削減 （中村将巳） [ summary ]
   本研究では車々間通信を想定した新しい移動体ネットワークにおける経路探索手法を提案し、シュミレーション実験を用いた性能評価を行った。具体的には近傍のノードではなく、無線到達範囲のできるだけ外周領域にあるノードを対象にルーティングすることでホップ数を削減する。
   

第5期（2009年度卒業）

1. Firefox における LocalStorage を用いたアノテーション機能 （鷲見拓也） [ summary ]
   Read OnlyなWebドキュメントに対して、その文中にアノテーション(ここでは「注釈」を意味する)を挿入できる機能を開発し、Webブラウザに実装した。
   [ 操作説明 (PDF) ]
   == note
   ブラウザの LocalStorage 機能が当時出たばかりで、それを用いたシステムの試作に挑戦したものである。アノテーションの追加機能だけでなく、むしろドキュメントの更新があっても設定したアノテーションを正しい（と思われる）位置に表示するための推定にこそ技術的ハードルがある。ここでは単純な段階的文字列比較しか実装できなかったが、曖昧検索によるより妥当な推定、あるいはアノテーションを追加した元の記述が失われた場合の対処など、まだまだやることが多く残されている。
   
2. サーバ監視ソフト Nagios のログデータをグラフ化する （桝本裕也） [ summary ]
   Nagiosのログデータを継続的に蓄積、グラフ化し、サーバ管理者のトラブルシュートを補助することが目的だったが、あまり意味のある成果が出せなかった。
   
3. ROP : 途絶に耐えて新しさを優先するプロトコルの設計 （横関健悟） [ summary ]
   モバイル端末によるインターネット利用では、数分から数時間の通信の途絶が日常的に発生する。一般にはそうした途絶が発生すると通信を一旦終了し、通信可能になった時に改めて処理を行う。 しかしそのような長時間の途絶があっても通信を終了せず再開を待ち、そのような事態に適した再送制御を行う仕組みが用意されていても良いはずである。本研究では通信の途絶に対応する通信プロトコル ROP (Recent Oriented Protocol) の提案を行う。ROP は途絶後に再送制御を行うが、TCPとは異なり再送より最新データの送信を優先する。なお本研究では実装には至らず、設計までを行った。
   == note
   主たる工夫はACKのまとめ送りの手法などである。この分野はまだまだやれることが多いが、こうしたタフな内容に取り組む学生が減ってしまったのが残念。この研究はその意味でも貴重なトライとして評価できる。

第6期（2010年度卒業）

1. Twitter への過去を 思い出させる機能の追加 （稲熊洋介） [ summary ]
   用事や予定を忘れやすいくせに、備忘録に書く習慣を持たない人がいる。予定表は時間が来れば知らせてくれるシステムを作りやすいが、本屋に来たらxxを買う、xxが出演する番組は録画する、といった用事はそのような「起点」を設けにくい。一方で日常的にTwitterなどのネットワークサービスにリアルタイムに多くのことを書く人がいる。ここで作成したシステムは、Tweet した内容から類似度の高い過去の Tweet を補助的に提示するTwitterクライアントである。
   == note
   「起点」の候補としてはTweet（文字列）だけでなく位置情報も当初想定していたが実装がそこまで届かなかった。この翌年にAppleがリマインダーアプリで「この場所に来たら」反応する機能を入れたので、Appleに先んじる事ができた、と言えるチャンスを逃したことになる。残念。 この手法の面白みは関連性の強さを余り厳しく判定しない代わりに、日常的に操作する Tweet 画面に「それとなく」邪魔にならないように表示することにある。つまり「確定的な予定を厳密に管理する」一般的な予定管理に対して、真逆の「はっきりしないままそれとなく表示して利用者に判断させる」アプローチである。Amazonの商品推薦などもそうであるが、2015年春に日経とEvernoteがほぼ同じアプローチのサービス「関連ノート」を出した。 また「起点」として今回は過去のTweetに絞ったが、実際にはメイルや各種メッセージ、ブラウザ閲覧・検索履歴なども想定には含まれていた。つまり「現代ではコンピュータはユーザが受発信する多くの情報を目撃しており、その情報からマイニングできることはとても多い」ことが本研究の骨となるテーマである。まだまだやれることは多い。
   
2. 複数ホスト間での間欠的なデータの同期 （高島誠孝） [ summary ]
   個人で複数の PC を所有している場合、同じファイルを全ての PC で扱う可能性がある。そ のために各ホストに手作業でファイルをコピーする代わりに、本研究では、ネットワークを通じて複数のホスト間で指定されたディレクトリ内のファイルを同期するアプリケーションを開発した。具体的には非構造的なP2Pネットワークを組織し、そこでファイル群の同期をとるためのプロトコルとアルゴリズムを設計し、6 台の実機を用いてその動作を確認した。
   
3. EOS (Arista Networks) への 802.1X 認証機能の追加 （向井健太） [ summary ]
   EOS (Arista Networks 社スイッチの OS) は Linux ベースの OS で、従来のネットワークスイッチで使われている組込 OS に比べて機能追加が容易である。本研究で は 802.1X 認証機能を EOS に追加した。EOS は拡張機能のパッケージングを支援しており、802.1X 認証を機能させるソフトウェアと管理ソフトウェアをパッケージとしてまとめた。
   == note
   最終的な成果物は802.1X suite for EOS として公開された。それを参照することでも分かるが、有線での 802.1X 認証をサポートする OSS のコードが無く、単純な移植では済まなかったために多くのコードを追加している。
   

第7期（2011年度卒業）

1. OpenFlowにおけるフロー追跡手法 （妹尾郁弥） [ summary ]
   OpenFlow ネットワークでホストからホストまでの一連のパケットの転送経路(フロー)およびコントローラがフローエントリーを決定する処理で通った箇所(ロジック)を追跡し，経路を可視化するシステムを開発した.
   

第8期（2012年度卒業）

1. Twitter における楽曲情報の抽出 （井戸木良） [ summary ]
   Twitter に流れる特定ハッシュタグつきの投稿から楽曲情報を抽出する試み。
   == note
   当初は曲の長さ情報やアルバムの収録状況を見て、連続的に再生しているユーザの割合やアルバムと個別曲の聴かれ方などの違いについて調べようとしていたが、そこまでは到達できず。まだまだやれることは多い。
   
2. SPAM の逆探知に関する試み （亀石知果） [ summary ]
   一般にスパムの送信者が自分のメールアドレスをどのような方法で入手しているのか知る機会は無い。本稿はメイルアドレス収集手段として挙げられる手法のうち 5 つに対して実証実験を行った記録である。結果、掲示板への記入と配信停止処理を行ったケースについてスパムが来る事例を得た。
   
3. DNS 逆引き情報を利用したトラフィックの可視化 （小林優貴） [ summary ]
   DNS の逆引きから得られるホスト名によってトラフィックを分類し、可視化することで、Google や Yahoo! といった有力サイトへのトラフィックを把握しやすくする。
   == note
   ただし可視化そのものは安田が過去に作成した Packet Leap を用いている。この研究では非同期のDNS逆引きと、ホスト名による分類機能を加えた点で、それを活かしたトラフィック分類や画面表示への反映に関しては手が届かなかった。こうした可視化や表現についてはDAEDALUSなど多くやれることがある。
   

第9期（2013年度卒業・修了）

1. ネットワークスイッチの設定情報の可視化 （中根誉佳） [ summary ]
   SDNではソフトウェアがネットワーク機器を設定を行うため、オペレータはネットワーク機器の設定情報を把握する機会が減った。それは SDN による恩恵でもあるが副作用もある。本研究ではオペレータに機器の状態を分かりやすく提示するために、ネットワークスイッチの設定情報の可視化を行った。
   
2. 通信の遅延を考慮したインタラクションのための表示手法 （溝口夏樹） [ summary ]
   本研究は通信の遅延による不自然な表示を補正するものである。例えば卓球をする二人のプレイヤーがいて、ボールの位置や相手の動きをネットワーク越しの通信によって情報交換して動作するような場合、互いが起こした事象が相手に伝わるまでの通信遅延が互いの表示において問題となる場合がある。これを補正してスムーズにプレイできるような表示を可能にするアルゴリズムを検討し、試作した。
   

1. サービスに注目したトラフィックの分類と可視化 （妹尾郁弥） [ summary ]
   [ 表示例 (mov) ] [ 表示例 (mov) ]
   本研究はユーザが利用しているサービスに注目したトラフィックの分類と可視化を行うものである．
   一般にトラフィックの分類ではホストのアドレスやプロトコルなどによってトラフィックを区別するが，本研究では利用者が認識するネットワークサービスを単位とする．たとえばYouTubeは多数のホストを用いて，さまざまなプロトコルを組み合わせて構成されているが，それらYouTubeを実現するためのトラフィックはすべて単一のネットワークサービス “YouTube”として分類する．つまり同じWebサービスであってもTwitter，Facebook，Amazonや楽天といった単位で分類され，可視化される．
   本手法の応用として，ユーザ自身による不適切なトラフィックの抑制などが考えられる．具体的には，その場のトラフィックをリアルタイムに取得し，いまそこで利用されているサービスの内容を分かりやすく分類・可視化して周囲の他のユーザに提示する．これによって各ユーザが自主的にその場において好ましくないと考えられるトラフィックの発生を行わないように促せる．
   具体的なサービス分類は 1) HTTPのHostヘッダから得たドメイン名，2) IP アドレスの逆引きドメイン名，3) IP アドレスに対する whois 情報の三つから判定する方法を試みた．いずれの方法も主要なサービスに対して照合する文字列あるいはアドレスのリストを用意して判定する．完成した可視化システムではトラフィックはサービスごとにまとめられ，三次元的に表示される．各ノードは対向する二つの平面上に配置され，パケットはその両平面を行き交うように表示される．大量のトラフィックをそのまま描画すると視認性が悪化するため，一定量を超えたパケットの列は帯として表示するなどの工夫を施した．
   

第10期（2014年度卒業）

1. OpenFlowスイッチにおける経路変化の可視化 （谷口裕紀） [ summary ]
   SDNの本質ははオペレータの操作が自律的なソフトウェアによって代替されることにあるが、それはオペレータの把握しないところで経路設定などが行われることを意味している。通常時はそれで問題がないとしても、ひとたびソフトウェアのバグやオペレータのパラメタ設定などの失敗による事故が発生した場合、これがトラブルシュート（問題の把握）を難解にする可能性がある。
   本研究ではOpenFlowスイッチの経路設定の変化を予め記録し、問題が生じた際にその変化を認識しやすい形で提示するシステムを試作した。これによって上記のトラブルシュートを支援することが目的である。具体的には定期的にネットワーク上のフローエントリを何らかの手段によって収集し、前後のエントリ情報を比較することでフローエントリの変化を検出し、事後に指定された時間範囲における変化を可視化し、その変化（追加・削除・継続）を分かりやすく提示する。オペレータはトラブルが生じたと推定される時間帯に狙いをつけて、その変化を縦覧することで問題の原因を発見しやすくなるだろう、という目論見である。
   == note
   実装が追いつかなかったことが残念だが、オペレータ支援は多くの可能性をもつ領域と思う。
   
2. 音声によるスタンプ機能が使えるチャットシステムの試作 （安藤香織） [ summary ]
   [ スクリーンショット (PNG) ] [ 機能説明ビデオ (mp4) ]
   本研究はチャットに音声スタンプを導入するものである。すなわちイラストによるスタンプと同様に、テキストメッセージのやりとりに音声を挿入できるシステムを設計・試作した。また被験者実験によってその性質を調査・検証を行った。
   その結果、初めてシステムに触れた利用者どうしのチャットであっても、被験者は僅かの説明の後にイラストスタンプと同様に音声スタンプを感情・心情あるいは状況を伝える道具として使用した。これは音声スタンプがその機能においてイラストスタンプと同じもの（同様に使えるもの）として受け入れられた事を示しており、イラストスタンプ同様に急速に広く普及する可能性を示唆する。
   本研究で試作した音声チャットシステムは録音・加工（エフェクトとミキシング）によるスタンプの自作を特徴の一つとする。イラストによるスタンプの自作は、絵を描くこと自体の難しさ（不慣れ）や必要とする時間が長いといった問題があるのに対し、音声スタンプの自作は誰でもその場ですぐに行える利点がある。実験では相手の名前や大学の部屋の名前を入れるなど、より利用者の細かな状況に合わせたスタンプを作ろうとする傾向が見られた。また、加工が匿名性確保の手段として有益であることが女性利用者の意見から明らかになった。
   == note
   この研究はこの年度で唯一、指導教員と担当者の双方にとって未知のものに取り組んだものだったが、新しい知見が得られた興味深い研究となった。
   発表では音声スタンプの一覧性について質問が出た。自作を含めて多数のスタンプをどうやって縦覧するか、という指摘である。視覚情報に対して音声情報はその一覧性が低いのは明らかで（安田は文字やラベルでタグづけして検索する事を考えるが）、それ自体が一つの大きな研究テーマとなるような指摘と解釈する。いずれにしてもそうした興味深い指摘を引き出せるような研究となった。
   なおチャット部分は公開されている WebRTC の機能を利用したファイル転送機能つきサンプルを基に同学年の廣瀬が作成したものであるが、それ以外のPureDataによる音声加工アプリケーションの開発と被験者実験・調査は安藤が行った。本研究の本質はWebインタフェイスではなく音声スタンプと評価にあるため卒業論文は単著としている。
   また、2014年1月末にLINEが「音付きLINEスタンプ」を出したが、これはイラストスタンプに効果音が付いたものであり、従来的なイラストスタンプの延長でしかない。本提案では音声について絞ったために「自作」という価値が生まれており、音付きイラストスタンプはそこにはたどり着けない。
   
3. OpenFlowスイッチの遅延計測自動化 （土屋葵） [ summary ]
   OpenFlow スイッチのパケット転送能力はフローエントリによって大きく異なる。あるパケットの処理（Action指示）の実装がハードウェア（Switch ASIC）内で済めば速いが、ソフトウェア（制御用CPU）実装になると極端に遅い。MAC, IP の書き換えそれぞれはハード処理可能でも、両方を行うよう指示するとソフトウェア処理に fallback する可能性もある。スイッチOSのバージョンによっても異なる可能性がある上に、コントローラ（OpenFlowアプリ）のバージョンが上がったら途端に問題となる種類のエントリを設定するかもしれない。更に OpenFlow 2.0 では各ビルドごとに相違が出るだろう。この問題は研究でも未だ手つかずの領域であるが、しかしOpenFlowスイッチの実運用では大きな問題となる。
   そこで安田はエンドユーザ向けの、すなわち容易に問題となり得るフローエントリの有無を検査できる安価な転送遅延計測装置を提案している。開発中の Lawine システムは FPGA を用いて10G Ethernet の転送遅延をクロックサイクル精度（今回の製品では8ns）で計測可能である。本研究ではこのシステムに対して連続的な検査機能を加える。具体的には検査対象となるフローエントリとパケットパターン及びその組み合わせを与えて、RYU と Lawine をそれぞれドライブして検査を行うシステムを構築した。
   == note
   届かなかったが、Use Case に合わせた計測結果の可視化までを視野に入れており、まだまだやれることが多い領域。Lawine のテストや RYU の改修（実装不充分な箇所へのコード追加）に時間を取られたこともあるが、惜しい。
   
4. 検索語を用いたページ内情報探索の支援 （西村拳） [ summary ]
   [ スクリーンショット (PNG) ]
   検索エンジンはユーザの情報探索を支援するものであるが、提示されるものは候補となるページ群に過ぎない。ユーザはそれから各ページを閲覧して求める情報を自身の目と手で探す必要があり、長文コンテンツではこの作業はかなりの手間となる。これはユーザの探索活動が「ページ」で一度断絶していることを意味する。
   本研究では両者、ネット検索とページ内検索を接続する試みである。具体的には検索エンジンに与えた複数の検索語を自動的にページ内でハイライトし、コンテンツ全体での出現位置をスクロールバーに表示する Chrome 拡張機能を作成した。これによってユーザは提示されたページを素早くチェックすることが可能になる。（スクリーンショットは「psql」「メタコマンド」で検索した例）
   == note
   テーマとしてはページ内検索における情報提示、つまり「あやしい度合い」の表現に時間を費やしたかったがそこまで到らなかった。検索エンジンのもつ検索語との不一致（曖昧検索や suggestion 機能）対応など、やるべきことはまだまだある。不完全ながら候補ページ中の検索語の位置を頼りにページをチェックすることに見込みがある、と事前調査で出せたことには意味があった。
   
5. 仮想化環境におけるシステム構成テストツールの提案 （橋坂侑汰） [ summary ]
   本研究は分散システムの基本的な構成検討、サイジング（負荷に対する要素ノードのバランス検討）を容易にするために、自動的なパフォーマンステストシステムの開発を目指すものである。OpenStack と Docker によってプログラムされた構成を高速に作り、試験し、データを可視化してシステム管理者に提示する。
   実際には自動化まで到達せず、OpenStack と Docker を手でオペレーションしてロードバランサ、リバースプロキシ、App、DB、キャッシュからなる仮システムを構築し、実験としてそれらの設定パラメタやノード数、掛ける負荷を変化させて性能を測定し、それぞれのパラメタの関係などを検討するにとどまった。
   == note
   本来であれば実験で得られた経験とデータを下敷きに調査シナリオを作成し、それに沿ったテストを自動的に行い、データを収集して可視化するシステムを設計・開発することが目的であったが、投入する時間が足りなかった。残念。
   
6. iBeacon を用いたイベント参加者の動線表示 （廣瀬真人） [ summary ]
   Bluetooth LE などを代表として小型センサやモバイルデバイスを用いた人流解析がよく行われている。本研究もその一事例となるものであり、イベント会場の来場者に iBeacon デバイスを携帯してもらい、会場各所（四室及び廊下で計29箇所）に設置した iPod Touch によって各 Beacon の受信電界強度を記録し、事後にその可視化を行う予定であった。iPod Touchによるデータ収集システムは安田が開発したものを利用しており、廣瀬は実験の計画・実施および収集データの後処理と可視化を行った。
   == note
   全体として時間を使えておらず、基礎実験、リアルタイム表示などあらゆるものを切り落としながら進めたが、それでも成果の薄い結果となった。可視化だけは何かしら工夫が欲しかった。
   

第11期（2015年度卒業）

1. OpenFlow を用いたネットワーク学習支援システム （清水控視・磯井哲・今井理） [ summary ]
   二年次必修科目であるネットワーク実験、具体的にはルータにエンドノード（PC）を接続して、全てのノードが相互に通信できるようにネットワークを構成する、つまりルータに適切なルーティングテーブルを設定し、疎通を確認するものがある。疎通確認作業はpingやtracerouteを用いた手作業であるため、ユーザは例えば 6 台のノードに対する確認作業を合計30回繰り返す。もし設定誤りがあれば再び30回の反復作業を要する。本研究ではこの疎通確認作業を自動化し、その結果を可視化するシステムを開発した。これによって受講生の学習を支援する。
   == note
   Zebraの動作確認から始めて、Ansible などツールのテスト、合計6台のサーバと10台を越えるPCを動員して複数の実験環境を構築・維持しながら、とにかく自動化システムの設計と実装、可視化までたどりついたことには拍手を贈る。可視化については何かしらの工夫が欲しかったが、そこに手が入っていないのが惜しまれる。
   なお、今年度の卒業研究で遂に学生が自分でテーマを発見して研究することをやめて、こちらから学生にテーマを提供して作業してもらうことにした。昨年度の経験から、もはや通常の特研作業ができない、と踏んでのことだったし、この研究自身はそれなりに作業としては出来上がり、学生との関係性も壊れることなく進めることができたのでそれで間違っては居なかったと思うが、一方ではやはり学生が本来もつ可能性を阻害した可能性を思ってしまう。
   

第12期（2016年度卒業）

1. 不審な通信を行うアプリケーションを検出する手法の提案 （舩侑也） [ summary ]
   2013年度の修士研究発表時のコメントで、DNS正引き情報のモニタリングによるサービス元情報の推定と提示を下敷きにした研究。応用として新しくインストールしたアプリケーションが出すトラフィックに注目し、通信先の情報を補助的に提示して「不審」な通信が行われていないことを確認しやすくするようにアレンジした。本来はマルウェアを仮想環境下で動作させた時のトラフィックをチェックして機能検証することを想定していたが作業時間が絶対的に足りず放棄した。他にもほとんどのことを切り落とした。試作アプリケーションのために作った知識ベースは僅か5時間分の自分のトラフィックデータに基づいたもので一般性が低く、マッチパターンのワイルドカード対応すら無い。Gyazo は ruby を呼びだしてソケット通信しており、他にも何ものかが bash をキックして通信しており、このあたりとても危うい（バックドア？）。これらは親プロセスを追跡することで検証可能だが何もしていない。Webブラウザについても調べられる可能性があるが放棄している。作成した通信先表示アプリケーションはCUIベースで操作性が悪く、知識ベースはエディタを使って手作業でメンテナンスするしかない。すべては工程見積もりの甘さと、その結果投入した時間の少なさからくる。
   == note
   なお今年度は前年度を含めて過去の状況を説明し、研究テーマはこちらの用意したものを手がけるように勧めたが三名の受講生はいずれも自分で探すことを選んだ。結果的に全員とも作業が遅れに遅れ、二名が脱落、残る一件も想定されたほとんどのことまで到達せずに終わることとなった。
   

第13期（2017年度卒業）

1. Beacon を用いた歩行者渋滞計測の試み （大脇拓郎） [ summary ]
   Beaconを階段の要所に取り付けて歩行者向けの渋滞度を計測する。廊下など狭い屋内でのBeaconを用いた位置推定は反射の影響などで精度が低い。しかしBeaconから受信機が1m程度の近距離にあれば（廊下の幅、つまり反射する壁面が3m程度離れていたとすると）、反射が生む電界強度に対して直接受信による電界強度の値の方が支配的になる。つまり「目の前を通過した時間」については精度高く検出できると目論んでトライした実験。結果的には3階ぶんの階段に7つ設置したBeaconのうち、使えるデータが得られたのは2つだけとなり、この両者の通過時間の違いから渋滞の有無を判別する事しか出来なかった。
   == note
   分析が遅すぎたため、置いて測った以上の工夫ができず、一度しか混雑時の計測ができなかったことが致命的だった。実験によって「移動速度と混雑度は必ずしも一致しない（激しい混雑時では人の密度が上がるだけで、階段を進む速度は変わらない）」体感があり、このとき減衰による全体的な電界強度低下がデータに出ていた。ここから通過速度と減衰度合いを合わせて新たな渋滞・混雑判定基準を提案する可能性があったが、そこまで手が回らなかった。惜しい。
   
2. 通信量制限「ギガ足りない」を抑止するアプリケーションの試作 （由尾宗汰朗） [ summary ]
   この話はもともと「操作ミスや無理解による突発的な大量データ通信」が出発点だった。事後で良いので、何が起きていたのか把握できれば同じ失敗を繰り返さずに済む。そのために必要な情報提示について検討した結果が、日ごとのアプリケーション別データ通信量を遡って提示するシステムとなった。利用者目線では日々の累積通信量の変化から「異常な動き」を発見し、検討する流れである。しかしグラフを見ていると今度は「正常なデータの使い方」が示されていないことが気になる。単純には帯域上限が設定されている範囲の初日から最終日（たいてい月初から月末）にかけて、0Byte から上限（例えば2GB）まで直線的に消費されるのが良いと考えがちだが、そうとは限らない。後半に余裕を残しておいて安心したい人も居れば、あるうちに我慢するより少なくなったら仕方なく節約する方が性に合う人も居よう。そこでその人にとっての「理想の消費パターン」を現時点の消費量に添えて提示し、利用の目安とする提案となった。ただ研究の目論見としてはこうだが、実際には UI を提案するだけで終わってしまった。
   == note
   本来このシステムは同年の若原・田中の作成したモニタリング＋可視化の応用の一つとして検討された。準備段階で Android タブレットの netstat コマンドが lsof コマンド同様にアプリケーションごとの通信状況を出力することを確認しており、VPN を利用してキャリア経由のトラフィックをモニタリングする仕組みも用意されていた。しかし開発能力の低さと投入時間の少なさからほとんど全てを切り落とすことになり、Android の通信量提示機能が出すグラフからUI 提示のための限られたダミーデータを得てなんとか動作するだけで終わってしまった。
   なお研究報告に「スクリーンショットのRGBデータを二次元配列に格納してテキストデータに出力する」と記述があるが、これは指導教員（安田）が以前に作ったユーティリティを用いたもので、由尾による仕事ではない。無論二次元配列云々は関係なく、単にPNGファイルを読んで画素ごとのRGB値をJSON形式でラップして吐くコマンドである。
   
3. アプリケーションの通信に注目した トラフィック監視環境の提案 〜不審な通信を見つけるための可視化〜 （若原洋平・田中勇） [ summary ]
   [ スクリーンショット (PNG) No.1, No.2 ]
   昨年度の舩による卒業研究の改善版である。主な改善点は 1) 3D グラフィクスの導入 2) リアルタイムなパケット流量の提示 3) モジュール構造と REST インタフェイスによる拡張性あたりか。可視化したい情報をモニタリングプログラム群によって収集し、これをサーバに蓄積して可視化プログラムが順次取得しながら描画する構造である。通信に関する何か他の情報を可視化したい場合は、不足する情報を収集するためのモニタリングプログラムと可視化プログラムを追加することで、全体的なシステム構造を変えることなく実現できることが大きなゴールである。およそこの目標に向けて開発することができた事には拍手を贈るが、それだけにこれを実現するところで止まってしまったのは惜しい。
   == note
   この研究はもともとセキュリティ的な視点だけではなく、トラフィックの内容をより良く把握することで出来ることは何かと考えながら進めたものである。舩の研究をそのまま実現するもの（本研究）以外に、携帯通信量の管理（由尾の研究の本来の形）、DNS 情報から見るネットワーク構造の可視化、HTTP など代表的なアプリケーション・プロトコルのミクロ的な可視化（主として教育目的）などがはじめの段階で挙がっていた。由尾ともう一人がこの枠組みから外れて、最終的に若原・田中で舩の研究をそのまま動作させるものだけが残った格好である。更に若原・田中もそこで止まり、新しいことが加えられなかったのは残念だった。せめて動かしてから得られた知見を元に改善するなり、malware を試すなりできれば良かったのだが、それもかなわず時間切れとなった。
   なお、今年度も取り組むテーマについて全体で揃えてやるか、各自で提案するかで右往左往した。去年度でひどい結果になったためにはじめ強制的にこちらで決めるとして進めたがどうしても作業量が上がらない。年々卒業研究は悲惨なことになっている。
   

第14期（2018年度卒業）

1. アプリケーションの通信に注目したトラフィック監視環境の提案 〜Webアプリケーションへの対応〜 （前田一樹） [ summary ]
   [ スクリーンショット No.1 (PNG), No.2 (MP4) ]
   
   先行する舩および若原・田中の研究ではブラウザのトラフィックを対象としなかった。いまどきのWebアプリは通信先が多い上にユーザは大量のTabを開いて作業することが多いため、通信先をTabごとに分類して出さなければ意味が無いからである。本研究はWebRequest APIによる通信記録とパケットモニタリングの結果を統合してTabごとにトラフィックを分類することで若原・田中のシステムにWebアプリケーションのタブごとのトラフィック監視機能を追加するものである。
   == note
   必ずしも器用にプログラミングできるわけでも無い状況で、ほぼ手探りで根気よくトラフィックとChromeの挙動を追いかけ、不完全ながら意味のある可視化ができた。Chromeの挙動が発表間際のバージョンアップで変わってしまったり、事業者がサービスとして提供するプラットフォーム上で実験することの危うさを実感した。
   

第15期（2019年度卒業）

1. ジェンガブロックの押しにくさを推定する試み （栗原拓海・山本竜佑） [ summary ]
   [ スクリーンショット No.1 (PNG), No.2 (PNG), No.3 (PNG) ] [ 発表 本編 (YouTube), 質疑応答 (YouTube), スライド (PDF), スライド (Slideshare) ]
   
   本研究では、一般的なゲームであるジェンガに対してコンピュータの支援による新しい要素を加えることを目的に、各ブロックの押しにくさを推定する。我々は「形状・大きさが僅かに異なるブロックの組み合わせによって各ブロックの摩擦抵抗に違いが生じる」と仮説を立て、摩擦抵抗測定装置（ブロックの摩擦抵抗力は軽く押せる場合で 50mN 程度、かなり重い場合で 300mN 程度）と形状測定装置（10μm程度の精度が必要となった）を作成した。それらの計測データに基づいて配置されたブロックの摩擦抵抗を推定するシミュレータを作成し、評価を行った。
   == note
   未知の対象に、まったく手探りで取り組むタイプの卒業研究となった。二人で大量のデータを採取し、検討し、改善してやり直すことをくり返した。置針式ニュートンメータで解けないと判り、ロードセルをステッピングモーターで押す装置を設計・製作したが、彼らにとっては作業のすべてが初めてだった。まずステッピングモーターについて学び、Arduinoを学び、学内ファブスペースでFusion 360を学んでアクリルレーザーカッターと3Dプリンタで部材を出し、組み立てた。マイクロメータの各所計測で済まないと判り、5μm精度のレーザ距離計を導入して装置を設計・製作した。しかしこうした作業に時間を費やし、肝心のシミュレータ製作とその評価が駆け足で終わってしまった。どうしても工程見積もりの甘さを修正できず、都度都度の作業が後ろに倒されて追い詰められた結果ではあるが、それも含めて学部の卒業研究として重要な課題をまるごと体験できたと思う。全ての過程での彼らの格闘に拍手を贈る。
   

第16期（2020年度卒業）

1. アプリケーションの通信に注目したトラフィック監視環境の提案 〜スマートフォンへの対応〜 （ウカイキョウ） [ summary ]
   [ スクリーンショット No.1 (PNG), No.2 (MOV) ]
   
   もともと舩とともに構想したトラフィック可視化システムはスマートフォンを対象としたものだった。しかしこれまで開発の容易さからプラットフォームをPC(Mac)で行っており、今年度、ようやく于によってAndroidへの移植が果たされた。また、これまでPython2で全体が書かれていたが、これをPython3で書き直してもいる。
   == note
   COVID-19による渡航制限のため、12月半ばまで来日がかなわず、作業はほぼリモートで行われた。実機が手元にない状態でエミュレータによる開発からスタートしたが、根気よく作業を続けられた事は良かった。当初、gRPCゲートウェイはJava Appとして作成したが、それをGoで書き直したり、lsof/netstat代替物を作る際の高速化のために延々と調査をするなど、成果物として見えない部分の方が大きい。
   
2. アプリケーションの通信に注目したトラフィック監視環境の提案 〜コンテンツの配信構造に注目した可視化手法の検討〜（伊藤雅弥 ・山下真弘） [ summary ]
   [ スクリーンショット No.1 (MOV), No.2 (PNG) ]
   
   これまでの可視化システムはアプリケーションやWebページごとに、その通信を単に「このホストとの通信」である、として見せるものだった。今回は新しくWebページを構成するコンテンツがCDNやPublic Cloudを用いて配信されている、その構造を可視化することを試みた。これもまた田中・若原が設計・実装した際に用いたシステム全体をモジュール構造としたことの成果の一つと言える。また、従来の実装の弱点であった性能面での改善や工夫を行った。具体的にはFlaskをgRPCに置き換え、大量トラフィックに対して適切に間引いた描画を行う、といったことである。
   == note
   やはりCOVID-19のために長期間リモートでの作業となった。短いフィードバックを必要とする状況だったが、週に一度にレビューするだけでは、それほど込み入った事も出来ず、進度も遅くなる。それでも懸案だった従来システムの性能問題とThree.jsでのメモリリーク問題を突き止めて解決したことは大きい。根気よく作業した事は評価したい。新しい可視化手法についてはほとんど時間を投入できず、予備実験や下準備を行い、簡単なモデルを試作するところで止まってしまった。惜しい。
   

第17期（2021年度卒業）

1. パケットロスの影響を調整するツールをオンラインゲームのデベロッパーに提供する試み（中條博斗） [ summary ]
   
   
   Unreal Engine などのゲームエンジンを利用してオンラインゲームを作成した場合、ゲームサーバとクライアントの間では変数の同期が行われる。従来、ゲームでベロッパーはこの同期処理に対するパケットロスがどの程度のゲームプレイの品質低下につながるか定量的に把握しておらず、同期対象となる変数の数や、遅れに対する厳しさの設定などは経験的に調整されてきた。本研究ではパケットロスを発生させる機構を作成し、その影響を定量的に調べる。それによってデベロッパーに定量的な計測に基づいた調整手法を提案することが可能になることを示している。
   == note
   当初は被験者を用意して実験する予定だった。つまりプレイヤーが操作しているキャラクターが「短い実験時間中」に「ちょうど」おかしな挙動を示すように仕掛け、バースト的なロスがどのように体感されるか調べる目論見だった。ロス発生装置に柔軟性の高い netfilter を利用したのもそれが理由である。しかしUnreal Engine のパケット解析がうまく行かず「あるオブジェクトに関する同期データを含んだパケット」だけを「狙ったタイミングでロスト」させることができなかった。そのため結果的に非常にシンプルなロストを単純なゲームアプリケーションに与えて、ベンチマーク的な情報を取るにとどまった。ロスさせた影響を動的に調査する手法が機能することは確認出来たが、残せたものがそれだけになってしまったのは残念としか言いようが無い。新しい領域に踏み込む場合、ほとんどすべてを自己開発することになるのはやむを得ない。使える時間が限られている状況で、適切なテーマ設定から始め、Unreal Engine の不充分なドキュメントと膨大なコードを相手によく格闘し、ここまでたどり着いた事は高く評価する。
   

第18期（2022年度卒業）

1. P4ハードウェアスイッチを用いた遅延計測（榎本遼） [ summary ]
   
   
   Tofino がもつナノ秒単位の正確なハードウェア・タイムスタンプ機構を使い、不安定なソフトウェア・ベースの計測結果と比較することで、ハードウェア計測の優位性を確認する。また一般にスイッチ内部では累積的な遅延分布情報を持てないためサンプリング結果を分析サーバに送ることになるが、それではバースト的に発生した問題などを見逃してしまう。そこでShifted bin counterを使い、全パケットのヒストグラムをスイッチ内で作成する。
   == note
   ハードウェアによるプログラミング経験などがない状態でも手探りで100Gbpsクラスでの実験・実装が安定して行えるのがP4の美点であるが、それを示せた計測実験となった。むしろ性能を出すのが難しかったのは両エンドに設置したLinux PCによるクライアントとサーバのプログラミングだった。そしてBMv2で動作していたプログラムがTofinoではマトモに動かない、という、やはりハードウェア・プログラミング「あるある」事例の洗礼を受けたのも良い経験になっただろう。多方面で（本人にとって）新しいことに取り組み、進めていった努力には拍手を贈る。なおここでも何年も前に用意したShifted bin counterを初めて卒業研究で使う機会となった。使ってくれたことに感謝する。
   
2. 携帯アプリの通信量を可視化する試み（東構利樹・片山裕斗） [ summary ]
   
   
   一般にユーザは使おうとしている携帯アプリがどのような操作でどれだけのデータを使用するか把握していない。またうっかり毎月の上限データ使用量を超えたとき、過去においてどのような利用がデータ量を多く使 ったのか調べたいとしても、その方法はない。そこでこの研究では、リアルタイムでのトラフィック可視化をスピードメーターと棒グラフで行い、過去のトラフィック量と、そのときどきのスクリーンショットを表示するものを作成した。15人の被験者に操作体験させ、ヒアリングを行っている。
   == note
   当初はリアルタイム表示だけを検討していたが、早期に試した被験者の意見から、過去の操作とトラフィックの関係が見られる事の価値を認識して、それを実現するシステム作成に至ったことは重要な体験だった。基礎実験によって操作によるトラフィック量が3-4桁ほども違うことを明らかにするところから始め、携帯画面のミラリングとその数秒間隔の記録など、様々な作業を一つずつ実現した。ただ過去の操作状況を見る仕組みはシステム化できず、手作業の動画編集となったが、実装能力が高くないなかでともかく被験者を立てて体験させられるところまでたどり着いたことは評価したい。なお計測には舩の研究のために用意したが結局使われなかったVPNを用いたトラフィックモニタリング機構が遂に活用された。
   
3. P4によるパケットブローカーの試作（細見勇介・千原優希） [ summary ]
   
   
   本研究ではパケットブローカーを題材として、P4 による各種機能の実装を試みた。システム全体はGUIによる構成ファイル作成部分と、それに従ってP4スイッチに適切なテーブル・エントリを設定するコントローラ部分の二つに分かれている。GUIはPHP+MySQL、コントローラはP4Runtime Shell (Python) と、Mininet上のBMv2環境で実装した。実装した機能はポートベースVLAN、レプリケーションと、フィルタリング（但しGUIなし）の三つである。
   == note
   年度当初から時間を掛けて細見が取り組んでいたパケット・ブローカーのシステムに、後から千原がGUI部分を追加した形になっている。細見はネットワークにもプログラミングにも慣れない状況から、よく時間を掛けて作業した。指導では複数テーブルを連携させたマッチングや、ワイルドカードの実現方法などについて構造的なことを説明しただけでコードを提示することはなかった。それでも最終的には実現したいパケット処理について、妥当な提案と議論を繰り返しながら自分で設計・実装できるようになったことには拍手を贈る。GUI部分は本来、ラック内でのテストベッド的な利用を想定した複数構成の切り替えやバージョン管理を重視したものにしたかったが到達せず、単に構成情報を入力するだけ（それもフィルタ機構は間に合わず）になった。
   
4. 循環的複雑度を用いたプログラム開発支援システムの試作 - .NETコンパイラプラットフォームRoslynの応用 -（山内龍我） [ summary ]
   
   
   提案するシステムは、リファクタリング作業あるいはプログラム開発時にプログラムの複雑度が上がらないよう誘導するレポートを、作業している VS Code エディタの画面上に動的に提示するものである。現時点では指標を循環性複雑度、対応言語をC#として作られているが、システム構造としてはそれらは差し替え可能である。
   == note
   長く続けた開発系業務体験（アルバイトだが社員と変わらない）に基づいて、当初から開発支援、特にリファクタリングに役立つ方法を探していた。最終的に動的にコード解析を行い、指標として出した数値に基づく指摘レポートを（サジェスチョンとして）VS Codeにリアルタイムに表示する形になった。VS Codeが標準的に持つ文法的なエラーや警告を画面上に出す仕組みを拡張する形で実装している。卒業研究としては実装主体、それも余りドキュメントが無いなかを手探りで進むような形になった。表から見えないところで多くの作業を行ったことは評価する。
   

第19期（2023年度卒業）

1. USB Type-Cケーブルの機能の判別との情報のプリント（高弥安） [ summary ]
   
   
   USB Type-Cケーブルはその利便性から多用されているが、データ通信と電力供給の両面で多様な種類があルため、一本のケーブルがさまざまな規格に対応している状況が生まれている。それらの対応情報は主に箱にだけ記載されており、手元のそのケーブルがどのようなプロトコルでどの速度が出せるのか判別することは困難である。そこでケーブルのコネクタに自分にとって重要な規格の対応状況を印刷する。本研究ではまず識別すべき規格の整理を行い、それを容易に判別するための手順及び補助装置と、安定して印刷する手法の確立に進んだ。 == note
   当初からシステム開発などでなくデザイン・制作系を志望していたため、それに合わせて手を動かすものを題材として指導した。発表ではまるでハンダづけとレーザカッターなどで装置を作ったくらいにしか見えていないが、実際にはかなり広範囲にパッケージの表記とケーブルの結線と実際の動作の比較を行い、これはもう自前でマーキングする他ないと言える結果を出している。例えばThunderboltケーブルとして使えるのに対応情報になく、コネクタにロゴも無いケーブル、充電専用と書かれているがそうではなかったケーブルなどがあった。本人が本来やるべきだった結線チェッカーによる情報提示の方法やロゴマークの検討など、本来そこにデザイン仕事があると思える部分にあまり注力できなかったのは惜しいが、あまりにも複雑な規格の理解、多くのツール・機材を使って対応規格を整理した作業、半田付け作業などを通じて情報系学生が作ったものと言える結果までは到達できており、そこは評価したい。
   
2. トラフィックジェネレータのパケット送信間隔の安定性評価 〜帯域指定による送信間隔の分布を比較する手法の提案〜（久枝美優） [ summary ]
   
   
   トラフィックジェネレータは多くの場合、1Gbpsなどと送出するストリームの帯域指定ができる。IXIAやSpirentなどのハードウェアベースの製品が数ナノ秒程度の精度を持って一定の間隔でパケットを送出していることは第10期の土屋の研究などから容易に想像がつくが、ソフトフェアベース、つまりTSSで動くカーネルがどれだけの精度で一定間隔の送出を維持しているかは明らかでない。そこでこの年度はそこに注目して複数人でそれぞれ取り組むことにした。もっとも荒れるであろうターゲットとしてiperfが考えられ、これを相手に「荒れ具合い」を可視化・定量化する方法を模索したのがこの研究である。最終的に一つの方法を提案できた。
   == note
   プログラミングやデータ操作が得意でなく、データ群を前にその傾向を調べる、といったことがあまりうまくできない状態で、根気よく取り組み、さまざまな問題が未整理のまま残ったとはいえ、一つの提案にたどり着けたことは良かった。実験は全て100GインタフェイスがついたLinuxマシンを使ったが、計測はtcpdumpであり相当に精度が低い。ただ計測帯域がかなり低速なので結果には大きな影響は無いだろう。元々は100GインタフェイスのP4スイッチを使ったデータを使う予定で本人は最初P4のプログラムを試して貰っていたが、そこまで到達できなかった。
   
3. トラフィックジェネレータのパケット送信間隔の安定性評価 〜P4とDPDKを用いたパケット送信間隔計測システムの設計と実装〜（吉田拓翔） [ summary ]
   
   
   久枝の研究と外枠は同じ。ただしターゲットはTRexであり、より高い計測精度を求めてP4スイッチのタイムスタンプ機能を使った。その上で安定性評価手法そのものは久枝の提案手法を使っており、作業のほとんどはP4スイッチ自体の安定性、タイムスタンプそのものの精度、大量データの送信間隔変化の可視化といった、実務的なものになった。しかしTRexでもそれほど安定しているわけではなく、ある帯域を境にその前後でかなり異なる変則的な動きをすることを発見できた。
   == note
   手探りで作業することに慣れていなかったようで、明確な結果が出ない状態で素早く試行錯誤することができず苦労した。本来はもっと多くのことを調べて、成果として出せるはずだったように思える意味で幾らか残念ではある。本来は当人がやる予定ではなかったTRexそのものの調査などが急に自分に回ってきた事も作業の進みが遅くなった原因ではある。ただ、最終的に結果として出した「ある帯域を境に激しく送信パターンが変わる」ことは当人が工夫して作った、帯域を自動的に少しずつ変化させながらモニタ結果を蓄積するシステムによるものである。論文には出せていないが、Tofinoから一度出たパケットをもう一度別ポートに入れて出す（二度タイムスタンプを打つ）ことで、Tofino自体のタイムスタンプ精度について数ナノ秒であることも調べている。もう少しできることが多かったと思うと幾らか残念である。
   
4. P4 Smart NIC による VPN オフローディングの設計と実装（大浦丈晃） [ summary ]
   
   
   P4 SmartNICを用いて、ホストCPUのオフローディングを試みたもの。結果としては「最初の試行」として取り上げたVPNのためのヘッダCaps/Encaps処理が実は大したCPU負荷を生じさせておらず、また利用したSmartNICがホストCPUとデータ交換するためには一度VPNを通す必要があるため、オフローディングしたであろう分がVPN処理のオーバヘッドにより相殺されて見えなくなった、という結果にとどまった。作業としてはおおよそ正しく出来ており、数字が出なかったことは惜しかった。
   == note
   別の研究室に配属されたが、ネットワーク関係のことがやりたいために当研究室で機材提供と助言を行うことになった。4月からPNAについて調べ始め、BMv2でPNAを模したSoftwareNICを作った。これはSmartNIC上でのデバッグが困難であることを見越し、また実際にIntel P4 SuiteとSilicom N5014が手に入るかどうか際どいところで、最悪Tofinoでオフロード処理が動かせるように、という安全ネットでもあった。あちこちで機材が揃わず作業遂行がスムーズに行かなかったことは申し訳なかったが、アーリーアダプタである以上仕方がない面もある。それでもP4 User会で途中経過を発表できたことは（内容には誤謬が混じったものになったが）良かった。かなり早期に「成果が出なかった」内容で一旦カットオフして配属研究室の指導教員のAcceptを貰い、そこからオフローディング成果が出しやすいはずの開発に進むなり、成果が出なかった原因（VPNオーバヘッド）を調べるなり取り除いたテストをするなり、もう少し前進したいところだった。