教訓: Secure Eraseを行った後はリブートじゃなくて必ず一度、電源を切りましょう！ (そうしないと初期化エラーでBIOSがSSDを認識しない)
X25-MはSSDと判別してくれないという情報がネット上にあがってたけど、
X25-Eは一応、SSDと判別してくれているっぽい？
でも、デフラグは自動で無効になってたんだけど、Superfetchとかは有効のまま。
僕はSuperfetchなどのプリフェッチ技術に対しては肯定派なので
問題ないけどね。別にレガシーな環境でもないし。
東北新幹線は盛岡までちゃんと通ってますよ！というか青森まで通ってますよ！(謎
Wikipedia: 東北新幹線 によると、1982年に盛岡まで開通したらしい。
開通したのって最近だよねとか言ってた人もいたけど･･･
まぁ、僕も関東より南のことは何も知らないので、あまり人のことはいえませんが･･･
openCrypto.NETのCamellia実装と楕円曲線暗号実装がLinuxのx86版Monoで動かない問題であった問題のうち、バグレポートとして報告しておいたCamelliaの方は無事にMono (trunk r134470)で直った。
楕円曲線の方は相変わらずだけど、--optimize=-all なら動作するので、こっちも最適化の問題っぽい。
昨日の続き，KademliaもどきのDHTの実装の問題, 僕のDHT実装の問題の続き
KBRの部分を改良(改悪？）してみた。
ルートとなるノードが見つかったらそこから部分木にかけてキーに近いノードを探すようにしただけ。
以下は簡単なシミュレーションの結果。環境はパケットロス率は0%、IPの配送遅延が20msとなるようにシミュレート。
ランダムなキーを100回問い合わせ、そのときの平均ホップ数(ホップ数と記載)、平均応答時間(時間と記載)、ルートノードが正解である確率(ルートと記載)、複製1が予期するノードに配置される確率(複製1と記載)、複製2が予期するノードに配置される確率(複製2)と記載をまとめた。
- 8192ノード (20ms間隔で1ノードを離脱/参加)
- New KBR: ホップ数=4.76, 時間=914ms, ルート=97%, 複製1=97%, 複製2=95%
- Current KBR: ホップ数=3.19, 時間=385ms, ルート=86%, 複製1=77%, 複製2=45%
- 8192ノード (100ms間隔で1ノードを離脱/参加)
- New KBR: ホップ数=4.52, 時間=727ms, ルート=98%, 複製1=97%, 複製2=93%
- Current KBR: ホップ数=3.28, 時間=388ms, ルート=81%, 複製1=73%, 複製2=46%
- 8192ノード (churnなし)
- New KBR: ホップ数=4.77, 時間=693ms, ルート=99%, 複製1=98%, 複製2=95%
- Current KBR: ホップ数=3.55, 時間=439ms, ルート=93%, 複製1=82%, 複製2=58%
このように、現在のKBRでは二個以上の複製はあまり機能しないように見える。
ただ、新しいKBRの実装が必ずしも優れているというわけではなく、ホップ数は増えるし、
結果が返ってくるまでの時間も二倍程度に伸びている。
うーん･･･どういうKBRの実装を採用すべきなんだろうか･･･
トラフィックについては計測し忘れたので、今度また再測定する予定。
ただし、今日から実家に帰りつつ、就職関係の用事もあるので、続きは月曜日になりそうだけどね。
昨日の続き，KademliaもどきのDHTの実装の問題
これらのメモのまとめ。
まず、上の図のようなネットワークを想定する。ノードは0011, 1000, 1100, 1111の四つがネットワークに参加していて、ノード0011のルーティングテーブルには距離(1000)2以上(10000)2未満として1000の情報が登録されている。このルーティングテーブルの状態は整合性が取れており、なんら問題はない。
そして、ルート候補選出数を2として0101を検索すると、0011が ルートノードとして選出され、ルート候補として、1000が 選び出される。
しかし、実際に候補として相応しいのは 距離が(1101)2となる1000ではなく、距離が(1001)2と(1010)2 となる1100と1111なので、もし0011が離脱した場合 1000に保存されたDHTの複製データには到達することができない。
こうなる可能性は結構低いと思ったんだけど、複製のうち1つが想定するノードに到達するのが大体8割ぐらい？、二つ目は5割未満ぐらいなんで、churnも発生する実環境だと、複製はあまり意味を成さなくなるのかなぁ。実際、先日の数ノード程度の小規模ネットワークのテストでも1ノードが離脱した後にDHTのgetが再putされるまで成功しないという現象が、比較的多く見られたので・・・
授業が18時までだから、結構厳しいぜ･･･というわけで、実家に帰るのは明日の朝に変更っと。
僕のDHT実装のバグについて考えたんだけど、
検索するキーの担当ノードが見つかったら、候補ノードを探すためにまた探索しなくちゃいけない。
おそらく1～3回ぐらいの問い合わせが必要なんだけど、この問い合わせはKBR層でやるべきなのかなぁ。
とか思ったり思わなかったり。
なので、問い合わせのタイムアウトも実装しなくちゃなとか思いつつ、実家に帰るので当分お休みっと。
SimpleRoutingAlgorithm (r2435), SimpleIterativeRouter (r2432)
KademliaっぽいDHTの実装をしたのだけど、先日のテストの時に
ノードが離脱するとDHTのGetがすぐに失敗するという不具合が。一応、複製数3でやってるのに･･･
原因を調べてみたら、ルート候補を取得する部分に問題があった。
ルーティングテーブルには 2^i<=key<2^(i+1) (0<=i<160) の範囲のキーを格納する入れ物があるんだけど
その入れ物には数個のノード情報しか入れないようになっている。
担当ノードを見つける普通のルックアップではこれで十分なんだけど、
担当ノード候補を見つけなければいけないDHTの場合は、これでは必ずしも
検索キーに近いノードから順に選出されるとは限らなくなる。
なぜならルーティングテーブルの入れ物にはその範囲の適当なノードしか入っていないので、
一番近いノードの情報が入れ物に入っていない可能性が十分あり得るからだ。
これを解決するには、Kademlia擬きのアルゴリズムを使っている現状では、
サブツリーに対して検索をかけるしか方法が無いように思える。はぁ･･･
これが所謂範囲検索ってやつに相当するんだろうか？
実装しながらプロトコルに変更を加えたりしていると、
だんだん見づらく･･･そして同じ事をチェックするコードが複数あったり･･･と
なんか統一性が無くなってきた。
プログラミング歴が後数年で二桁に達するのに、僕もまだまだだなぁ･･･
なぜかLinuxのx86版Monoだと下のコードの結果がおかしい･･･これが原因でCamelliaの復号部分のコードが正しく動いていない感じ。
- ソースコードusing System; namespace MonoTest { class TestCase { static void Main (string[] args) { TestCase core = new TestCase (); core.Test (0xffffffff); } int _flag; uint[] _k = new uint[4]; public unsafe TestCase () { _flag = 2; for (int i = 0; i < _k.Length; i++) _k[i] = (uint)i; } public unsafe void Test (uint plain) { fixed (uint* pk = _k) { uint* k = pk + (_flag == 2 ? 2 : 3); uint x = plain; k -= 2; uint y = x & k[1]; Console.WriteLine ("flag = {0}", _flag); Console.WriteLine ("x = {0:x8}, k = {1:x8}", x, k[1]); Console.WriteLine ("result: {0:x8}", y); } } } }
- 正しい結果flag = 2 x = ffffffff, k = 00000001 result: 00000001
- Mono 2.4 (x86, Linux)の結果flag = 2 x = ffffffff, k = 00000001 result: 00000004
楕円曲線暗号が動かない問題は謎･･･
stackallocした変数へのアクセスでなぜかNullReferenceExceptionが発生したり、IndexOutOfRangeExceptionが発生したりする。IndexOutOfRangeExceptionが発生しているんだから、境界をはみ出してアクセスしてるんじゃね？と思うかもしれませんが、stackallocの代わりに new uint[N] のように確保したら例外はおこらない。もちろんほかの部分は変更していない。
なら、stackalloc使わないで普通に配列確保すればいいじゃんって話ですが、何となく僕の方から折れるのはちょっと･･･ぇ
さすがにopenCrypto.NETのソースコードとテストケースと例外の内容をBugzillaにそのまま貼るのは、いざとなると気が引けてきたので、明日1日ぐらいかけて例外が再現する最小のコードを作るかな･･･ちなみに、上記のコードはCamelliaのコードにConsole.WriteLineを追加していって原因箇所を特定後、再現するような最小構成のコードとするまでに1時間ぐらいかかりました orz
僕ってVisualStudioのデバッガに頼りきりだからこういうときにどうすればいいのかよく分からない･･･だめだめだなぁ･･･
土日を利用して田植えのお手伝いへ。
天気も良いし、風も無かったので(夕方からは出てきたけど)、
作業は捗ったけど、体へのダメージが大変なことに。
普段、運動をしないので全身筋肉痛＆日焼け・・・
しかも日焼けに至っては顔や首回りには日焼け止めを塗っていたんだけど、
耳に塗り忘れていたおかげで、水ぶくれが･･･orz
太陽こわいよー
今日は細かいバグつぶし。
きちんと動作ログをとらないと探しづらいなぁ･･･と思いつつも、
めんどくさがって適当にConsole.WriteLineを入れて、画面を見ながら動作チェック(笑
今のところ、KademliaらしいKey-based Routing (KBR) はうまく動いている感じ。
分散ハッシュテーブル(DHT)の実装は、SimpleDHT.cs というファイル名が示すとおりなんか不安定...
匿名双方向通信部も順調かな～
匿名双方向通信路の遅延は、以下の条件の下、平均遅延313ms(標準偏差83.75)、最大遅延923ms
- ノード数: 100
- UDP配送遅延: 最低40ms
- UDP損失率: 5%
- ノードの攪拌: 1秒ごとに1ノード離脱、1ノード参加
- 中継ノード数: 6 (片側3ノードなので両方で6ノード)
- バックアップ経路数: 2
昨日はなんかやる気になれなくてp2pncsには触れなかった分、今日はがんばる！
とりあえず、どこに問題があるか全然特定できないので、ロガーを使ってトレースログを出力するようにしようかな･･･
1KBに余裕で収まったんだけど、動かなくなった･･･orz
デシリアライズでちゃんと元に戻ってくれていないのかな･･･とりあえず、一行でシリアライザを切り替えられるようにしたので、BinaryFormatterのままコミットっと･･･今日はもう帰る。
だんだん双方向匿名通信部が形になってきました。P2Pでサーバレスでいろんなサービスが実現できたらなぁ
しかし、ここに来て大きな問題が！System.Runtime.Serialization.Formatters.Binary.BinaryFormatterを使うと、データサイズが4KBを超える！UDPじゃ転送できない！ orz
今日はきちんと6時に起きられました。おかげさまでもう眠いです！
そして今日、ようやく双方向匿名通信が行えるようになりました。
といってもまだまだ初期段階ですが、なるべく早く完成させたいですね。
Short change logs
- 多重暗号部で始点から終点方向に流れるメッセージのACKにも共通鍵による多重暗号化を適用させた (r2393)
- シミュレーション用の仮想ネットワークにおいて、ポート番号がバインドしているものと異なっていても、IPアドレスさえ一致していれば、データグラムを配送してしまう不具合を修正 (r2394)
- MessagingSocket, VirtualMessagingSocketのコード重複部を分離 (r2395)
- Messagingソケットにおいて、問い合わせを処理する際にはイベントに処理用のメソッドを登録しておく仕組みをとっていたが、ソケットを利用する機能が増えたことにより、イベント方式では無関係な問い合わせを受信しても全てのデリゲートが呼び出されてしまうので、問い合わせオブジェクトの型ごとにハンドラを登録する方式に変更 (r2397)
- DHTの実装を少しまじめなものに。だけどやっつけなので後でまた再設計しなきゃなぁ･･･ (r2399, r2401)
- 双方向匿名通信部の実装を進め、メッセージのやりとりが双方向で行えるようになった (r2403)
Changesets: r2392, r2393, r2394, r2395, r2396, r2397, r2398, r2399, r2400, r2401, r2402
最近、全然朝に起きられません。5/3は起きたら18時でした。
なので実際に活動を開始したのは5/3の22時ごろ。
なので、5/4の日報としちゃいます。
- p2pncs
- 匿名通信路の実装 (50%ぐらいは終わったと信じたい)
- 細かい部分の改良
- openCrypto.NET
- ECDHのインターフェイスの改良
- ECKeyPairクラスに、楕円曲線ドメインパラメータ名 (secp256r1とか)を取得するメソッドを追加
Changesets: r2382, r2383, r2384, r2385, r2386, r2387, r2388, r2389, r2390, r2391
あー、今日はいろいろびっくりだったなぁ･･･もう昨日だけど･･･
今日やったのはこのぐらい。
- TA
- AjaxChat, HttpServerの開発＆初期実装コードをチェックイン
ちょっと脇道にそれちゃったけど、明日はp2pncsの匿名通信部分を作るぞ･･･
電子たばこも“禁煙” きょうからＪＲ北海道
賛否両論らしいですが、個人的には至極妥当なところだと思うなぁ。
紛らわしいから、注意する方もコストが高くなるし
それなら、駅にいる少しの間だけでもおしゃぶりを我慢してもらえればオッケーという思考にたどり着くのは
普通なような･･･注意・監視する方のコストが電車賃に反映されるとみんな困るしね。
というか喫煙者は何で少しの時間、おしゃぶりを我慢できないんだろう？
と思ってしまう、非喫煙者の僕。
まぁ、違法とされているマリファナより中毒性が高いから仕方がないのかな。
今日も16時起き･･･なんか朝起きられない･･･というか、14時間寝るってどうよ･･･
- Audio-technica A2000X の試聴 (後輩から借りた)
- あまりにも不安定なのでサーバのSubVersionのバージョンを1.6.1から1.5.6に戻した
- KBR・DHTの実装