引っ越し先決めた。
駅に近いところか駅からはちょっと離れるけど広いところが候補にあって、どちらも値段はだいたいいっしょだったんだが、やっぱどうせなら広いところいいよねぇというわけで広い方に決めた。駅から離れるといっても徒歩15分程度だし。駅近い方は徒歩2分ほどだったが。
新しい勤務先まではさらに1駅あるんだが、歩いていけそうだと試してみると35分でついた。途中で道間違ってちょっと迷ったんで30分くらいか。普通に歩く距離だなこりゃ。途中にスーパーもゲーセンもあるのはポイント高い。ゲーセンは中見てないけど、普通にビデオゲームもある模様。
あとはせっせと引っ越し作業しないとなー。あーめんどい。
1.9.0をリリースした。UPnP対応だー。
と思ったらバグってて全然機能してなかったので、いろいろ直して1.9.0.1を再リリースした。 動いてるの確認したつもりだったんだが気のせいだったんだろうか……。
Mono.Natを使用してるんだがNatUtility.StartDiscoveryを読んでなくてルータの探索をまったくやってなかったというね。なんで動いたつもりしてたんだろうね。たぶん他のテストプログラムでポート開けたのが残ってて動いたと思ってたんだろう……。
こんな例がある通り、UPnPなんかでのポート開けがちゃんと動いてるか、動いてないならなんでかとか調べるのは大変なので、設定画面にUPnP/NAT-PMPで取得した外部アドレスを表示するようにした。自動ポート開放が有効な場合はUPnP/NAT-PMPでルータからグローバルIPアドレスをもらってきて表示する。ルータがみつからない場合はルーター未発見と表示するのでルータのUPnPが無効になってるのかな？というのがわかるという按配である。ていうかこの機能をつけたら動いてないのがわかったんだけど。
直したのをリリースしようとしたら、アップデート通知がぶっこわれまくってて、アップデート内容の表示がされなかったり、されてもちゃんとフォーマットされなかったりしたのであわててそこも直してリリースしなおした。バグりまくりだよぉ。
次はRTMPでの視聴を実装していきたい。RTMPでの配信はできてるんだけど、視聴はFLVでのプログレッシブダウンロードになってる。まあ見れるんだけど、切れた時にプレイヤー側では切れた部分でループ再生しちゃったり、うまく再接続してくれなかったりと不安定になってしまう。あと視聴時にいちいちダウンロードしてしまうので一時フォルダに巨大なファイルが残ってしまう場合があるようだ。 RTMPでの視聴なら普通にストリーミングなので問題ないはずなんだけど、上手く実装できずに先送りになっていた。
今の接続待ち受け実装だと、リクエストを読み取ってどのチャンネルへのリクエストかを判別できたら、以後その判別できたプロトコルハンドラがやりとりするって形なんだけど、RTMPだとまずハンドシェイクをしないとリクエストがこない。リクエストがこないとどのチャンネルに対するものなのか判別できないので困ったなぁと。HTTPにしてもPCPにしても最初にどのリソースに対してのリクエストかぶん投げてくるからそれ用に作ってたのが仇になった。
そもそもで言うと、1つのポートでHTTPもPCPもRTMPもなんていう接続待ち受けがもうよろしくない。 よろしくないんだが、PeerCast時代から各種ツールがもうそれ前提で作られてるんでどうしようもない。 ない？ないか？なくないんじゃないか？ よく考えるとそんなこともないな……。 ユーザがちょっとツールの設定気をつければ普通に動きそうだわ。 まあユーザに気をつけさせるってのがなにより難しいんで無理なんだけど。
そう考えると、難しくないような気がしてきた。 PCPとHTTPはもう仕方ないので7144ポートで突き通すけど、RTMPはRTMP用のポートで別途待ち受けるようにしたらいいんじゃないだろうか。RTMPのデフォルトのポートは2375だっけ？違うかもしれんけど、まあその辺のポートで勝手に待ち受ければいいのかな……。 アクセス制御とかすごくめんどくさそうな気がするけど。
決め手になりそうな方法は思い付かなかったけど、まあぼちぼちなんか考えて作りましょう。