日記を書いてないのは作業が進んでいるせいです。
土日月は帰省してネコ充してた。ぬこぬこ。 こっちの顔を見てぶにーとか鳴いてなでろだのブラッシングしろだの要求してきたり、膝の上で小一時間寝てみたりだのいいように使われていた。 幸せである。
兼ねてから考えていたHTML UIなどに認証をつけるのを実装している。
今は何も考えずにWAN側への操作や視聴を許可してしまうと誰でもアクセスし放題で、ひどいとGoogleの検索にまでひっかかったりするようだ。
PeerCastでは外からアクセスするとパスワード入力画面になって、通るとクッキーにセッション情報を設定してそれを参照して表示するかどうか決めてたようだ。 これの困ったところはクッキーだとAPIなんかには適用しづらいことだよな。セッション管理もめんどうだし。
そもそも適当にちょろっと設定したパスワード一つで全世界に公開ってのもこわい。もっと手軽に使えて安全なのがいいなぁ。
SSHみたいに公開鍵認証でログインできるのがいいので、あんまり見かけないHTTPSのクライアント認証をやってみようかと思った。 だがしかし、.NETでHTTPSのサーバを作るのは非常に大変そうだ。 正確にはサーバは簡単に作れるんだが、証明書の管理がしっかりしててシステムにインストールしないといけなかったりとか、 証明書を作ったりはできないなど、脆弱な使い方ができないようになっている。 オレオレ認証局なんてそう簡単に建たせてやらねーぜ！という強い意思を感じる。真っ当な話だが困ったね。 SSH程度の使い方したいだけなんだけどなぁ。
クライアント認証は諦めた。そもそもいじられても危険な物でもないし、そんなに安全じゃなくてもいいか。PeerCastも安全ではなかったしな。
Basic認証を試そう。パスワードが十分長くて複雑ならまだマシだろう。
不安だったのが全ページに認証かけるとパスワード入力画面がでまくるんじゃないかという辺りだけど、OperaとIEで試したところ一旦認証が通ると同じサイトには認証情報を勝手に送ってくれたので問題なかった。APIの方も不安だったけど、JavaScriptからのPOSTにも勝手に認証情報をつけてくれるようで、一旦ページにアクセスできれば認証かかってないのと全く同じに扱えた。よかったよかった。
他のブラウザは試してないけどたぶん大丈夫だろう。
IDとパスワードは自動生成にして長くて複雑なものになるようにした。
手動だとあまりにも適当なパスワード入力しそうだ。
http://hoge:fuga@example.com/形式のIDとパスワードが入ったURLをブックマークしておけば大丈夫だろう、と思いきやIEでは上手く扱ってくれない。
RFCを調べると少なくともパスワードまで入った形式は非推奨になってるようだ。
そりゃまあパスワードまる見えだし推奨はできないけどちょっと困ったね。
まあパスワード管理ソフトかなんか使ってくれればいいんじゃないかな。
lastpassだとBasic認証フォーム埋めてくれたりくれなかったりするけど。
手動設定できるようにしてもいいんだけどね。
IDとパスワードの組をどこに設定できるようにするか悩んだが、べつにどこでもいいのでとりあえずポート毎に一つ設定できるようにしておいた。
とりあえずUIも作ってだいたいできた。ドキュメント書くのがめんどいな。あと使われるかが謎だ。
リレーがループするという報告があった。あー、するわ。
リレーのループというのは上流のノードが下流についてしまうという現象である。 同じ場面が何度も流れてしまうのは関係ない。 同じ場面で死にまくって無限ループって怖いよねになるのはもっと関係ない。
今まで全く考えてなかったので起きるだろうとは思えるが、なんで起きるのかは整理しないとよくわからんな。
整理してみたところ、再接続する時に自分の下流のノードを選択してしまいそこに上手いことつながるとループするという状況が思いついた。他の状況があるかどうかはよくわからない。稀にありそうな気はするが。
PeerCastではどう回避していたのか考えてみたがよくわからない。 下流のノードを選択しないのかと思ったけどそれっぽいコードも見当たらない、というかソースがアレで見つけられない。 単に再接続する時には最上流まで戻ってるだけかもしれない。
下流には接続しないってやるのが簡単かなぁとは思うんだけど、下流と上流の判別が難しい。 接続先選択にはノード情報リストを使うんだけど、ここには上流から貰ってきた次に接続するといいよというノードと、下流から貰ってきた今つながってる下流ノードの情報がいっしょに入ってて、いっしょになるともう区別がつかん。
真っ当なのは次に接続する候補ノードリストと今つながってる下流ノードリストを別に持つことだろうけど、ちょっと大変更になりそうだなぁ。やばい問題なので早めに直したく、なんとか小さい変更で抑えられないかと検討するものの、上手い方法はなさそうだ。観念して別にするか。
いざ作業してみると、あっさりと、いやとても簡単にできた。接続候補ノードリストはPCPSourceStreamしか使ってなかったので、こいつをちょろっと変えてやるだけでよかったようだ。逆に下流ノードリストはPCPOutputStreamしか使ってない……が、表示にも使ってるので、これを何か変えようとするとそこそこ作業は必要かもな。接続候補ノードリストは表示に使ってないのか。ちょっともったいないかも。表示する場所ないけど。
早くリリースしたいところではあるが、不安なので一応手元でちょっと使ってすぐ分かるような問題がないことを確認してからリリースしよう。
しかしこの問題はずいぶん前というか初期からあったと思うんだけど、なんでなかなか見つからなかったのかな。あまりPeCaSt使ってる人いなかったからか。
1.5.0あたりでFLVのH.264配信ができるようになり、配信方法の検証が進んだこともあってFLV配信が微妙に流行してる。 何かいいことあるの？って聞かれるけど俺は知りません。
まあH.264使えば低ビットレートに強そうなイメージがあるのと、x264のエンコードが綺麗なあたりが利点なんじゃないですかね。 個人的にはx264は重いのでAPUなうちのマシンではしんどそうだなぁと思う。VP6(FLV)がエンコ軽いってのと、プログラミング配信なんかだとFlash Screen Video2が良さそうな気がするんだけど、きっと誰も使ってないかな。
PeerCastIM(パッチ未適用)やVPなんかでもFLV配信が見れるという話があったんだが、見れないと思ってたので驚きだ。 HTTPで見に行ってもContent-Typeを吐かないので再生できないと思ってたんだが、どうもプレイヤーでFLVだと判断して再生してくれるらしい。 Ogg/Theoraは自動判別で再生してくれなかったじゃないですか……。
ただPeCaStじゃないとすぐ切れるとかなんとか。ちょっと試してた感じではそんなことはなかったんだけどなんだろう。 パケットサイズでかくなるのかな？と思ったけどそれはもっと前に直したな。15KiB越えてたら分割するようにしたはずだ。 配信が見れないとかならともかく、リレーが切れるのはPeerCastStationの不具合だろうから本当にそうなら直したいところだが調査がなかなか面倒だなぁ。
FLVが思った以上に流行ったので、流行ってるうちに先に進めたいところはあるな。 FLVでめんどいのは視聴と配信だ。
視聴は当然Windowsの標準で再生できないあたりの問題だ。 これはまあどうしようもない。Splitterとデコーダを入れれば再生できるみたいだけど、試したところではすぐ詰まっちゃって安定しないね。 俺は普段OSXでVLC使ってるので普通に見れてるんだけど、WindowsだったらWMPとかDirectShow使ったプレイヤーで見たいだろうしなぁ。 誰かが上手い視聴環境作ってくれることに期待しよう。
配信は直接FLVで配信できるシステムがないので現状なんだかいろいろと面倒なことをやっている。 ffmpeg→HTTPサーバ→PeCaStとかOBS→rtmpdump→HTTPサーバ(?)→PeCaStとかね。 それはさすがに大変すぎるのでPeCaStにRTMPサーバ機能をつけたいなぁ。OBS(やRTMPに配信できるソフト・ハード)→PeCaStで配信できるのが理想。
そのためにRTMP仕様を読んでサーバ書いてみてるけどよくわからんところが多くて難しいな。 ていうか仕様書1.0になって抜けてたところが埋まったと喜んでたんだけど、よく読んだらべつに埋まってなかったぜ。 ‘connect’コマンドのサーバからの返事に入れなきゃいけないデータについて書いてないよ……。
まああとPeerCastStationというかPeerCastからそうだが、サーバからPullしたデータで配信は開始できるんだが、クライアントからPushで配信開始するようになってないのでその仕組みを作るのがすっきり行くか不安だ。単体でRTMPサーバ作れてからする心配だけどな。