コグノスケ

DVDを借りたのは初めてかもしれない

レンタルCD/DVDショップで有名なTSUTAYAがオンラインでのDVDレンタルを始めました。TSUTAYA DISCAS というレンタルサービスです。ネットで注文すると、家に郵便（宅配便もある？）で届けてくれて、返すときも郵便で送るだけのお手軽レンタルサービスです今なら無料で借りられるらしいので、早速、登録しました。

契約条項を斜め読みしてみると、無料なのは「今月だけ」で来月からは勝手に有料コースに変更されるそうです。そういえばユーザー登録の時に、住所や名前の他にクレジットカードの番号まで聞かれたっけ…。あれは来月からの料金徴収のためだったんですね。

さて、TSUTAYA DISCASでDVDを借りるときの基本的な流れは、
予約リストに登録、2枚借りる、見る、2枚返す、2枚借りる、見る、2枚返す…（リストが空になるまで続く）
です。もう少し詳しく書くと、以下のようになります。

1. （借りる）TSUTAYA DISCASのサイトで借りたいDVDを見つける。
2. 予約リストに借りたいDVDを追加する。
3. 日をまたぐとTSUTAYAからDVDを送りました、という確認メールが来る。
   在庫によるけど、通常は予約リストの上位2枚が送られる。
4. 2〜3日でDVDが配達される。
5. （見る）DVDを好きなだけ見る。
6. （返す）借りたときの封筒にまたDVDを入れてポストへ。切手不要。
7. DVDがTSUTAYAに到着すると、確認メールが来る。
8. 3. に戻って、TSUTAYAが次のDVDを送ってくるのを待つ。

ちょっと仕組みが難しい気がします。単に借りるまでの手順が多いだけか、予約リストという概念が難しいだけなのか…どうもしっくりこない。

ポイントは、手元にくるのは2枚だけ、次を見たければ手元の2枚を返さなければならない、の2点です。一度に2枚しか来ないのは借りパク対策でしょうか。予約リストの上位から送ってくる、ことも知っていると便利です。

とりあえず上限の8枚まで予約リストを埋めました。CDなら幾度となく借りたけど、DVDを借りるのは初めてかも…。

VirtualBoxとOpenGL

下記の参考記事にもあるように、Virtual Box 2.1からOpenGLへの対応が始まっています。個人的にはOpenGLよりDirectXに対応して欲しいところですが…それはさておき。
参考記事: OpenGLやIntel Core i7に対応した「Sun xVM VirtualBox」v2.1が公開

OpenGLへの対応といってもOpenGLのフル機能をサポートしているわけではありません。というのもOpenGLは過去何度も仕様が拡張（※）されており、様々なバージョンが存在するうえに、各GPUメーカーが独自拡張を施しているためです。

というわけでVirtualBoxはどの機能に対応しているのか、OpenGL Extensions Viewer を使って調べてみました。

ホストOS（Windows XP）でOpenGL Extensions Viewerを実行した結果

まず、ホストOS（Windows XP）でOpenGL Extensions Viewerを実行した結果です。ホストマシンではNVIDIA GeForce6600を使っています。

結果はOpenGL 2.1までフル対応です。Rendering Testを走らせてみると、きちんと2.1のテストまで完走します。

VirtualBox内のゲストOS（Windows 2000）でOpenGL Extensions Viewerを実行した結果

次に、VirtualBox内のゲストOS（Windows 2000）でOpenGL Extensions Viewerを実行した結果です。

結果はOpenGL 1.5までフル対応です。しかしRendering Testを走らせようとすると、OpenGL Extensions Viewerがエラーを吐いてしまい、テストができません。しかも不思議なことに、OpenGL Extensions Viewerを起動させるとVirtualBoxごと死んでしまう場合があります。よくわからんな…。OSがWindows 2000だからかなあ…？

VirtualBoxの名誉のために書いておくと、巷にあるOpenGLのアプリケーションは正常に実行できます。OpenGL Extensions Viewerが何か変わったことをしているだけかもしれません。

（※）OpenGLの公式サイトによると現時点での最新版はOpenGL 3.1 のようです。

シュークリーム

大下さんちでシュークリームを作って食べました。

今回はカスタードクリームが若干粉っぽかったけど、シュー皮がうまくいってました。おいしかったです。

シュークリームというと難しそうなイメージがあったのですが、作り始めてからできあがるまで、2時間かからなかったです。材料もクッキーと大差ない（レシピによっては特殊な材料が入っているかも）ので、揃えるのも簡単です。

昼から作って3時のおやつに間に合う、お手軽おやつです。みなさんもいかが？

ネットワークの不調

ある日、部屋のネットワークをシェア（ネットワークの契約や管理は私がやっています）している隣人から「インターネットに繋げない。」って言われました。うーん、何も変えてないぞ？

自分のデスクトップマシン（有線）で試すとインターネットに繋げました。プロバイダやVDSL回線は正常のようです。

隣人のPCは無線接続なので無線が原因？と考えて、手持ちの無線機器（VAIOとNintendo DS-i）で試してみました。結果VAIOは正常に通信できましたので、無線に問題はなさそうです。しかしDS-iはインターネットに接続できません。

何が違うのか

VAIOとDSの差というと、VAIOは固定IP、DSはDHCPから動的割り当てに設定したくらいしか思い浮かびません。試しにDSに固定IPを振ってみると、DSからインターネットに接続できました。どうやらDHCPサーバがおかしくなっているようです。

しかしCTUのDHCPサーバ設定を見ても異常はないし、ログを見ても攻撃されている様子はないので、CTUが原因とは考えにくいです。他に起動しているのはデスクトップマシンくらいなものですから、デスクトップマシンが原因でしょう。おそらく。

デスクトップマシンを調べるとVirtualBoxが起動している時のみ、DHCPが192.168.56.xという変なアドレスを振ってくることがわかりました。仮想マシン内でLinuxを動かしていたのでそれが原因かと思いきや、仮想マシン内でWindows 2000を動かしても同じ症状が出ます。もしやVirtualBox自体が原因か？

DHCPサーバをみつけたぞ

調べるとVirtualBoxは独自のDHCPサーバを持っていることがわかりました（※1）。Host-only Adapterの先にあるネットワーク（つまりホスト - 仮想マシン間ネットワーク）からのアドレス要求に答えて、アドレスを割り当てるためです。

部屋のネットワークとVirtualBoxのホスト - 仮想マシン間ネットワーク

上図のように、CTUのDHCPサーバは192.168.1.1〜254のアドレスを割り当てます。またVirtualBoxのDHCPサーバはホスト - 仮想マシン間ネットワーク上の機器に、192.168.56.101〜254のプライベートアドレスを割り当てるように設定されています。

VirtualBoxのDHCPサーバが振るアドレスと、さきほど判明した変なアドレスが一致していますので、DSを困らせるDHCPサーバはVirtualBoxで間違いなさそうです。

（※1）VirtualBoxのDHCPサーバの設定は、
[ファイル] - [環境設定] - [ネットワークタブ] - [Host-only Adapterのリストから適切なものを選択] - [ドライバーマークのボタン] - [DHCPサーバータブ]
にあります。かなりわかりづらいです。

ブリッジの弊害

ホスト - 仮想マシン間ネットワーク用のDHCPサーバのはずなのに、部屋のネットワーク上にある機器にアドレスを振っているのはなぜでしょう？実は訳あって（※2）部屋のネットワークとホスト - 仮想マシン間ネットワークをブリッジしていたのです。

部屋のネットワークとVirtualBoxのホスト - 仮想マシン間ネットワーク、ブリッジ後

上図のように、部屋のネットワークと、ホスト - 仮想マシン間ネットワークをブリッジすると、VirtualBoxのDHCPサーバに部屋のネットワークからのアドレス要求が届いてしまいます。さらにVirtualBoxのDHCPサーバはCTUのDHCPサーバより早く応答していたため、部屋のネットワークからのアドレス要求に対してVirtualBoxのDHCPサーバの応答が優先されてしまうのです。

その結果、DSはVirtualBoxのDHCPサーバが割り振るアドレスを受け取り、ホスト - 仮想マシン間ネットワーク（青線）へ参加してしまいます。これは当然CTUのDHCPサーバが割り振るのアドレスとは異なりますので、DSは部屋のネットワーク（赤線）上のCTUと通信できず、インターネットへアクセスできないのです。

今回の教訓は、ネットワークをブリッジするときは、ブリッジする2つのネットワークに被害が出ないことを確認してからやりましょう、かな。

（※2）この時はBridge Adapterが何故か使えなかった（2009年4月29日の日記参照）ため、Host-only Adapterを一つ作って、デスクトップのネットワークインタフェースとWindowsのブリッジ機能でブリッジしていました。

不幸中の幸い

幸いなことに今回のケースではVirtualBoxのDHCPサーバの応答速度が、CTUのそれに対して圧勝していたため、問題の発覚が早かったです。これがもし場合によってVirtualBoxのDHCPサーバが勝ったり負けたり、という状況だったら、さらに解析が困難でした。不幸中の幸い、でしょうか。