ガルパン劇場版が良すぎて2回も見に行ってしまった。というのを書き忘れてた。べつに一週間で2回行ったわけではない。
ELECOMの新しい人差し指トラックボールが先月出たので買って使ってるんだが、もうTrackman Marbleに身体が調教されきってて乗り換える程でもないかなーと思ってきた。 ホイール付いてても使わなくてボールでスクロールするようになっちゃってるんだが、WheelBallを割り当てた上面のボタンが押しながらボールでスクロールをするのがやりづらい。 ただ、いろいろボタン設定をいじってたら右ボタンをWheelBallに割り当てて、戻る/進むボタンを右/中クリックに割り当てたらちょっといい感じになった。これで様子見よう。
RubyKaigiはいつやってるのかすら失念していた。まとめでも見ておこう。来年は京都でとかいう話だけは聞いた。いいですね京都。
最近WindowsタブレットからOSXの共有ファイルを開こうとするとめっちゃ遅くて困ってた。 1MBもないファイル開くのに15秒もかかるような状態で全然使えん。 OSXのファイル共有ったらもー！って怒ってたんだけど、他にインターネットが重いような気もしてたがこれはISPが詰まり気味かなーと。丁度そんな障害情報出てたし。
で、昼休みに会社のフリーWiFiから家にVPN張ってネット見てたんだけど普通に快適な速度が出てることに気付いた。 あれ、ということは家のWiFiが遅いだけでは……。
というわけでいろいろ試してみたところ、なぜか5GHz帯でつないだ時だけものすごく調子悪いようになってしまったようだ。2.4GHz帯だと問題ない。 ファイル共有が遅いのもそのせい。ごめんよOSX。いつも遅いのは確かだけど我慢できない程遅いのはOSXのせいじゃなかった。
干渉とか調べてみたんだが、5GHz帯はそもそも干渉とかなくて衝突するかしないかくらいみたい。でもルータでチャンネル自動設定にしてるからそう簡単に衝突なんかしないはず。 その辺調べられるソフト教えてもらって見たけど、やっぱり衝突なんか無いし、むしろ2.4GHz帯の方が衝突してるくらいだ。そりゃそうだよなだから5GHz帯使ってたわけだし。
これはタブレットかルータかどっちが悪いのかって話なんだが、BlackBerryも5GHz帯でつないでて問題なく動いてる感じだからやっぱタブレットかなー最近調子悪いからなーこのポンコツめーとか思ったんだが、良く調べてみたらBlackBerryでも5GHzだと調子が悪いことが分かって、ルータが悪そうという結論に。 位置を変えてみたりしたけど変わらんし、そもそも電波強度的には問題ないんだよな。ルータの内部での処理がなんかおかしいっぽい。 とはいえ再起動しても改善してくれないからな……。
で、仕方ないのでルータ新しくするか、ルータのWiFiは切ってアクセスポイント追加でもするかとか考えてたんだが、2.4GHz帯でそんなに困ってないことにさっき気付いたのでしばらく放っておくことにしよう。 買うならそこそこ良いルータ欲しいよねとか思ってお金かかっちゃうもんね……。
PeerCastStationでUPnPとNAT-PMPのポート開けを実装してたんだが、安定版としてリリースしたらエラーで落ちると報告が来てしまった。
UPnPやNAT-PMPでのポート開けにはMono.Natというライブラリを使ってるんだが、どうもそいつの中で落ちてる模様。ログ出すようにして試してもらうと、http://hoge:1900controlpoint的なURLにアクセスしようとして死んでいた。ルータが返してくるコントロールポイントのURLが相対URLで、頭に/もついてない相対パスで書かれているとこうなってしまうようだ。
Mono.NatではURLを組み立てるのに、文字を検索して文字列の一部を切り出してそのまま結合して～的な素朴な文字列操作をやっちゃってるんだけど非常によろしくない。Uriクラスちゃんと活用しなさいよ。URIの操作なんて難しすぎて素人ができるようなもんじゃねぇしさ。
今回は間違ってる場所はわかったのでMono.Natをフォークして相対パスの時はちゃんと/を必要に応じて挟むようにごまかしたやつで解決したんだけど、もっとちゃんとしたやつ使いたいなぁ。
というわけでOpen.Natに乗り換えようとしてみた。こいつはMono.Natから派生はしてるものの今となっては別物なくらいに変わってるやつで積極的にメンテもされてる。
で、使ってみるとなんとも使い勝手が微妙だな。デバイスの探索がAsyncなメソッドなのはいいけどCancellationTokenじゃなくてCancellationTokenSourceを受け取るようになってんのはマナー違反でしょ。なんでかと思ったらいつまで待ち受けるのかのタイムアウトがCancellationTokenSourceのディレイで行うようになってるようだ。なんだその仕様。
微妙だなーと思いつつ使ってみると、なんだかデバイスの探索が全く返ってこない。いやー普通にNAT-PMPなルータあるんだからそいつ返してよーとOpen.NatごとデバッグしてみるとNAT-PMPのあたりで例外で落ちてるようだ。よくソースを見るとNAT-PMPのところ全くめちゃくちゃじゃねーか！なんでリクエスト送信する前に返事受信待ち受けようとしてんだよ！返ってくるわけねーだろ！！ まあOpen.Natのリポジトリ見たらNAT-PMPサポートの削除っていうブランチがあったから嫌な予感はしてたんですけどね。まさか現時点で動いてないとはね。Mono.Natでは動いてるんだけどさぁ。
ちなみにNAT-PMPはAirMacぐらいでしか使われてないんだが、丁度うちのルータがAirMac Extremeなので外すのはちょっとな……といったところ。
Open.Natをいじって使うのはさすがに嫌だなぁと思って諦めたんだが、Mono.Natを自分でメンテするのも嫌だなぁ。ていうかこれくらいだったら自分で作ってもよくね？作れるな。作りたい！作っちゃおう！
というわけで自前のポート開けコードを書き始めてしまった。 とりあえずMono.Natと仕様書を参考にNAT-PMPとUPnPでポート開けるのをRubyで書いてみて上手く動いてそうなところまでいけた。NAT-PMPは超簡単。UPnPはちょっとめんどいけど思ったよりは簡単。 あとはこれC#にして組み込むだけだなー。なんとかなりそうだ。