横にならないブラウザ

iPhoneのSafariブラウザはよく落ちる。

まぁ、不安定な初物というのは別に珍しくないので気長に構えることにする（もちろん、普通の利用者にとっては大きな問題だろうから、早急に安定させて欲しいが）。

それより、個人的に問題なのは加速度センサーによるportrait - landscape自動検知だ。行儀が悪いので、ついゴロゴロしながらウェブ閲覧などしているのだけど、縦画面で見たいのに、ちょっと姿勢を変えた拍子に横画面になってしまう。

ということで、UIWebViewを使って横にならないブラウザを試しに作ってみた。CocoaのWebKit Frameworkをちょっとでも使ったことのある人なら、あっという間に作れるはず。

とりあえず、表示はできるようになったけど、一番見たかったGoogle Readerはクリック時にページを別ウインドウで開くため、単純にUIWebViewだけでは済まないことが（当然予測できてしかるべきではあるが）判明。ちょっと作業が必要だなぁ。その前に、誰かが作ってApp Storeに登録しそうではあるが。。。

iPhoneでWiFi

お祭り騒ぎになった7月11日から1週間が過ぎた頃、ようやくiPhoneを入手できた。たまたま運良く早朝販売で購入することができたけれど、まだまだ入荷量は不安定のようだ。

さて、iPhone Dev Programにはしばらく前から登録されており、これまでtouchを使って遊んでいたのだけど、iPhone実機が手に入ったので、作りかけていたWiFiモニターをiPhoneで動かしてみた。

キーノートで話題になっていたCoreLocationサービスを使うのだけど、WiFiしか使えないtouchですら、かなり正確に場所を示してくれていた。iPhoneにはGPSも搭載されているので、より正確な位置に加え、高さも取得できる。

もともと、WIDEプロジェクトのWiL用アクセスポイントデータをiPod touch/iPhoneで収集しようとして作りかけたもので、あとは登録部分さえ作れば、それなりに使えるものになりそう。

問題はむしろ、これをどうやって配布するかということになる。App Storeで配布できるのかなぁ。一応、作ってはならないアプリケーションの条件には合致しないと思うのだけど。

残念なのは、プログラムのソースコードを公開できないこと。詳細を述べることはできないが、締結したNDAに抵触する行為となる。Xcodeを用いた、Mac用のソフトウェアには、このような制限はないようなので、いずれNDAの内容が更新されることを期待したい。情報交換ができる方が、開発者のスキルも向上するし、よりよいソフトウェアが作られると思うから。

Global HAHA

どうにかInterop Tokyo 2008での実験を完了。(実験の詳細はこちら)

ホームエージェントは、コントリビュータさん提供の1U PCを2台。1台をホール123に設営された主NOCに、もう1台をホール45に設営されたサテライトNOCに置かせてもらった。

ホームエージェント切り替え対応は、NetBSD + SHISAにホームエージェントスイッチメッセージを拡張実装したものを利用。モバイルノードからのBinding Updateが、別のホームエージェントからトンネルされてくるタイミングで、モバイルノードにスイッチメッセージを送る。

モバイルノードは、NetBSD + SHISA (ノートPC)、およびUbuntu Linux + UMIP (USAGI MIP) (Virtual Machine) の2種類を用意。それぞれ、ホームエージェントから送られるスイッチメッセージに従って、より近いと判断されたホームエージェントに再登録する仕組みを拡張実装した。

今回、ホームエージェントを広域に分散した訳ではないため、実際役に立ったかと言われると、まぁたぶん役に立ってはいないのだけれども、スイッチメッセージが正しく動作し、モバイルノードがホール間を移動したタイミングで、登録ホームエージェントが切り替わる動作が確認できたことが、一番の収穫だ。次は、本当のインターネットでの実験かな。

INTEROP TOKYO

INTEROP TOKYO 2008でMobile IPv6のホームエージェント分散運用の実験をするためにホットステージに参加している。INTEROP関連に関わるのは、IPv6 Show Case以来なのでかなり久しぶり。

残念ながら、今回の実験は一般のユーザの方が体験できる環境ではなく、NOCメンバにMobile IPv6端末を使ってもらうという形になる。ホームエージェントの台数は2台で、会場に設営されるNOCを間借りして運用。それぞれのホームエージェントをネットワーク的に離れたNOCに収容し、Mobile IPv6のホームネットワークへの経路をanycastとして広報することで、移動ノードを経路的に近いホームエージェントに収容する仕組みだ。

今日までにインストールを完了し、接続テストとかしている予定だったのに、順調に遅れている。明日くらいにテストできるといいんだけど。。。

フラグメントと効率

パケットを送信する際、パケット長が長ければ長いほど送信に失敗する確立が高くなる。そのため、ビットエラーの発生率が高い無線リンクなどでは、短いパケットなら届くのに、長いパケットだと届かないという状況に出合うことがある。

パケットを短くすれば良いのは明らかだけれども、アプリケーションレベルでは（なるべく）パケットサイズを気にしたりしたくないし、TCPのように、そもそもアプリケーションレベルでパケットサイズの調整が困難な場合もある。

そこで、単純に大きなパケットを送信する際にリンク層で分割するだけで、多少なりとも効率があがったりはしないのか、と考えたくなる。

エラー発生時の再送などを考慮しつつ、思い切り通信モデルを単純化して、1500バイトのパケットを送信する際のフラグメントサイズと、通信効率の関係をプロットしてみたところ、上のようなグラフになった。通信路のビットエラー率は10^-4を仮定している。

フラグメントサイズが40のときが最も効率が良いらしい。うーん。本当だろうか。

iPhone SDKとInterface Builder

iPhone SDKが更新されて、Interface Builderが付属するようになった。早速試してみようと思ったところ、どうやらまだXcodeとの統合が完全ではなく、新規プロジェクトを作成するときに自動的に適切なixbファイルを作ったりはしてくれないようだ。

ウェブで先達の知恵を漁って、なんとなくInterface Builderを使う方法がわかったけれど、一点すごくはまったところがあるので、ここに書いておこう。

Interface Builderで新規のCocoa touch用ixbファイルを作成し、WindowとViewを作成するのだけど、Viewの初期値でUser Interactionがオフに設定されている。このせいで、View内に配置したボタンからのアクションが実行されずに、かなり悩んだ。

次のベータでは、きっとXcodeとの統合も完了し、Interface Builderでほいほい画面が作れるようになるだろうから、その時を気長にまとう。その前に日本でiPhone発売されないと、あんまり意味ないけど。

L2TP on MacOS X

以前、MacOS X 10.5とMacOS X Server 10.4の間でL2TPを使う場合、MPPEを無効にしなければ接続できない、という内容の記事を書いたのだけれど、今日同僚からMPPEが有効のままでも問題なく接続できるとの情報をもらった。

え！？ と思って自分のMacから試してみると、たしかに接続できる。うーん。なにかの勘違いだったのか。。。？

keiichi-mipv6 tag on NetBSD

Mobile IPv6開発のためにNetBSD treeにtagを打つ。どきどきだ。

L2TPでグローバルインターネット

MacOS X Server (10.4)をL2TPサーバにしてMacOS X (10.5)から接続する設定をしてみた。目的は、NATの裏からでもグローバルアドレスを使った通信をするため。

MacOS Xで遠隔会議するとき、XMeetingをよく使う。このとき、プライベートアドレスだとハマることが多い。それならいっそのことグローバルアドレス使えばいいじゃん、という流れ。会議は手段なので、PacketiX VPNみたいなソフトが使えるなら、迷わず使いたいところ。残念ながら、MacOS X用はまだでないようだ。

気をつけないといけなかった点は以下の通り。

1. OS XクライアントでMicrosoft Point-To-Point Encryption (MPPE) Protocol (RFC 3078)を使わないように設定
   
2. OS X Serverのファイアウォールで、IKE (UDP 500)、IKE NAT Traversal (UDP 4500)、L2TP (UDP 1721)を通すように設定
   
3. 当然、NATボックスも上記UDPポートを通すように設定
   

1.に関して、MacOS XのL2TP接続設定にはMPPEをオフにする設定がない。ウェブを見回っていたら、/Library/Prefences/SystemConfiguration/preferences.plistのCCPMPPE128EnabledとCCPMPPE40Enabledの値を0にすればよいという情報を見つけたので、それで対応する。

MPPEはPPPペイロード (PPP Information Payload) を暗号化するための仕様。L2TPとPPPの終端装置が同じ物で、しかもIPsecを使ってL2TPのUDPトラフィックを暗号化している限りにおいては、MPPEでPPPペイロードを暗号化しなくてもよいだろう、と判断。というか、いまどき大切な情報をリンク層の暗号化機能のみで守る時代でもないだろうし。

なお、L2TP (+ IPsec)は、UDP 500、1721、4500が使えることが前提。次の問題は、これらのポートが空いているかどうかかな。