くまりゅう日記

もっと過去の日記
[.NET | BeOS | Blender | COLLADA | fossil | mono | monotone | NPR | OpenGL | PeerCastStation | Riko | Ruby | Silverlight | TRPG | XNA | ゲーム | ゲーム作り | ]

2012-10-17

日記

涼しくなって朝起きれるようになってきた気がする。 あとはもうちょっと帰る時間を早くできるといいんだが。

[PeerCastStation] 謎のリレー詰まり

ちょっと前から発生していた謎のリレーできなくなる問題。 送信ビットレートをリアルタイム表示できるようにしたので配信で試してみてたんだが再現した。

思ったとおり送信ビットレートが0kbpsになってて送信ができない状態のようだ。 しかし接続要求が来てない時も0kbpsのままで、接続要求がくると送信がなぜかブロックしてしまうのではないかというのは違うっぽい。

一旦リレーが切れても再度接続されると同じ状況なのでチャンネルの状態が悪そうな感じがする。少なくともPCPOutputStream単体の問題ではない。

ローカルで視聴するのは問題なくできるので、リレーのみおかしいのかローカルだと問題ないかのどっちかだな。ローカルのリレーはすぐ試せなかったんだがまた今度起きたら試してみよう。その前に直せれば一番いいんだが。

ある程度配信してないと現象が出ないようなのでプロバイダにひっそり帯域制限かけられてんじゃないかとも思ったが、以前同じ問題が出た場合は一旦チャンネルを止めて再度建てると上手くいった覚えもあるな。だとするとやはりPeerCastStation内部の話だろうな。そもそも1時間半で500MBくらい送信した程度で制限かけられたのではたまったものではない。

大量のリレー要求が来たときにすぐ同じような状況になった覚えがあったので100クライアント程一気に立ち上げてリレー要求してみたが、それぞれがリレーできる設定になってなかったので結局2本程しかリレーできずじまいだった。ダミークライアント自身もリレーできるはずなんだがなんでできてないんだろ。あとで調べとこ。

そんなわけで原因は未だわからず。なんとかしてすぐ再現できるようになると調べやすいんだが……。

調べてた問題とは別だが、ログを見てたらリレーできないはずのクライアントにもちょっとデータ送信しちゃってるっぽいのを発見した。確かにそんな状況あるんじゃないかと思ってはいたが本当にやっていたとは。

ソースを見てみたら、リレーいっぱいの場合はハンドシェイクの返事が来たら次に接続すべきノード情報を送って接続終了しようとするんだが、ノード情報を送ってから接続終了処理をする間にコンテンツ送信を通ってしまっていた。コンテンツ送信はリレーいっぱいの場合は絶対しないようにしておけばいいか。

はいはいこれで直ったわーと思ったが……むむむ、直してから気付いたがこれって結構重大なバグじゃないか?一気に10本とかリレー要求くると既にリレーいっぱいなのに間違って保持してるコンテンツ全部(おそらく数百KiB~数MiBにもなる)を送ろうとする。うちはADSLerなもんでそんなに上り帯域ないので送信に時間がかかり、既にリレーしている人への送信も滞る。送りきった時点でリレーいっぱいなので切断するよーと切ってしまい、切られた側はリレーできそうな下流にリレーしてくれーと行くが、既にリレーしている人も受信が滞ったため切れちゃって……。おおっと。崩壊の連鎖が止まりませんな。

これだと確かにローカルでは(充分な帯域があるため)再現できないし、リレー要求が一気に来た場合に起きるんじゃないかという観察にも一致するな。送信ビットレートが0kbpsというのは、送信が完了した時点で初めて計量してるのででかいデータ送信中は0になってしまう。ということはこの修正で謎のリレー詰まりが直ってくれるかも?ま、ローカルで再現できないんで実際自分で使って様子見るしかねぇな。

これうちが光マンで充分帯域があったら気づかずにいた可能性あるなぁ。それにしてもずっと前からあった問題のはずなのに、最近になって現象が顕著になったってのは気になるな。まあ確かに以前からリレー崩壊の復旧はなんか遅いなーとは思っていたが。


ページのトップへ | トップ «前の日記(2012-10-13) 最新 次の日記(2012-10-22)» | 編集 | kumaryu.net by kumaryu