« 2008年1月 | トップページ | 2008年3月 »

2008年2月

2008年2月28日 (木)

Polipoが覗く HTTP/1.1の深淵(?)を UMLGraphで解説してみる

DolipoPolipoが 話題になっているようで。 でもその原理になっている HTTP/1.1の仕組みとかはそれほど理解されてなさそう。 この記事 でも Poor Man's Multiplexingは飛ばしちゃってるし。

ということで、自分の思い出すのと UMLGraphの練習を兼ねて 解説したいと思います。 Sequence図の UMLGraph sourceももれなく公開という大盤振る舞いです (って、だれが喜ぶんだろう)。

HTTP 0.9

まず、HTTPの基本形とは以下のようなかんじです。
Requestがあって Responseがあるという単純なもの。 そして重要なのが transactionごとに TCPを張り直すということ。 これは、HTTP/0.9時代は responseの終わりを TCP Disconnectionで 示すという荒っぽい仕様だったためしかたないっす。

つまり、三つの tranasctionがあったら以下のようになります。

TCPの SYNや FINの時間がもったいないっすね。

HTTP/1.1 の工夫

ということで出てくるのが persistent connectionです。 これは HTTP/1.0では Content-length headerでコンテントの 終わりを明示できるのでできる技です。 HTTP/1.1ではこれが標準になってます:
絵の上からでも短くなったのが分かるでしょう。

さらに、全体の応答時間 (latency) を短くするための 工夫が pipeliningです。

絵ではちとズルをして縦幅を短くしてありますが、 Responseを待ってから次の Requestを 投げるより、Requestを立て続けに投げた方が 全体として時間を無駄にしてないのはイメージできますよね?

あともう一つ、Range Requestの話もしときます。 これは、コンテンツを頭から読み出すんじゃなくて 指定したバイトから指定した長さだけ呼び出すってもの。

たとえば PDF Pluginとかで使われてます。 Web最適された文書の場合、読みたいページに飛んだらそこの 内容だけを読み出すようにして、いらない途中のページの転送時間をかけない。 だから、PDFは Downloadして Helper applicationで読むより、 Pluginで読む方が早いはず。

でも、個人的には昔の Pluginが不安定だったり、 Pluginだと画面が狭くなるので、Helper applicationで呼んでますが。

polipoはこういう技術をバリバリ慎重に使ってる

で、こういう風な工夫がされているのが HTTP/1.1なんだけど、 実のところ積極的には使用されてないような気がします。 調べたわけじゃないので断言できないけど。 少なくとも某社のブラウザとかでは。

なぜかといえばいろいろ実運用上問題があるから。

たとえば典型的な問題に pipeline stallというのがあります。 上の sequece chartでいえば、 Response1 がすごく重い CGIで生成される画像で、 Response2 がちっちゃい静的な画像だったりします。 そうすると、Response1の生成に時間がかかってるせいで、 Response2の画像も画面に表示することができない。 複数 connectionを張っていれば、Response2はサクッと 素早く取り出せたのに。

まあ、そういうしがらみがあって、みんな保守的にやってるのかもしれません。 そこを、polipoは果敢に使える機能は使っちゃってるので いい感じに早くなってるのかも。 そして、そういう問題を回避する know howとかも入ってるんじゃ ないかなあ、って documentも読まずに想像してます。

「polipoのパイプラインについて」(わかつも) によると

polipoはサーバーがパイプラインをサポートしているか慎重に調べ(carefully probes)てからパイプラインを使うぜ
だそうです。ここら辺が肝なんでしょうねえ。

最後に Poor Man's Multiplexing

で、最後に問題の Poor Man's Multiplexingについて説明します。

でもドキュメント見ると polipoの PMMって既定値では offなんですよね。 やっぱり "an intrinsically unreliable technique" (本質的に信頼できない技巧) だからねえ。 ということで PMMは polipoの高速性にはあんまり貢献してないと思うんですが、 乗りかかった船ということで。

最初に、Multiplexingとは何かと言うと、 複数の transactionを順番じゃなくて同時に送っちゃうことです。

本来 Persistent connectionや pipelineを使っても、objectは順番にしか 取り出せないわけです。 で、 pipeline stallとかの問題が起こるわけです。

ちょっと前の (今でも?) お行儀の悪い web browserとかでは、 そこらへんは 複数 connecitionで回避してたわけです。 Operaの connectionの張り方なんてすごかった気がします。 最近はおとなしくなったんでしょうか。

HTTP/1.1 では client ごとに 2本だけの connectionにしとけよ! って 仕様にかかれていて、やっぱりこれを守りつつ multiplexしたい! というと PMMになっちゃったんでしょう。 っていういみでは、Poor Manじゃなくて、規約を守る Nice Man's Multiplexingって気もしますが。

どうやってやるかというと、Pipelining と Range requestを 駆使するんだと思います。多分。実験しないでかいて申し訳ありませんが。

Content{0, 1, 2} を擬似的に同時に取りたい場合、

  1. Content0 を先頭から 1KiB だけ
  2. Content1 を先頭から 1KiB だけ
  3. Content2 を先頭から 1KiB だけ
  4. つぎに Content0 を 1KiB目から 1KiB
  5. 以下続く
って感じに Pipeliningを使ってやるんだと思います。 試してませんが。

まあ、でもこれも Content2が重い CGIだったりすると stallする 可能性は大なので、労多くして益少なし、ってことで offになってるんでしょう。

まとめ

UMLGraphは便利だけど、いまどき PSを吐くので Pngにするのが面倒です。 ここら辺、自動的にやってくれないかなあ。

| | コメント (0) | トラックバック (2)

Leopard (MacOS 10.5.1) の Windows shareの bug回避

MacMiniに Leopardを入れて serverにしようとしたんだけど、 最初から入っている Sambaが腐っていて苦労しちゃいました。

/var/log/samba/log.smbdを覗くと以下のように 10秒ごとに rebootを繰り返していました:

[2008/02/28 01:19:36, 0] /SourceCache/samba/samba-187.1/samba/source/smbd/server.c:main(890)
  smbd version 3.0.25b-apple started.
  Copyright Andrew Tridgell and the Samba Team 1992-2007
[2008/02/28 01:19:36, 0, pid=1346] /SourceCache/samba/samba-187.1/samba/source/lib/charcnv.c:init_iconv(159)
  init_iconv: Conversion from UTF-16LE to 932 not supported
[2008/02/28 01:19:36, 0, pid=1346] /SourceCache/samba/samba-187.1/samba/source/lib/charcnv.c:init_iconv(167)
  init_iconv: Attempting to replace with conversion from UTF-16LE to ASCII
  	      :
[2008/02/28 01:19:36, 1, pid=1346] /SourceCache/samba/samba-187.1/samba/source/lib/util_tdb.c:tdb_log(662)
  tdb(unnamed): tdb_open_ex: spinlocks no longer supported
[2008/02/28 01:19:36, 0, pid=1346] /SourceCache/samba/samba-187.1/samba/source/passdb/secrets.c:secrets_init(67)
  Failed to open /private/var/db/samba/secrets.tdb
[2008/02/28 01:19:36, 0, pid=1346] /SourceCache/samba/samba-187.1/samba/source/smbd/server.c:main(986)
  ERROR: smbd can not open secrets.tdb
[2008/02/28 01:19:46, 0] /SourceCache/samba/samba-187.1/samba/source/smbd/server.c:main(890)
  smbd version 3.0.25b-apple started.
  Copyright Andrew Tridgell and the Samba Team 1992-2007
結論から言うと既知のバグのようです。使えん。 Appleの Discussionによれば /var/db/samba/の 下の *.tdbを消せばいいよう。 へたれなので rmじゃなくて mv *.tdb bak/しましたが、 それでとりあえず動きました。めでたし。

まだ、謎の iconvがらみっぽい文句は吐いてますが、 漢字まじりファイル名も windows から見られてるのでとりあえずよしとしよう。

ちなみに 同じような対処をしてもうまくいかない例もあるよう。 万能の対処法じゃないようです。 俺も今後変にならない用に見張って置かないと。

さらにもひとつちなみに。 上の Appleの掲示板はログのメッセージでググって発見しました。 生のログを載せることで、こうやって googleで症状を共有することも やりやすくなるもんすね。

ということで、俺もlog載せておきました。 だれかの役に立ちますかね。

| | コメント (0) | トラックバック (0)

2008年2月14日 (木)

Panasonic SDR-H18 でとった動画が ffmpegで変換できないわけ

「ffmpeg compileできたけど変換がうまくいかないよう」って書いたけど、原因が分かりました。

本質的には、同じようなのが FAQにのってて、 AC-3って audio codecの decoderが標準では含まれてないからのよう。 分かってしまえば簡単だけど、multimedia関連は MPEG2-TSぐらいしかしらない素人の俺には大変でした。

そもそも俺の VCR、Panasonic SDR-H18で撮った .MODファイルは、音声が AC-3 (aka Dolby Digital or A/52) って やつで encodeされているらしい。

でもってそれを decodeする free software、liba52ってのもあるんだけど、GPLらしい。

ffmpegは LGPLにしておきたいんで、liba52 は linkしないように なってるらしい。 GPLになっても構わん、ってのなら configure に --enable-gpl をつけろ、 ってのは FAQに 書いてあるとおり。

もう、ここらへんいろいろ権利とかごっちゃになっているから、ややこしいすね。 ほかにも Portsfileのままだと mp3 encodingができないので LAMEを入れろとかややこしい。 いろいろ configurationを考えなきゃいけない、 古き良き時代を思い出します。 とりあえず今は眠いんで、明日入れ直します。

でも、LGPLで作ってもそれが GPLを参照するようにしたら、 GPLになっちゃうもんですかねえ。 さらにもとの LGPL libraryを dyanamic linkしてた applicationも、 ソースを公開しなきゃいけなくなっちゃうんでしょうか。 LGPLだと思って使ってたのになんか理不尽ですねえ。 この場合、だれのせいなんでしょうか、って思っちゃう。 ここらへん、パズルになりそうだけど、 やっぱり眠いので夢の中で考えます。

| | コメント (0) | トラックバック (0)

2008年2月13日 (水)

ffmpeg on MacOS X

FFmpegを MacOS Xで MacPortsを使って 入れたよ、という話です。

出来心で、最近買った Videoカメラの動画を変換したくなったので。 こっそりYouTubeに あげたりしたんだけど、実家のPCじゃみられないので、 aviにしたりすればいいのかなあ、と。

ports fileは用意されているので ports installで 頑張ってくれます。でも以下のようなエラーが:

gcc -I"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_multimedia_ffmpeg/work/trunk"/libswscale -I"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_multimedia_ffmpeg/work/trunk"/libavcodec  -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_ISOC9X_SOURCE -I"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_multimedia_ffmpeg/work/trunk" -I"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_multimedia_ffmpeg/work/trunk" -I"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_multimedia_ffmpeg/work/trunk"/libavutil -O2 -DHAVE_LRINTF -I/opt/local/include -no-cpp-precomp -pipe -force_cpusubtype_ALL -Wno-sign-compare -fomit-frame-pointer -g -Wdeclaration-after-statement -Wall -Wno-switch -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wno-pointer-sign -O3  -c -o i386/cavsdsp_mmx.o i386/cavsdsp_mmx.c
i386/cavsdsp_mmx.c: In function 'ff_put_cavs_qpel8_mc01_3dnow':
i386/cavsdsp_mmx.c:447: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
make[1]: *** [i386/cavsdsp_mmx.o] Error 1
あ、一行が長いんで大変っすね。まあ、肝心なのは "GENERAL_REGS" 云々っすから。

これはasm命令で割り当てる registerがないってことらしい。恥ずかしながら GCCの asmはいじったことないのでなおし用もわからない。だいたい、MMXだの 3DNow!だのはいって、最近の x86はわからんし。

こちらによると -mdynamic-no-picをつけるといいよって説もありますが、 PowerPC用optionだし、 shared libraryに向かないって書いてあるんで止しました。

代わりに日和って-disable-mmxです。これを Portsfileにちこっと書いてやり直し。これで無事 compileできました。せっかくの MMXやらを使えないのは悲しいけどねえ。

で、喜び勇んで変換してみると

[1:10]marble:~<109> ffmpeg -i ~/Movies/takesi/PRG00C/MOV002.mpg /tmp/aho.flv
FFmpeg version SVN-r11532, Copyright (c) 2000-2008 Fabrice Bellard, et al.
  configuration: --prefix=/opt/local --prefix=/opt/local --disable-vhook --mandir=/opt/local/share/man --enable-shared --enable-pthreads --disable-mmx
  libavutil version: 49.6.0
  libavcodec version: 51.49.0
  libavformat version: 52.4.0
  libavdevice version: 52.0.0
  built on Feb 13 2008 00:50:33, gcc: 4.0.1 (Apple Computer, Inc. build 5367)
Input #0, mpeg, from '/Users/takesi/Movies/takesi/PRG00C/MOV002.mpg':
  Duration: 00:01:20.5, start: 0.255589, bitrate: 2464 kb/s
    Stream #0.0[0x1e0]: Video: mpeg2video, yuv420p, 704x480 [PAR 8:9 DAR 176:135], 9542 kb/s, 29.97 tb(r)
    Stream #0.1[0x80]: Audio: 0x0000, 48000 Hz, stereo, 256 kb/s
Output #0, flv, to '/tmp/aho.flv':
    Stream #0.0: Video: flv, yuv420p, 704x480 [PAR 8:9 DAR 176:135], q=2-31, 200 kb/s, 29.97 tb(c)
    Stream #0.1: Audio: adpcm_swf, 48000 Hz, stereo, 64 kb/s
Stream mapping:
  Stream #0.0 -> #0.0
  Stream #0.1 -> #0.1
[adpcm_swf @ 0x132a810]Sample rate must be 11025, 22050 or 44100
Error while opening codec for output stream #0.1 - maybe incorrect parameters such as bit_rate, rate, width or height
うーむ、Audio stream の sampling rateがダメだよ、っていってるんですね。そんなの変換してくれないのかよ。

どうもここらへん、multimedia業界の formatってのはよくわかりません。 勝手に変換されるのを気にする風潮とかあるんでしょうか。 もう少し調べてみます。


2008-03-07 (Fri) 追記:
macport でいれるのは以下のコマンドラインでうまくいきました。
sudo port install ffmpeg +gpl +lame +extvorbis +faac +faad +xvid +x264 +a52
ちゃんと SDR-H18でとった AC3 audioも変換できてます。

ffmpeg macports で検索されてきている方も多いので、ここに追記しときます。

| | コメント (1) | トラックバック (1)

2008年2月 8日 (金)

Neo1973購入

OpenMoko用端末 Neo1973を 出来心で買ってしまいました。

これもひとえに hitoriblogさんが GPSで楽しそうに Hackしているせいなのです。 あれをみて、対抗して変な GPSデバイス→ OpenMokoって活性が ながれていったせいです。 Phase 02の ハードウェアが出るまで待っていようと思ったのに。

さっそく電池を入れて立ち上げてみると簡単に kernelは bootします。 が、initを見つけられなくて panicってます。 どうやら rootfsは入っていない模様。

MacOS での焼き方も 乗っているので、とりあえず Flasherのリストに出てきた 20070831 の snapshotをやいてみる。 焼くときにくせがあって、一度つなぎなおして、もう一度 flashボタンを 押さなきゃいけないのにつまずいたけど、 それ以外はサクッとできた。

で、立ち上がった applicationは、まあ、発展途上だなって感じ。 携帯に向いていないUIだし、DPIを考えずに文字とかが細かすぎ。 動きももっさりしてる。

で、iPhoneの SIMをさしてやったけど、肝心の GSMが使えない。 どうも networkを認識してない模様。 同僚の Donは、電話は使えるって逝ってたんだけどなあ。

ということで071121の snapshot imageで再挑戦。 他にも野良ビルドで新しそうな物がいっぱいあったんだけど、 やっぱり openmoko.orgの下のが一番信頼置けそうで。

でもプロジェクト主導を持って daily buildつくってないのはどうかな、 とか NetBSDを見てきたおじさんはちと思います。まいいや。

で、焼き終わって立ち上げてみると.. かなり UIかわってます。

ボタンとかもでかくなって押しやすくなってるし、アイコンも見やすくなった。 センスは相変わらずそんなによくない気がするけど、 かなり変わってます。うーん、さすが OpenSource。

でもやっぱり電話かけられませんでした。 電界強度のの表示は出たんだけどなあ。 しらべてみたい.. けど仕事とやってることが変わらん気がしてきた。

| | コメント (0) | トラックバック (0)

« 2008年1月 | トップページ | 2008年3月 »