かつてホームPCかホームサーバか、呼び名は忘れましたが、家電の中心にPCがいて各種家電を制御するような未来図があった気がします。そんな未来図はすっかり影を潜めて、ネットワーク化された家電の中心にはテレビとビデオがいます。もっとも、リビングの中心にはテレビがある、というだけの当り前の話です。そもそも、ホームサーバなどと言っていたのはPC側の人が作っていた話で、テレビをやっていた人は、始めから眼中に無かったのかもしれません。

目玉(?)の情報大航海プロジェクトのブースも見てきました。

これはどうなんだろう、というのが率直な感想です。オモロサーチとか、ここはIPA未踏のブースかと思うようなチープさです。

役所が大量の金をつぎこむITプロジェクトと聞くと、条件反射的に拒否反応を示す人もいますが、個人的には、そういうものがあっても良いと思っています。経産省の金の出し方とアメリカの国家予算の使い方の差を語れるほど事情に詳しくはないですが、インターネットもBSDもX Window System(Project Athena)も国による財政補助が寄与しているはずです。なので、国が財政補助をするITプロジェクトにはロクなものが無い、と言うのは間違いだと思っています。

しかし、せっかく150億円使うなら、個人で手の出しようの無い分野をやってはどうかというのが個人的な感想です。情報大航海プロジェクトのブースを見ていると、技術よりもサービスに寄りすぎている気がしました。既存技術を組み合わせてサービス化するのは、個人でも小さな会社でも手が出しやすい分野です。そこ頑張られても、という感じです。地味な基礎技術のライブラリなどを作って配布して、未来の誰かがサービスのパーツとして使える方が世の中の為という思いがします。

とは言え、何が正しいかは分かりません。未来は不明だからです。BSDやX Window Systemを作った時代は、そういうものが求められていたのに対し、今の時代はサービスが求められているのだ、という考え方もあるからです。誰が使うか分からないパーツを量産するぐらいなら、今すぐに使えるサービスを提供するべきだという考えも一理あります。また、BSDの時代も、Unixとはなんとチープな、と思っていた人がいるかもしれません。結局、何かを作る人は結果がすべてです。

• 2008/10/6 typo修正
• http://www.amazon.co.jp/exec/obidos/ASIN/4822281116/arielnetworks-22/

原稿が進まない現実逃避かもしれませんが、「ゆとりの法則」を読みました。

「第22章 恐怖と安全」が一番気に入りました。人(組織)が変化できるためには、失敗しても責められないという安心感が必要だという主張です。一部、引用します。

皮肉やいやみを言い、ぐさりとくる批判をし、目の前であざ笑い、人前ではずかしめ、いらだち、かんしゃくを起こし、あきれてみせる。これらはすべて、重要な変化にとって本当の敵である。変化を受け入れられる組織にするには、このような不遜な態度を組織から一掃する必要がある。かわりに、どの階層の人でも、あえて苦労を受け入れようとすれば尊敬されると、はっきりわかるようにすることだ。

変化の最中は、どんな失敗でも、教訓を伝えるものとして尊重されるべきである。失敗した人はヒーローであり、変化の立役者である。失敗によって、その人は前にもまして尊重される。

失敗した人はヒーロー、ってところが良いですね。最近、人の失敗を見ていらだちを見せてしまったかもしれません。今度から、失敗した人はヒーローという格言を忘れないようにします。

FSFのフリーソフトウェアの優先プロジェクトのリスト(http://www.fsf.org/campaigns/priority.html)に、"Reversible debugging in GDB"というのがあります。

• http://sourceware.org/gdb/news/reversible.html

説明からすると、次のことができそうです。

次のような関数呼び出しがあるプログラムをデバッグするとします。

a
|
+-b
| +-c
|
+-d
  +-e

関数aがbとdを呼び出し、bとdがそれぞれcとeを呼んでいます。eの途中でブレークした時、関数cの処理にバグの原因がありそうだと予想して関数cの呼び出し時点に戻りたいことがあります。しかし、こういうことは普通できません。時々、できればいいなと夢想したことがありますが、そんなことは無理だと思っていました。

"Reversible debugging in GDB"でこれができそうです。

無理だと考えた理由は、これを実現するには、スタック領域、ヒープ領域、スタティックなデータ領域(bssおよび非bss)、これらをまとめてデータ領域と呼ぶとすると、ある時点のデータ領域全体の状態をどこかに記憶しておく必要があるからです。例えば、関数aが関数bを呼び出す直前のデータ領域全体の状態が記憶できれば、関数cの呼び出し時点に戻ることができます。しかし、これは全く現実的ではないと思っていました。言うなれば、ネイティブレベルの「継続」だからです(http://dev.ariel-networks.com/Members/inoue/continuations)。

概念上、fork(2)をすると、親プロセスの仮想メモリ全体の複製を行えます。普通のOSはcopy on writeのため、forkした時点でメモリの複製はしませんが、概念上はデータ領域全体の複製ができることになります。

関数aが関数bを呼び出す直前でforkして、その子プロセスを停止したまま、親(元)プロセスの実行を進めます。その後、関数aがbを呼ぶ直前に戻るためには、停止中の子プロセスからデータ領域をコピーして戻す必要があります。ユーザ空間だけで行うなら、なんらかのプロセス間通信により、データ領域をごっそり元に戻す必要があります。copy on writeしたページ分だけをコピーできれば効率的ですが、これをユーザ空間から知るシステムコールがあるかは寡聞にして知りません。その後、PCやSPなどのレジスタを戻せば、関数aがbを呼ぶ直前に戻れます。

理屈上はこれで動作しそうですが、どうでしょう。

Apacheでreverse proxyをする常套手段はmod_proxy(http://httpd.apache.org/docs/2.2/mod/mod_proxy.html)のProxyPassとProxyPassReverseディレクティブをセットで使う方法です。

ProxyPassはシンプルな場合に特化したディレクティブなので、複雑なルールでreverse proxyをしたい場合はmod_rewriteの[P]オプションを使います。ちなみに、http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewriterule にあるように、mod_rewriteの[P]オプションは内部的には、mod_proxyを必要としています。

mod_rewriteは次のページの次の言葉がよく性格を表わしています。

• http://httpd.apache.org/docs/2.2/rewrite/

  The great thing about mod_rewrite is it gives you all the configurability and flexibility of Sendmail. The downside to mod_rewrite is that it gives you all the configurability and flexibility of Sendmail.

某サーバで動作しているapacheがmod_rewriteによるreverse proxy動作をしていました。しかし、バックエンド(=reverse proxyされた側)のWebサーバがRedirect動作をした時に問題がありました。reverse proxyサーバが、RedirectレスポンスのLocationヘッダを適切に書き換えていないためです。

今まで、漫然とProxyPassとProxyPassReverseはセット、という思い込みがありましたが、ProxyPassReverseはmod_rewriteのRewriteRuleの[P]オプションとセットでも使えることを知りました。

こういう確認は、手元で簡単な設定ファイルを用意することで、ローカルのapacheだけで簡単に行えます。

次のようなふたつの設定ファイルを用意して、動作確認を行いました。fooの部分は適当なホスト名に置換してください。

# backend server
ServerRoot "/usr/local/apache22"
Listen 8081
User daemon
Group daemon
ServerAdmin you@example.com
ServerName foo:8081
ErrorLog "logs/error_log"
LogLevel warn
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
CustomLog "logs/access_log" combined
PidFile "logs/httpd.pid"

Alias /y /home/inoue/.emacs.el
Redirect /x  http://foo:8081/y

# reverse proxy server
ServerRoot "/usr/local/apache22"
Listen 8082
User daemon
Group daemon
ServerAdmin you@example.com
ServerName foo:8082
ErrorLog "logs/error_log-rev"
LogLevel warn
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
CustomLog "logs/access_log-rev" combined
PidFile "logs/httpd-rev.pid"

<VirtualHost *>
ServerName foo:8082
RewriteEngine On
RewriteRule (.*)  http://foo:8081$1 [P]
ProxyPassReverse / http://foo:8081/
</VirtualHost>

バックエンドサーバは /y にアクセスされると、.emacs.elを返すようにしています。これは今回の検証にとって意味はありません。単に /y でアクセスされるファイルを用意するのが面倒だったので、.emacs.elを返すようにしただけです。Redirect動作がreverse proxy経由でも適切に動作するかを確認するために、/x へのアクセスを /y にRedirectする設定をしました。

reverse proxyサーバの方は、事実上すべてのアクセスをバックエンドにproxyしています。

http://foo:8082/x にアクセスすると、http://foo:8081/x とバックエンドにproxyされ、バックエンドがRedirectレスポンスを返します。この時のLocationヘッダの値は http://foo:8081/y です。この後の動作が、ProxyPassReverseディレクティブの有無で変わります。 ProxyPassReverseディレクティブが無いと、Locationヘッダがそのまま書き換わらずに通過するので、ブラウザは http://foo:8081/y のバックエンドに直接アクセスします。ProxyPassReverseディレクティブがあると、Locationヘッダの値が http://foo:8082/y に書き換わるので、Redirect後のリクエストもreverse proxyに来ます。

この動作例の場合、ブラウザからバックエンドサーバに直接アクセスできる環境なので、Redirect後にreverse proxyに来なくても動作します。しかし、ブラウザがバックエンドサーバに直接アクセスできない場合(reverse proxyだけがインターネットから見えて、バックエンドサーバが見えない場合)には問題が生じます。

IBMにこんなブログがあるのを知りました。

• http://www.ibm.com/developerworks/blogs/page/bptej

IBMも最近はWeb 2.0のつもりかもしれませんが、IBMのサイトの個人的な印象は、リンク切れの多さです。

例えば、古い記事ですが、

• http://dev.ariel-networks.com/blog/inoue.php?blogid=2&archive=2005-10-13

からリンクしていた

• http://www-6.ibm.com/jp/developerworks/xml/020201/j_x-xdnat.html

の記事は消えています。

web.archive.orgで調べると、次のようにわずか3年であっさり消えています。

• http://web.archive.org/web/*/http://www-6.ibm.com/jp/developerworks/xml/020201/j_x-xdnat.html

サイト内の全文検索で「データ用のXML」で検索しても該当文書を見つけることはできません。

• http://www-128.ibm.com/developerworks/search/searchResults.jsp?searchType=1&pageLang=ja&displaySearchScope=dW&searchSite=dWJapan&lastUserQuery1=%E3%83%8D%E3%82%A4%E3%83%86%E3%82%A3%E3%83%96XML%E3%83%87%E3%83%BC%E3%82%BF%E3%83%99%E3%83%BC%E3%82%B9&lastUserQuery2=&lastUserQuery3=&lastUserQuery4=&query=%E3%83%87%E3%83%BC%E3%82%BF%E7%94%A8%E3%81%AEXML&searchScope=dW&Go.x=13&Go.y=4

RESTとかマッシュアップとか言う前に、まずはリンク切れしないサイトが基本です。学生の個人サイトが卒業とともにリンク切れになるのは仕方ないと諦めますが、企業のサイトが簡単にリンク切れを起こすのはどうかと思います。まあ、最近は改善している可能性もありますが。

ちなみに、2008/8/18の記事は見た目以上に深いのですが、分かる人は僅かです。

• http://www.ibm.com/developerworks/blogs/page/bptej/20080818

ApacheのMLにSCTP版Apacheの話題が流れました。まあ、誰も反応していませんが。

• http://www.cis.udel.edu/~nataraja/research.html

SCTPというのは、TCPと同じレベルのyet anotherなトランスポートプロトコルです。次のページが分かりやすいと思います。

• http://www.ibm.com/developerworks/jp/linux/library/l-sctp/

残念ながら、HTTPをSCTPの上に載せるメリットは感じません。SCTPが向きそうなのは、現状、UDPの上で適度なフロー制御や再送処理をしているプロトコルだと思います。メジャーなところだと、RTP/RTSPあたりでしょうか。

SCTPをTCPと比較すると、開始が4-way handshakeになって(TCPは3-way)、終了が4-wayになっているのが興味深いです。開始が4-wayになっているのは通信プロトコルの本質的な理由ではなく、DoS対策というのが時代を感じます。half closeが無いのは良い気がします。half closeは鬼門です。Windowsのshutdown(2)とか未だに動作が信用できません(ちゃんと調べていませんが)。

TCPのようなバイトストリームではなく、メッセージ境界を維持することは、そんなもんか、という感想です。

TCPのバイトストリーム方式は、TCPのソケットプログラミングを始めた人が最初にはまる問題のひとつです。送り手が1000バイトのデータをsend(2)しても、受け手が1000バイトの単位で受け取る保証はありません。100バイトずつのrecv(2)を10回かもしれませんし、999バイトと1バイトのrecv(2)になるかもしれません。

メッセージ境界を保証するのは、TCPより上位のプロトコルの責任です。TCPの上位プロトコルがメッセージ境界を保証する手法は、主に3つあります。

• 長さ情報を送る(HTTPのContent-Lengthヘッダを想像するのが一番理解しやすいです。この方式が一番、無難です)
• 終端文字を決めておく(SMTPが代表的)
• 送り終わったらセッションを切る(HTTP1.0が代表的)

どれも面倒で、TCPを使うソケットプログラミングのガンです。長さ情報を先に送り後からデータを送るのが最も無難な解決策ですが、ストリーム的なデータをだらだらと送る場合、実は困ります。送っている方も送り始めた時点で全体の長さが分かっていなかったり、あるいは全体長を知るためにデータをなめる必要があり、それならデータをなめながら送ってしまう方が効率的だったりする場合があるからです。こういう場合に終端文字を決める方式もひとつの解ですが、将来に禍根を残す可能性も高いですし(エスケープが必要になってカオスになったり)、そもそも送りたいデータがバイナリデータであれば現実的ではありません。面倒ですが、無難な方式は、HTTP1.1のChunked Transfer Codingのような方式です(細切れで送り、かつ最後のチャンクを明示する)。

この辺の面倒をトランスポート層で見てくれるのは嬉しいような気もする半面、TCPの場合でも苦労するのはライブラリやフレームワークを作る極一部のプログラマだけで、ほとんどの人は苦労を隠蔽した上位APIを使うので、どうでもいいような気もします。

WEB+DB PRESS vol43(2008年2月)

• http://gihyo.jp/magazine/wdpress/archive/2008/vol43

コンピュータ、プログラミング言語、低レイヤの数字 さまざまな「数字」にまつわる基礎知識

• 第0章：コンピュータが扱う数字 ビット、2/8/10/16進数、整数、浮動小数点数……井上誠一郎
• 第1章：プログラミング言語と数字 Java、Rubyと数字の落とし穴……大谷弘喜
• 第2章：低レイヤへの数字への入口 周波数、CPU、メモリ、ディスク、カーネル……袖山剛

の原稿を公開しました。

• http://dev.ariel-networks.com/articles/webdb-vol43/

Webで読むのは見づらいと思うので、テキストファイルも置いてあります。それぞれの画面の下の方にリンクがあるので、ダウンロードしてEmacsで読んでください。

ニュース

• http://www.ariel-networks.com/company/newsrelease/news081023.html
• http://www.ariel-networks.com/blogs/airone/2008/10/av500.html

リリースノート

• http://www.ariel-networks.com/downloads/releasenote/project_a.html#note02

新機能や技術的な話はまた別の機会に。