次世代Peercastについての構想、発表配信を見た感想

Peercastのお祭りイベント、キャスケット2012春でやっていた、TP管理人さんの次世代Peercastの構想配信について見た感想を書く。
まず内容についてまとめると
・リレー管理のアルゴリズムの話であるということ
・TPさんの卒論テーマ
・「実装は誰かやってくれ!」意訳
・x264対応
・信頼できるノードが配信者の直下に優先的に選ばれるようにするために、ノード情報のデータベースサーバーを建てようと言う話
・↑これは個人的にはよくない方針だと思ってる。管理だるそうという意味で。P2Pの利点が生かせない。あってもいいけど本質的ではない。もともとYP情報はP2Pで流す仕様だったけど現実的ではないということでどこかのサーバー(YP)でC/Sモデルで運用されているのが現行のPeercastらしいので、俺はもう最初に立ち返り、Yellow Pageというサイトがそもそも完全不要なP2Pモデルを目指す方向で良いと思う。ソッチの方が"自由な配信サイト"になりそう。理想郷だ。権利的な意味も込めて。800Gbps/月の転送量になってしまうのは、単にgzip圧縮していなかったらそれをするようにすればおそらく1/10にはなると思うので、80Gbps/月ぐらいには収められるんじゃないかなぁと思ってる。どうなんでしょうね。

YPについては、単に適切なキャッシュさせるだけでものすごい軽くなると思う。言うは易しなので試しにやってみたいと思っている。現状は、apache + mod_php + sqlite構成とかいうわりとものすごいレガシー構成っぽいきがする(実際のところは知らない)。

俺が考えるpeercastのリレー管理の理想モデルは
・ポート未開放でも直下取れる、しかし帯域の大きなノードが来たときはそいつに席を譲って、そいつの下に行くようにする。(そういうのをP2Pのツリーにおいて再帰的に)
・偽の帯域情報撒き散らすノードがあったときの対策はなんかそのへんの論文にいくらでもありそう
・あとは直下のノードにおいてリレー数に偏りがある問題について。直下ノードAは200人ぶらさがってるのに、直下ノードBは20人とかぶらさがってるだけで、このアンバランスさがあるために、直下ノードAが死亡したときに200人が一気に失われて大量バッファになっちゃう問題。これ単に配信者のマシンに、開いてるノードはどこか問い合わせるだけで良いよね。peercastはツリー型のP2Pなので配信者がすべての視聴者のIPアドレスとリレー状態(それぞれのノードが配下に何人ぶら下げてるか)の情報を持ってるので、どこに繋げばいいのかわりと明確に指示出来るのでは。まぁもちろんどこかに偽情報をまき散らすノードいたら崩壊するけど。これも論文の力でなんとか頼む。。
・ただツリー型のせいで、リスナー数が増えてくると配信者のマシンに対する問い合わせだけで、DDosみたいになってるってのがいま問題視されてるんだろうけど(実際にそれが問題になった場面を見たことが無いので、机上の話っぽさはある。俺の観測範囲の問題である可能性は否定できず)

とりあえず例のIRCに入っておいた。まぁ俺は俺でできることをやろうかなと思っている。今俺が考えてるのはとりあえず現状のPeercastはすでに成立してるし、まずは新しいことをする前の土台固めとして、いつでもrevertできるようにと、現状を可能な限り維持するためにYPの高可用性を確立しようと思っていて、VP, CP, KP, いろいろ潰れていったけどYP建設のハードルが高いことによりYP運営者が増えていないという問題があるので、そこを滅茶苦茶ハードルを低くしようかなと。peercast.inはとりあえずYP4Gの再実装の試験場として運用していこうかなと考えてる。