あちい。 ちょっと暑いが、このくらいの気温のまま夏が終わればいいのに。
土曜日は寝て本読んでごろごろしてたら一日終わった。あったかくて雨降ってたら最高の寝日和なので仕方ない。
日曜日はPeerCastStationをいじってたら一日終わった。久々に長時間の作業もいいものだ。なんか無駄な作業ばっかりしてた気はするが。
モニターの位置が低いかなぁと常々思ってたので、モニターの下にダンボール箱を敷いて10cm程上げた。座椅子を使った時に丁度よい位置になってくれたのでしばらくこれで様子を見よう。箱潰れないといいけど。
RubyKaigi2013のタイムテーブルが発表されてたのに気付いた。
Super Earlybirdとかいってチケット割引きされてた時にはタイムテーブルが全く発表されておらず、何をするのかわからない謎の会に2万円もつっこめるかよ……と思ってたんだけどEarlybirdになってしばらくした今になって発表されてたのに気付いた。いつ発表されてたんだろうな。
RubyKaigiはblog(英語)と日記(日本語)があって、日記は国内の地域Ruby会議告知用でblogはRubyKaigi2013告知用っぽいんだが、bingでRubyKaigiを検索しても先に日記が出てきたりするんでせめて日記からblogとかRubyKaigi2013のページに行けるようにならんのかなぁ。
タイムテーブル発表の告知はblogにもなくてどこで告知してたんだろうこれ。 RubyKaigi2013は情報が手に入れづらい気がするわ。
タイムテーブル見る感じだとちゃんと技術的なセッションがほとんどっぽいので楽しそうだ。 技術的な物が少なくて自己啓発セミナーか何かかと思うような内容の勉強会とかあるもんな……。
RubyJSとかWebrubyとかいうJavaScript上でRubyを動かすぜってのが2つもあってちょっと笑った。しかもどっちも俺がちょっと触ったOpalとは別なんだよなこれ。WebrubyはOpenGL ES2.0のバインディングでゲームがどうこうとか書いてあって俺のやってることと被ってるな。OpenGLES2.0バインディングってかたぶんWebGLだと思うけど。
調べたらRubyJSはRubyっぽく書くJavaScriptなのかな？すげー微妙。 WebrubyはEmscriptenでJavaScript化したmrubyか。なるほどその手があるか。
Earlybirdは27800円でちょっと高いけど出せる額だしこの内容なら行こうかなーと思ったんだけど、日付が木金土だった。あれー、前回までみたいに金土日だと思ってたのに平日かー。 暇なら仕事休んで行ってたんだが次の週が締めの仕事があるんで平日は厳しいな。むむむ、Ustream配信とかあれば会社で見るだけになるかなぁ。
リレー要求が来た時にすでにリレーがいっぱいだったらリレー不可なノードを切って新しい接続を優先させちゃう機能を実装した。
何も考えずに切るのは簡単なんだけど、できればもう少し優しく切りたい。 具体的には切るノードにこっちにつないだらいかがですかリストを送ってから切ってあげたいところ。 しかしリレーできてるところに唐突にノード情報送っていいものだろうか。リレーいっぱいだからこっちにつないでねというパターンと同じだから大丈夫だと思うんだが、PeerCastは想定してないパケットを送るといきなり切ったりするので気をつけないといけない。どっちにしろ切るからいいような気もするが。
PeerCastのソースを見る限りではPCP_HOSTをおもむろに送りつけてもちゃんと受け取ってくれそうなので試してみたが……あれーなんか切れてるー。 どうもPCP_HOSTからPCP_QUITまでをちゃんと受け取って切れる(正常動作してる)ときと、受け取りきれずにタイムアウトして切ってしまう場合があるようだ。なんでだろ。
いろいろと動作を見てたところ、PeerCastStation側で最後に未送信データを送りつけるところで送信タイムアウトして切ってしまうようだ。でも1MiBとかでも切れてるんですけどなんでー？ローカルマシン内での通信で3秒かけて1MiB送りきれないとかどんだけー。
もっと動作を見てると高ビットレート配信をしばらくリレーしてると送信が詰まってしまっている。下手すると何分もStream.EndWriteが返ってこないとか。しかしWriteTimeoutは3秒にしてるんでタイムアウトするんじゃね？なんで何分も返ってこないの？全然わからん。
全然わからんとしばらく困ってたんだが、WriteTimeoutのドキュメントを見るとBeginWriteでの非同期操作にはタイムアウト適用されないとかなんとか。なんですとー！ひどくね？ 何がひどいってBeginWrite/EndWriteのドキュメントには一切書いてなくてWriteTimeoutにしか書いてないとか。あとBeginWrite/EndWriteをキャンセルする仕組みがないとか。キャンセルはむりやりCloseでぶちきってやるしかないんだろうな。 切断前の未送信データを送りきるところは同期版のWriteでやってるからここだけタイムアウトしてたのか。
タイムアウトしない原因はわかったんだけど、それにしてもローカルマシン内の通信遅すぎじゃね。思い当たる節があったので、PeerCastのソースを見ると1パケット処理する度に10ms待ったり受信処理に行ってた。そりゃ遅いよ。しかし10ms寝るところを1msにしてみたが変わらんなー。 というか、実は送信先がPeerCastStationでも詰まることがわかった。あれ、受信側の問題じゃない？PeerCastは無実だった？
そのあともいろいろと実験して、まあなんとなく受信側の問題っぽいなぁと検討をつけた。まずPeerCastStationでなんでそんなに受信が遅いのか調べるか。
予想としてはPeerCastと同じように無駄に寝てるところがあるんじゃないかと思ったが、まああった。あったもののPeerCastほど寝てるわけじゃないな。そもそも1パケット処理する毎に寝てたりしなければ大丈夫なはずなんだが……って1パケット処理したらいちいち受信ループに戻ってるじゃん！受信済みバッファに未処理のパケット残ってるんだから処理しましょうよー。
ということで未処理パケットは全部一気に処理するようにしたらちゃんと高速で受信してくれるようになってめでたしめでたし。 たぶんPeerCastも同じような感じでつまってるんだろうなぁ。PeerCastの方はどうしようもないから、送信側の問題でなければまあいいか。
タイムアウトも簡単ながら実装してちゃんと動いてるようなんで大丈夫だろう。 とりあえずリレーの自動管理は予定通りの機能で実装できたはず。ドキュメントにも書かないといけないけど、簡単に説明するのって難しいな。