kumama go言語とかgolangとかGAEとかネットサービスとかその他色々・・・

13Jun/100

ワンセグを http live streaming して iphone で見る

って、試してるのはipod touch (1st gen)なんだけどw。

iphone 4g買う気でいるのでその準備と言うか。
寝てる部屋でもテレビ見たいというか。

要るもの(ハード):

  • OSX(雪豹が望ましい)
  • Friio等(生TSが抜ける地デジチューナー)

ってここまでで敷居高杉ですが。

要るもの(ソフト):

  • recfriio改
  • tssplitter_lite改
  • mediastreamsegmenter

recfriioは終了まわり、tssplitter_liteはパイプ対応など修正。
mediastreamsegmenterはsnow leopard標準で入ってるコマンド。

iphone側はQuicktime playerで見るので特にソフトは不要です。

あ、あとWebのUIをgolangで作ってて、iphoneからはsafariで操作する感じ。

mediastreamsegmenterはオープンソースのsegmenterでも行けそうなんだけど、
AACとの相性が悪いのか成功せず。
トランスコードしてる訳じゃないので、
これさえ動けばlinuxとかbeagleboardでOKなんだけど。

と、需要あるのかないのかなのでとりあえず。

Filed under: etc, golang No Comments
8May/100

WebSocket Draft76

1周半ぐらい周回遅れですが、WebSocketのDraftが更新されていて76に成っています。
Handshake周りが変わっていて前バージョンとの互換性が実装次第なので注意が必要。

って、WebSocket Draft75 « ケンタテクブロで先を越されてエントリしていませんでしたが一応記事にしておきます。

Filed under: golang No Comments
18Mar/100

websockets を proxy 環境でも利用する場合の注意点

ええとコメント頂いたのでまじめに書くことにします。
(ちょっとアングラな世界でドライバ作ってました)

現在のwebsocketsのクライアント側の実装でproxy越えをしようとする場合、サーバ側で特殊な考慮をしておかないと繋がらない環境が多いと思います。

ちょっとややこしいので順を追って説明します。

・クライアント側の実装でproxy越えする際にはProxyに対し CONNECT を発行する
・proxyでCONNECTできるのは接続先ポートがhttps(443)に制限されている場合が多い
(squidはデフォルト。443以外のSSLポートをSquidでプロキシするには辺り参考)
・一方、サーバ側はというとhttps使ってるならhttpsの場合が多い。
・websocketsで443に繋いだとしてもSSLのハンドシェークは行われない

以上から、proxy経由でのwebsocketsをなるべく利用可能にするならrawな(SSLでない)websocketsの口をポート443であけて置く必要があります。このblogに張ったwebsockets chatはこの対応をやってます。(httpsは潰してますw)

ま、現状の実装(websockets, proxy)での話しなのでこの先は分かりませんが…。

Filed under: golang Continue reading
9Mar/100

golangリリースニュース(w

2010-03-04のリリースで言語仕様に変更が有った模様。
http://go.googlecode.com/hg/doc/devel/release.html

strings.Bytes(x) -> []byte(x)
strings.Runes(x) -> []int(x)

って、結構当たり大きいような。

Filed under: golang Continue reading
4Feb/100

websocketsのpipeline

またもEmerge Technologyからのネタ。
この、websocket pipelineのサンプルが意味するところら辺の話。

# ちなみにHTML5のドラフト上、「websocket」ではなく「websockets」が正解・・・だったと思うw

websocketsの利用シーンとしては現状httpでは出来ないサーバ側からの通知とか、
非同期通信ばかりを思い浮かべていたけど、ajaxで出来る事もwebsockets化する!って
言うのはなんと言うか着眼点が面白いというかちょっと思いつかなかったなぁと言う感じ。

ただ、なんと言うか記事読んでいて思ったのは、
「websockets+pipelineが凄い!」っていう結論に成るような論旨展開に成っているんじゃない?!という事。

pipelineにするとシーケンシャルにしか処理できません。
例えば、1件処理するのに3秒かかるリクエストを3件行うとします。
3並列で実行すれば3秒、シーケンシャルに処理すれば3秒x3=9秒かかるのは当たり前です。
ただ、この話は3並列で処理を実行した場合のオーバーヘッドが0という前提が必要です。

それをふまえ、何故、「websocket+pipeline」のサンプルがajaxでの処理が遅いのか考えてみると、
サーバ側でリクエスト1件に対するオーバーヘッドが大きいからに他成りません。
mod_python使っていても、handlerがpublisherの場合のTPSはそんなに良くないはずです。
またサーバ側のCPUのスレッド数も分かりませんし、
apacheのpreforkがいくつに成っているのかも分かりません。

websockets版はスレッドとしてpython上でread/writeをループしているだけで、
pythonの初期化とかしてないので早くて当たり前ですね。

上記のような事を考察せずNWの遅延とかターンアラウンドの話ばかりを引き合いに出しているあたり、
微妙に突っ込まれる事も有るかも知れません。

その上WebSocketsの方はページを開いたときにコネクションを張ってしまっています。
なんと言うか、インフラとかapacheとかajaxに詳しくない人って印象を受けてしまうのは気のせいでしょうか。

穿って考えると、websocket+pipelineが早い、という事ではなく、
「自分のサーバとかJSだとwebsockets+pipelineの方が早いみたい。」
と、言う話で一般的にAjaxよりもwebsockets+pipelineが早いという話では無いような気がしてきます。

と、色々書きましたがやっぱりWebSocketsは現状httpでは出来ない事を実装するためのものと、
思った方が良いのかも。

http(s)なら今までの資産として、javascriptのライブラリも使えるし、
cookieとか認証とか文字コード変換とかjsonとかproxyでのキャッシュとか
今まで蓄積してきたモノが使えます。

websockets上で独自プロトコル作るのがデファクトとは思えず。

まー、apache + mod_pythonなんてケチな環境じゃなく、
golangで専用プロセス上げてればもうちょっと違う結果になったのかもw

Filed under: etc, golang No Comments