前回の日記の件、大阪市立大学の研究実施責任者より連絡を頂いた。前回、可能性として、
の3つを挙げたが、(B)であるとのこと。大阪市立大学では、P2Pファイル共有ネットワークにおける検索キーワードの流行が時間的にどう変化するかを統計的に分析する研究を進めていて、統計的推定のためには、データの収集頻度を増やす必要があるということで、クローラをマルチスレッド化する改造を年末に行い、年始より稼働させたとのこと。
今回の結果を招いたことについて、「こういった計測活動は慎重にせざるを得ないにもかかわらず、きちんとケアできていなかったのは指導教員である私のミスであり、その結果、高木さまをはじめ多くの方々をお騒がせしてしまったことは大変申し訳なく思っております。」「今回の状況を真摯に受け止め、今後は社会的影響についても慎重に考えながら研究を進めて参りたいと思います。」とのことだった。
クローラの稼働によって大量の架空ノードが発生したのは、そのクローラが、自ノードポート番号(待ち受け接続用に接続相手に申告する自ノードのポート番号)を通知するにあたり、接続先ごとに別々の番号を用いたためであるが、先方の説明によると、「ポート番号をスレッドごとに別々にする必要があり、スレッドごとにポート番号を変化させた」とのことだった。
これらのことは、前回の日記の図3のグラフから推察できることだった。というのは、大阪市立大学のIPアドレスのノードは、ずっと以前から数千個程度で推移していたからだ。こちらの記録がある限りの期間でそれを示すと、以下の図1のようになる。2009年11月までは、全体のノード数としては無視できる程度のものであったのが、12月の改造以降で影響を及ぼすほどになったことがわかる。
しかし、本来、ポート番号を別々にすることは不必要で、1つのポート番号を用いて目的を達成できるはずである*2。おそらく、研究を実施する学生さんが実験用プログラムを開発する初期の段階で、ポート番号を変える必要があると思い込んでしまったのだろう。先方には、ポート番号を固定にしたクローラの作り方を説明して、今後も研究を継続なさるよう、伝えておこうと思う。
以前から一部の関係者の方々にはお話ししていたが、やはり、「Winny等観測者連絡会」のような枠組みが必要だなと思う。これは勤務先の仕事として関係者の方々に声をかけようと思っているところ。
ところで、今回は不慮の事故であったが、今回の副産物として、従来できなかった実験(やりたくても「人体実験」的であるためにできなかった)に近いことが行われたことになる。つまり、冒頭で示した可能性(C)の実験である。
図1のグラフの集計の際に気づいたが、当該ノードが8万個を超えるようになったとき、ノードの数だけでなく、コマンド4で流れてくる隣接ノード情報のうちに当該ノードが占める割合が、かなりの割合を占めている様子だった。
これを、取り急ぎざっくりと簡便な方法で集計してみたところ、図2のようになった。
橙色のグラフ(下の線)(右軸目盛り)が示すように、Winnyノード間でやりとりされる隣接ノード情報のうち、架空ノードが占める割合が、2割にも達するという事態が生じていた。これによって、通常のWinnyがつながりにくくなっていたことが考えられる。どの程度つながりにくくなっていたかは、記録から何らかの方法で計算できるかもしれない。
中央大学の観測では、観測用クローラの「接続できなかったWinnyノードの比率」が、1月6日から上昇したとの報告が出ている。
また、接続できなかったWinnyノードの比率が上がった。このこともダウンロード違法化による影響か、あるいは巷に言われるダミーキーの放流にともなうダミーノードが増加したことに起因するのではないだろうか。
年末年始のP2P, cNotes: Current Status Notes, 中央大学大学院 理工学研究科 土居研究室, 2010年1月27日
これは、上記の件の影響ではないだろうか*3*4。青のグラフ(上の線)の形状が図2と符合している。16日以降にはもっと上昇していたのではないか。
副産物はもうひとつある。以前から気になっていたように、隣接ノード情報は、消滅した過去のノードがかなり長期間に渡って残留して現れるのではないか、そして、それが(隣接ノード情報を含めた)ノード数観測に影響を及ぼしているのではないかという疑問点があった。今回の事態によって、その影響の推定ができるかもしれない。
図3は、大阪市立大学の今回のクローラが隣接ノード情報に残した架空ノード数の、クローラ稼働終了以降(終了から1日半経過後(の24時間経過後)以降)を拡大したものである。
1月20日14時ごろに稼働が終了し、1日半が経過した後も、このように、これらの架空ノードが隣接ノード情報に現れている。これは、Winny利用者に、ときどき断続的にWinnyを起動する人たちがいて、その人たちが、大阪市立大学のクローラから接続を受けている最中に一旦Winnyを停止し、何日かぶりにWinnyを起動したときに、消滅しているはずの大阪市立大学の架空ノードを隣接ノード情報として周囲に撒いたものと考えられる。
図3の結果から、概ね、1日半経過後で約1%の確率で残存ノードとなること、2日半後で約0.5%となることなどが読み取れられる。これを元に計算すれば、全体のノード数への影響を算出できるかもしれない。
中央大学の観測の続報によると、やはり、接続できなかったWinnyノードの比率はさらに上昇していたとのこと。
*1 4月26日以前は旧観測システムによるもの。現在の観測システムに比べて観測密度が低いため、十分な数を捕捉できていない可能性がある点に注意。
*2 Winnyクローラを実現するには、通常、待ち受け接続を必要としない。クローラ側から接続したソケットがあれば、接続先のWinnyノードはこちら向きにコマンドを送ってくる。非Port0接続で接続した場合に相手方から「BadPort0」確認用の接続が折り返し接続されてくるが、これを処理する必要があるならば、接続を受けてすぐに切断すればよく、そのとき待ち受け用のポートは1つでよい。また、仮に何らかの理由で待ち受け接続が必要だとしても、ポート番号は1つでよいはずで、ノードの区別のためには接続元のIPアドレスを用いればよいはず。
*3 架空ノードの占有率に対して「接続できなかったWinnyノードの比率」の上昇がさほど多くはないのは、接続できない率が元々70%あるから。
*4 私のクローラ(2009年5月以降の新型)では、接続先として、キーに書かれたノードアドレスだけを使用して、隣接ノード情報は無視しているため、接続失敗率に今回の影響が及んでいないので、残念ながら同様のデータが私のところにはない。