ネットワーク上のキー検索シミュレーション。サンプル５０と３００で試した。サンプル５０では１５番の個体から、サンプル３００では１５０番の個体から、それぞれ０番を検索する様子のシミュレーションとなっています。緑文字は拡散キーを表し、青文字は検索キーを表しています。緑文字は、前回と同様、例「o1s0t20」の場合１ステップ移動、もしくは、２０秒たつと消滅することを表し、s0はキー発行元を表しています。
シミュレーションでの、青文字の検索キーと緑文字の拡散キーの違いは複数の同じステップ数が同時に存在するか、しないかです。青文字の検索キーは探索経路順にステップ数が１０、９、８・・・という風にカウントダウンして、拡散キーを検索している様子が見て取れます。一方緑文字の拡散キーは、同時に複数先に拡散されるので複数のステップ数が同時に存在しています。消滅時間を短くしてステップ数を長くするとよい結果が得られました。
clover_v34_キーの検索前.zip
clover_v35_キーの検索前.zip
clover_v36_CASHLIST構造体変更前.zip
clover_v37_構造体変更.zip
clover_v38_構造体変更_.zip
clover_v39_PACK型追加後.zip
clover_v40_検索キー導入途中.zip
clover_v41_検索キーグラフィックまで収集機能まだ.zip
clover_v42_検索キーグラフィック.zip
clover_v43_検索キーグラフィック.zip
clover_v44_.zip
clover_v45_動作が重いのを修正.zip
clover_v46_検索find表示みせかけ.zip
clover_v47_検索find表示のみ.zip
clover_v48_SPC配列のoverbufferを修正.zip
clover_v49_検索findまで.zip
clover_v50_.zip
clover_v51_.zip
今回、動作が重くなり処理が変になった。原因はオーバーバッファフローだったのですが・・中々気が付かなくて、時間をくいました。でも、バグを見つけたときは脳汁がでました・・ｗ。現在defineで固定配列を使用していますがポインタ配列に変更しようか考えています。なにしろ、ユーザー１００。IPリスト１００、キー管理（検索、拡散、実体）で１００×３、訪れた先のIPリスト保持・・・。をシミュレーションしようとした際。これだけでもざっと、ユーザー１００×IPリスト１００×キー管理１００ｘ３＝３０万個の情報を扱うことになる。現在ユーザーを３００以上増やすと見慣れないエラーが表示される。恐らく、Cygwin(g++)のコンパイラに構造体、クラスの確保サイズに上限がありそうだ・・？。
シミュレーションで取り扱うユーザー限界数を超えるためには・・ｗポインタ配列に変更するのがいいのかな・・？
シミュレーション関係も残り、リバーシ検索拡散と、BBSの投稿シミュレーションあたりか・・・？大体一区切りがついた感じで個人的には満足しているｗ。今回のP2P掲示板で取り扱うデータはWinnyのようなデカイソフトを取り扱うことを想定していないので、キー拡散＝本体そのものでもいいのかな・・？とも考えています。なにしろ、２ｃｈの１０００レスいったDATファイルの、最大サイズはせいぜい０．５M程度ですから・・。
Winnyだと６４ｋサイズ毎にデータを区切っている。１レス投稿の拡散キーに投稿内容ものっけて拡散しちゃたほうがいいかな・・？とも考えています。その為には、投稿サイズ制限を２０４８バイトとする予定。これは２ｃｈのニュース＋と同じ投稿制限サイズ。その昔・・投稿サイズの制限がない某下水道掲示板で
ジャイアント馬場の等身大画像を張り付けているドアホがいた・・ｗ。回線の細い時代だったので、少しずつ表示される等身大サイズのジャイアント馬場に愕然としましたが・・。おっと・・今回のP2P掲示板では画像のやりとりもやるつもりはないです。新月とかは画像ファイルを取り扱っていますが・・。基本テキストのみを考えています。
PR
リンク