Poderosa で Cygwin 起動

お久しぶりです。P2P 関連、全然やってないです。キャッホーイ。

閑話休題。
仕事で Poderosa を使い始めたら結構便利だと気づいた。top コマンドで画面が
崩れるので、そのあたりは Putty とかのほうがべんりだけど。でもタブで複数枚
開けるのは便利だ。
Poderosa は Cygwin も開けるんだけど、家の PC だとなぜか起動できなかった。
で、調べた結果、Cygwin のルートディレクトリが取得できなかった模様。
家の PC を Windows7 x64 に変えたせいと思われる。
通常、HKEY_CURRENT_USER\Software\Cygwin\setup に rootdir があるはずなのだが
x64 だと HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Cygwin\setup
に書かれるようだ。
方法は２つで、Poderosa にパッチをあてるか、前者のキーを自前でつくるか。
パッチあてはコンパイル環境がないと面倒なのでキーを自前で作成。
regedit.exe で HKEY_CURRENT_USER\Software\Cygwin\setup を開き、
rootdir というキー名で文字列を作成。あとは Cygwin のルートを書くだけ。
これできどうできるようになった。
最新の Cygwin は UTF-8 になったため、普通のコマンドプロンプトだと文字が
化けて面倒だったが Poderosa なら Cygwin を UTF-8 で開くオプションがあるので
とても便利だー。

Windows で Java プロセスの全スレッドのスタックトレースをとる

メモ。

jstat の解説。さすが櫻庭さん、わかりやすい。
SendSignal.exe を使った方法。

Version0.9.2 が出た

4/18 に 0.9.1 がリリースされていたので本当なら触っておかないといけなかった
んだけど仕事があってほったらかしに。
そうこうしているうちに、英語のメーリングリストでの指摘から Chord の実装で
最善ではない次ホップを選んでしまう場合があるバグがあったとのこと。
そのことプラス、スレッドプールについて洞察が深まったとのこと。
この２つが組み合わさっての 0.9.2 となった模様。

0.9.1 を見ていないので、本当はそちらでの修正だったのかもしれないけれど、
0.9 から 0.9.2 への変更でいくつかメソッドが修正になっていた。

(1)DHT.setTTLForPut の引数が long から int をとるようになった。
(2)AbstractMessagingProvider から Executors がなくなった。
(3)インターフェイス DHT から高レベルサービス（DHT の本質ではない、
　主に情報取得系のメソッド類）がインターフェイス ow.util.HighLevelService として分離。
(4)HighLevelService.getRoutingTableString が int 型の詳細レベルを
　引数として取るようになった。
　これは最終的には IDAddressPair の出力形式の指定となる。
　詳細レベルが 0 未満の場合、ID は 2 byte 分しか出力されない。
　詳細レベルが 0 未満の場合、InetMessagingAddress のポート出力は省略される。
(5)DHT.getLastRoutingResult が HighLevelService..getLastRoutingResults に変更。
　戻り値が RoutingResult の配列に変更。
(6)DHT.getLastKeyString が HighLevelService..getLastKeys として ID[] を返すように変更。

まだ変更はあるかも。
残念ながら、ow.messaging.tcp パッケージはスレッドプールを使うようには変更
されなかった模様。このあたりは根本的に直さないとダメかなぁ。

首藤さんが Windows で全スレッドのダンプを取るため苦戦している模様。
jps + jstack（日本語 Doc を見ると印刷すると書かれてるけどたぶん誤訳で、単純に表示するだけのはず）
とか jconsole とかでダメなのかな。

のんびりした結果がこれだよ！

あちゃ～、syuu1228さんからトラックバックもらっちゃった…。
１年以上前からやってたのに追い越されたって、どんだけウサギ（でもないけど）の昼寝が長すぎんだよオイ。
仕事で手一杯だけど、そろそろ本格的に再始動しなければ…。

自ノードのアドレス設定を行うと selfID が変更される

ちょっと困ったことになった。
ネットワークカードにグローバルアドレスが割り振られている場合、つまり NAT 環境
でない場合は問題にならないが、NAT 環境だと問題が出る。まあ無視すればいい問題
でもあるのだが…。

NAT 環境の場合、DHTConfiguration.setSelfAddress には INADDR_ANY か、もしくは
NIC に割り当てられたアドレスを指定する必要がある（これは bind を行う際に
このアドレスが使用されるため）。
しかしこのアドレスは他ノードへのメッセージに送信元情報として付与される。
となると当然ながら　INADDR_ANY やらプライベートアドレスをいつまでも設定して
おくわけにはいかない。
そこで何とかしてグローバルアドレスを手に入れて、MessageReceiver.setSelfAddress
を呼ぶ必要がある。しかしこれを呼んだ場合、selfID が変更されてしまう。
これは IterativeRoutingDriver, RecursiveRoutingDriver の親である
AbstractRoutingDriver の getSelfIDAddressPair が、現在 RoutingDriver
が知っているアドレスと MessageReceiver のアドレスが異なっていた場合、
IDAddressPair.setAddressAndRecalculateID を呼んでアドレスと ID の両方
を変更するためにおこる。
最終的にはアドレスのハッシュ値を取り、それを SHA1 に通して ID にする。
ID なんて勝手に割り振ってくれればいいや、という場合には問題にならないが、
変更してほしくないときには回避不能の大問題となる。IterativeRoutingDriver, RecursiveRoutingDriver
は final クラスだからメソッドのオーバーライドもできないし。
ソースを改変するしかないのかなぁ…。

OutOfMemory のデバッグ完了

http://cid-7862a61060e90b1f.skydrive.live.com/browse.aspx/NicoCacheWithOverlayWeaver?view=details

OutOfMemory の原因は、他ノードへのキャッシュ要求をかけた際の返答を受け取る
TaskGet がハッシュ表に残ってしまうせいだった。本来なら返答を受けたらすぐに
ハッシュ表から削除するはずが、削除されていなかった。基本的なミス。
デバッグには JDK6 update 10 から標準添付された Java VisualVM を使った。
本当に便利だ、このツール。ヒープダンプすればどこがメモリを一番食ってるか
一目瞭然。もちろん対象インスタンスをどのクラスが保持しているかも分かる。
これはお勧め。ただこれを使うと RMI のあたりでログが出まくるので、なんらか
の方法で抑止しないとログが流れちゃうなぁ…。

デバッグ中

http://cid-7862a61060e90b1f.skydrive.live.com/browse.aspx/NicoCacheWithOverlayWeaver?view=details

ある程度動くようになってきた。他ノードからキャッシュを受け取れるように
なったので、そこを中心にデバッグ中。
ファイルサイズの大きい動画だと OutOfMemory 例外が出てしまうようなので
調査中。
あと、サーバからのレスポンスヘッダがどうしても必要だとわかったため、そこ
のコードを追加した。毎回サーバに HEAD メソッドで問い合わせてしまうと
サーバ負荷の低減にならないが、偽のヘッダを返すようにしてしまうと、いざ
新しいレスポンスヘッダが必要なときに困ってしまう。
仕方がないので、一度 HEAD メソッドでレスポンスヘッダをもらい、それを
キャッシュして使いまわすようにした。あまり性質はよくないが、ここまで
が限界かと。一応、キャッシュすると「nicocache_nl_ow_response_header.txt」
というファイル名でカレントディレクトリにファイルを作るようにした。
これを削除すれば再起動せずとも HEAD を再発行するようしたので、必要で
あれば削除して、レスポンスヘッダを再取得するという形で納得することにした。

バイパスを作るには

プロキシ側と OW 側をどうつなぐか、ある程度プログラムを作ったのでデバッグ
してないけどアップ。

http://cid-7862a61060e90b1f.skydrive.live.com/browse.aspx/NicoCacheWithOverlayWeaver?view=details

つなぐ際に以下を目的とした。

(1)プロキシ側の書き換えを最小限に。
(2)OW から得たキャッシュをローカルに保存できるように。
(3)なんらかの理由で OW から得られなかった場合、通常の HTTP へ fall back する。

これらを満たすとなると取れる方法は限られる。結局、HttpURLConnection
を継承したクラスを作ることにした。内部で OW 側からキャッシュを取得し、
もし失敗した場合には従来の HttpURLConnection インスタンスをそのまま
呼び出して fall back する。
組み込み先は dareka.processor.URLResource の transferTo メソッド。

キャリアグレードNATになると

最近 IPv4 アドレスの枯渇への対策でキャリアグレード NAT が騒がしいが、
もし導入したとすると面倒ごとがおきるかも。
掲示板で犯罪予告が起きた場合、IP アドレスだけでは追跡しづらくなるんだろうな、と。
NAT なのでポート番号と組にしないと誰が利用しているかまではわからないんだよね？
掲示板側はポート番号もログに取るように修正する必要があるんだろうな。
ISP 側はもっとつらそうだ。今までは誰に IP アドレスを貸与したか、誰が返却（
もしくは expire したか）をログに取っていた（もちろんそれ以外にもログを取っているだろうが）のが、
今後はグローバルアドレスのどこのポート番号は誰が使ったかのログまで取るのか。
ログの量がすごそうだ。

さらにデバッグ（キャッシュ断片の送受信部分）

http://cid-7862a61060e90b1f.skydrive.live.com/browse.aspx/NicoCacheWithOverlayWeaver?view=details
一応、sm???? を指定するとそのファイルの断片を送受信するところまでは
デバッグした。
あとは全ての断片を取り寄せてそれをプロキシ側に渡すバイパスを作る部分。