勉強中。勉強中。

「Unixネットワークプログラミング」を読み進める。この本は、各所に勉強になることが書いてある。読まざるを得ない。

pthreadを、今まで少し間違えて使っていたのを発見。joinが前提となっていないスレッドは、detachした状態で開始しないといけないらしい（デフォルトでは、joinableという状態になっているらしい）。ていうか、デフォルトを逆にして欲しい。スレッドプログラミングでは、joinはむしろマイナーな部類で、joinに頼った設計はあまりきれいじゃないと思うな。（この点は、リチャードスティーブンスと考えが異なるようだ。）

もう一つ。やっぱりUDPは面白くて、TCPは偉大だという話。

最近は、ネットワークプログラミングと言ったら、TCPのアルゴリズムなんてものはブラックボックスで、おまけに、http通信までもがブラックスボックスになってしまった。今、ネットワークプログラミングといったら、もっと上位レベルの、Webアプリケーション開発の技術・手法を指すことが多い。

しかし、一方で、これだけhttpプロトコルが広がり、さらに、httpでしかインターネットにつなげないことが当然の世の中になったことで、httpを使ったアプリケーションに幅が出来つつある。そして、httpという信頼性のないプロトコルの上で、様々なアプリケーションを動かすようになってきている。開発者は、アプリケーションごとに、httpの上で信頼性を確保するための様々な工夫を行っている。

そういうとき、UDPに信頼性を付加するために、TCPがどういうアルゴリズムを用いているか知っていると面白い。信頼性のないネットワーク上で、TCPとまではいかなくても、せめて一定の信頼性を持たせるためにはどうすれば良いのか、そんなことで、頭を悩ますのは、楽しいことだ。

以前、僕は、ネットワーク帯域を測定するプログラムを作ったことがある。帯域測定のプログラムとしてはttcpとかnetperfとか既存のものはいくつかあったが、僕が作ったときは「どこでも動く」ということが最重要視されたので、httpプロトコルの上で動くものを作った。

帯域測定プログラムって、単に大量のデータを送って時間を計れば良いというものではなく、そのときの帯域具合に合った、ちょうど良い大きさのデータを送るのが重要になる。それに、ネットワーク遅延時間を計測するのは、httpの上ではなかなか難しい（Webサーバの振る舞いを良く理解しておかないと、えらいタイムラグの大きいものになってしまう）。このプログラムの中で、僕は、TCPのスロースタートみたいな感じで、帯域データ量を調整したり、ラウンドトリップ時間の推測アルゴリズムを作ったりと、いくつかの仕組みを実現した。なかなかやりがいがあった。これだけで一つのテーマになるのではないかと思ったくらいだ。