memo 809 件

UQ WiMAX - Windows Vista at オフィス

Windows Vista でのインストールは再起動が不要だった(その代わり、モデムを抜き差ししないとネットワークインタフェースとして認識されなかった)

で、港区のオフィスビル21Fでつなごうとしたけどダメでした。「WiMAX に接続処理中です」の状態がしばらく続き、一瞬「接続準備ができました」になるけど、すぐに接続処理中に戻っちゃう。まぁ、高層ビルだし、建物の中だししようがないでしょう。

UQ WiMAX - Windows7

Windows7 にインストールしようとしたら、
  • そもそも互換モードじゃないとインストールすらできなかった
  • インストールしたら起動しなくなって、自動的に修復が始まった

何かおかしかったのかな。また今度試してみよう。

uq15.png

UQ WiMAX - ネットワーク共有

Mac OS X では使えないことが分かってる UQ WiMAX だけど、VMware Fusion 上の WindowsXP で動くならそこで ICS (Internet Connection Sharing) を動かして、Windows に NAT してもらって外に出ればよいだろうと思い立ち試してみた。

始めに普段 VMware Fusion を NAT (VMware Fusion - 仮想マシン - ネットワーク - NAT)で使ってたので、そのまま Windows 内でネットワークアダプタ「UQ」のプロパティから「詳細設定 - インターネット接続の共有 - ネットワークをほかのユーザに…」をチェックして「ホームネットワーク接続」に「en0」(VMware Fusion の提供する仮想 Ethernet インタフェースの名前を en0 としている)を選択した。

uq13.png

すると、en0 のアドレスが 192.168.0.1 になり、DHCP を配り始めた。しかし、ここで問題が。OSX 側ではこの en0 は(VMware Fusion で「NAT」を選んでるため) vmnet8 に接続されているが、VMware Fusion 的にも DHCP が動いてるため DHCP を使ってくれない。強引に vmnet8 に alias で IPアドレスをつけた(192.168.0.100/24)ところ、一応 192.168.0.1 には ping ができるし、外の世界にも ping はできた。dig @192.168.0.1 www.yahoo.co.jp で名前も索けるのだが、通常のアプリケーションは名前解決に失敗してた。当然、/etc/resolv.conf に「nameserver 192.168.0.1」と書いていたが、今時の OSX にそれは通用しないようだ。

しかたなく「"VMware Fusion" "Internet Connection Sharing"」で検索したところ、あっさりこのページが見つかった。いろいろ書いてあるが、要するに、
  • VMware Fusion でネットワークの設定をブリッジ(VMware Fusion - 仮想マシン - ネットワーク - ブリッジ)にする
  • AirMac で adhoc ネットワークを作る (すると link up する!)
というだけ。adhoc にすることでリンクが上がり、VMware Fusion 的に en0 が AirMac に接続される。そうすればしめたもの。VMware Fusion 上の WindowsXP が DHCP でアドレスと DNS サーバのアドレスを配布し。AirMac が受け取るまで少し待てば、その後は OSX からも UQ WiMAX 経由で通信ができる。

uq14.png

というわけで VMware Fusion を NAT 箱相当に使い、いつでも OSX から通信する環境ができた。嬉しい。なお、モニター期間は 2009年06月30日 まで。それまでに OSX でネイティブに使えるようになるといいな。

ちなみに、OSX 側からだと普通に traceroute できた。
% traceroute -q1 www.google.co.jp
traceroute: Warning: www.google.co.jp has multiple addresses; using 66.249.89.99
traceroute to www.l.google.com (66.249.89.99), 64 hops max, 40 byte packets
1 vmware (192.168.0.1) 0.886 ms
2 119.107.200.49 (119.107.200.49) 106.280 ms
3 172.28.69.12 (172.28.69.12) 116.250 ms
4 124.211.15.9 (124.211.15.9) 106.647 ms
5 obpjbb202.kddnet.ad.jp (210.132.126.17) 82.833 ms
6 otejbb203.kddnet.ad.jp (59.128.4.177) 104.345 ms
7 ix-ote208.kddnet.ad.jp (59.128.7.138) 123.073 ms
8 203.181.102.106 (203.181.102.106) 143.022 ms
9 209.85.241.68 (209.85.241.68) 123.274 ms
10 72.14.236.126 (72.14.236.126) 155.014 ms
11 jp-in-f99.google.com (66.249.89.99) 145.299 ms
%

UQ WiMAX - ネットワーク

続いてネットワークをもうちょいよく見てみた。
C:\>ipconfig /all

[...]

Ethernet adapter UQ:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : UD01SS WiMAX Wave2 NIC
Physical Address. . . . . . . . . : 00-1D-93-09-2E-1E
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 113.152.x.x
Subnet Mask . . . . . . . . . . . : 255.255.255.255
Default Gateway . . . . . . . . . : 119.107.200.9
DHCP Server . . . . . . . . . . . : 119.107.200.9
DNS Servers . . . . . . . . . . . : 119.107.200.23
Lease Obtained. . . . . . . . . . : 2009年3月15日 21:41:18
Lease Expires . . . . . . . . . . : 2009年3月16日 21:41:18

C:\>

Point-to-Point リンクだから default gateway があさってのネットワークに向いてても問題なし。ping とか traceroute とかはこんな感じ。
C:\>ping www.google.co.jp

Pinging www.l.google.com [66.249.89.99] with 32 bytes of data:

Reply from 66.249.89.99: bytes=32 time=131ms TTL=247
Reply from 66.249.89.99: bytes=32 time=112ms TTL=247
Reply from 66.249.89.99: bytes=32 time=113ms TTL=247
Reply from 66.249.89.99: bytes=32 time=112ms TTL=247

Ping statistics for 66.249.89.99:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 112ms, Maximum = 131ms, Average = 117ms

C:\>tracert www.google.co.jp

Tracing route to www.l.google.com [66.249.89.147]
over a maximum of 30 hops:

1 121 ms 127 ms 129 ms 119.107.200.49
2 103 ms 128 ms 131 ms 172.28.69.12
3 * * * Request timed out.
4 * * * Request timed out.
5 ^C
C:\>

途中でプライベードアドレスを使ってる。

さて、じゃあこのネットワークはどうやって広告されてるのでしょう?
route-views.wide.routeviews.org> show ip bgp 113.152.x.x
BGP routing table entry for 113.152.64.0/18
Paths: (4 available, best #4, table Default-IP-Routing-Table)
Not advertised to any peer
2497 2516
202.249.2.110 from 202.249.2.169 (58.138.96.143)
Origin IGP, localpref 100, valid, external
Last update: Sun Mar 15 08:16:11 2009

4538 10026 2516
202.112.60.243 from 202.112.60.243 (202.112.60.243)
Origin IGP, localpref 100, valid, external
Last update: Sat Feb 28 09:21:12 2009

7500 2516
202.249.2.86 from 202.249.2.86 (203.178.133.115)
Origin IGP, localpref 100, valid, external
Last update: Thu Feb 19 10:09:07 2009

4777 2516
202.249.2.110 from 202.249.2.20 (210.171.224.6)
Origin IGP, localpref 100, valid, external, best
Last update: Thu Feb 19 10:08:55 2009

というわけで KDDI から広告されてます。まぁ、当たり前ですね。
ちなみに途中で traceroute が止まっちゃってるので、外からもやってみた。
[...]
13 pax-brdr-01.inet.qwest.net (205.171.234.2) [AS 209] 32 msec 28 msec
14 124.215.192.77 [AS 2516] 32 msec 32 msec 32 msec
15 pacbb001.kddnet.ad.jp (124.211.34.125) [AS 2516] 24 msec 24 msec
pacbb002.kddnet.ad.jp (124.211.34.133) [AS 2516] 28 msec
16 otecbb103.kddnet.ad.jp (203.181.100.185) [AS 2516] 136 msec 200 msec
otecbb104.kddnet.ad.jp (203.181.100.181) [AS 2516] 200 msec
17 otejbb203.kddnet.ad.jp (59.128.4.69) [AS 2516] 200 msec
otejbb203.kddnet.ad.jp (203.181.96.130) [AS 2516] 132 msec 136 msec
18 * * *
いずれにせよダメでした。

UQ WiMAX - インストール

UQ WiMAX のモデム UD01SS が届いたので使ってみた。

何はともあれ MBP に挿してみた。
Mar 15 21:12:00 snow kernel[0]: SAM Multimedia: READ or WRITE failed, SENSE_KEY = 0x05, ASC = 0x20, ASCQ = 0x00
とか表示されて使えなかった。(当たり前)
ただ ISO9660 フォーマットの USB メモリ(?)としては認識され、"Volume" という名前で mount された。中身は、
  • autorun.inf
  • Files/
  • Setup.exe
  • Setup.exe.manifest
(autorun.inf では Setup.exe が実行されるようになっていた)

いずれにせよ動かないので VMware Fusion 上の WindowsXP に認識させてみた。こちらでも、普通に USB メモリとして認識されてる。

まずは、メモリ内にあった Setup.exe を実行。(たぶんこのタイミングで)デバイスの自動認識が始まるがマニュアルにしたがってキャンセル。
uq01.png

普通にドライバのインストールが終わる。
uq02.png

デバイスドライバ上で正しくネットワークアダプタとして認識される。
uq03.png

普通にネットワークアダプタの一覧にも出てきた(ここでは UQ という名前に変更した)
uq04.png

続けて CD-ROM より接続ユーティリティのインストール
uq05.png
uq06.png
uq07.png

何事もなくインストールが終わり、促されるまま再起動するとつながった。
uq08.png

東京都周縁部(一応23区内)の鉄筋マンションの8階、窓から5メートルくらいの場所でこんな感じ(恐らく緑の棒が感度を示してるのだろう。最大でバリ5かな?)

コネクションユーティリティによる表示はこんなもん。
uq09.png
uq10.png
uq11.png

RBB TODAYで計測したら 4.3Mbps くらいだった。
uq12.png

look into ServersMan transactions

ServersMan の通信をしばらく Wireshark してみたけど、どこで IPv6 が使われてるのか分からなかった。(なお iPhone は NAT の裏)

流れとしては、
  1. www.freebit.com に接続
  2. /serversman/iphone/checkstatus.txt を GET して status のチェック
  3. snedit.dream.jp に接続して HTTPS でごにょごにょ (たぶんログイン処理)
  4. snel01.dti.ne.jp HTTPS で接続してごにょごにょ
  5. 途中から snel01.dti.ne.jp 側が port 9000 と 9001 (どちらも中身は SSL)の通信に移行
  6. その後は port 9000/9001 での処理が続く (サーバ側から定期的に keepalive も行なわれてる)
といった感じ。(port の使い分けは サーバ:9001 → iPhone、iPhone → サーバ:9000 の模様) ちなみに当たり前だけどここまでの通信はすべて IPv4。その後、たとえば http://serversman.net/(iPhone名)/ にアクセスすると、snel01.dti.ne.jp から iPhone にアクセスがあってコンテンツを返送してるようだ。(要するに snel01.dti.ne.jp と serversman.net が iPhone の proxy になってる感じ)

本日時点でサーバについてるアドレスは以下の通り。

snedit.dream.jp202.216.231.115
serversman.net202.216.231.116
snel01.dti.ne.jp202.216.231.117 / 2001:2e8:22:18::117

serversman.net には IPv6 アドレスがついてないんだから当たり前だけど、クライアントとの通信も IPv4。

snel01.dti.ne.jp には IPv6 アドレスがついてるから、もしかして iPhone と、(この proxy 風の)サーバとの間で SSL 内に tunnel が作られて、そこで IPv6 の通信をしてる、ってことなのかな…?一応、ServersMan で「情報」って項目を見ると 2001:2e8:500:29aa::/64 内のアドレスが付いてると表示されるが、外からは ping はできないし、何に使われてるかは不明。

もしかしたら iPhone が NAT の外にいると挙動が違うのだろうか?

余談
  1. こうやってパケットというかトランザクションを見てると、あらためて SSL って煩雑だと思う
  2. iPhone 上での WWW サーバは lighttpd 1.4.19 の模様
  3. ダンプする時は ip.len > 52 が便利。余計な ACK とか見なくて済む
  4. well-known port を使ってない場合は Analyze - Decode As が便利
  5. Wireshark の OSX native アプリケーションは出ないのかな…

awk

>cat a
A

B

C
>cat a | awk 'NF{print $0}'
A
B
C
>cat a | awk 'NF{print $0}' | awk '1;'
A
B
C
>cat a | awk 'NF{print $0}' | awk '1;{print "x"}'
A
x
B
x
C
x
>cat a | awk '{print (NF ? "[" ++a "]: " : "") $0}'
[1]: A


[2]: B


[3]: C
>cat a
1 2 3
4 5
6
>cat a | awk '{s=0; for(i=1;i<=NF;i++) s=s+$i; print s}'
6
9
6
>cat a
A B C X
D X E
F X
>cat a | awk '{sub(/X$/,"Y"); print}'
A B C Y
D X E
F Y
>cat a | awk '{$2=""; print}'
A C X
D E
F
>cat a
AAA
BBB
CCC
AAA
CCC
DDD
>cat a | awk '! a[$0]++'
AAA
BBB
CCC
DDD
>

FeedBurner to Google

FeedBurner が Google のドメインにマイグレされたけどどうやってるのかチェックしてみた。
>telnet feeds.feedburner.jp 80
Trying 66.150.96.120...
Connected to feeds.feedburner.jp.
Escape character is '^]'.
GET /Clicklog HTTP/1.0

HTTP/1.1 302 Moved Temporarily
Date: Sat, 07 Mar 2009 11:38:54 GMT
Server: Apache
X-FB-Host: jpfeed3.feedburner.com
Location: http://feeds2.feedburner.com/Clicklog
Content-Length: 0
Keep-Alive: timeout=1, max=32
Connection: Keep-Alive
Content-Type: text/plain

Connection closed by foreign host.
>host feeds2.feedburner.com
feeds2.feedburner.com is an alias for www4.l.google.com.
www4.l.google.com has address 72.14.235.118
>host feedproxy.google.com
feedproxy.google.com is an alias for www4.l.google.com.
www4.l.google.com has address 72.14.235.118
>
まぁ、またドメインが変わるのも面倒なので「My Account → MyBrand」でフィードも独自ドメインに変更した

How to update iPhone apps

US/JP アカウントの app が入り交じってると更新できなかった時にやってたこと。

前提
  • JPアカウントの app は Music/iTunes/Mobile Applications JP
  • USアカウントの app は Music/iTunes/Mobile Applications US
  • Music/iTunes/Mobile Applications は空っぽ
実際の手順は、
  1. iTunes 上ですべての app を削除 (ただし「ファイルを残す」を選択する)
  2. Music/iTunes/Mobile Applications US から iTunes の「アプリケーション」へ .ipa ファイルを D&D する (Music/iTunes/Mobile Applications へコピーされる)
  3. Music/iTunes/Mobile Applications US を削除
  4. 「アップデートの確認」を実行
  5. 再度、iTunes 上ですべての(といっても、今回はまだ片方のアカウント由来の app しか登録されてない) app を削除
  6. Music/iTunes/Mobile Applications を Music/iTunes/Mobile Applications tmp へリネーム
  7. 同様に、Music/iTunes/Mobile Applications JP の .ipa ファイルを iTunes へ D&D
  8. Music/iTunes/Mobile Applications JP を削除
  9. 更新
  10. Music/iTunes/Mobile Applications を Music/iTunes/Mobile Applications JP へリネーム
  11. Music/iTunes/Mobile Applications tmp から .ipa ファイルを D&D
  12. Music/iTunes/Mobile Applications を Music/iTunes/Mobile Applications US へリネーム
  13. Music/iTunes/Mobile Applications tmp を削除

iPhone App アップデート

あれ?いつもはUSアカウントで購入した app を削除してからじゃないとアップデートできなかったのに、今日は普通にアップデートできた。サーバ側で何か修正があったのかな?

IM+

iPhone の app「IM+ Lite」を試してみた。と言っても、興味は「サーバに直接つなぐか否か?」だけ。結論は ×。残念ながら別のサーバを介して接続してた。

テスト環境
  1. MacBook Pro の共有で、
    • 共有する接続経路を「Ethernet」
    • 相手のコンピュータが使用するポートを「AirMac」
    にして、iPhone から Wi-Fi で MacBook Pro に接続する。
  2. その状態で en1 を Wireshark で監視する。
テスト結果
  1. IM+ を起動するとまず、igate1.shapeservices.net と sar2.shapeservices.net の名前を索く
  2. sar2 に http で接続し /regServer/registration を GET する
  3. igate1 に接続し(なぜか接続先ポート番号は 443 (HTTPS)なのに SSL は使ってない)、IMEI とか送ってる (符号化されてる風)
  4. すると igate1 がその次に接続する代理サーバの IPアドレス とポート番号を返してくる (「Rdr ip(x.x.x.x m) port(nnnn)」)
  5. もう一度 sar2 の /regServer/registration を GET する (多分、ここまでで IM+ 的セットアップが終了)
  6. 先に取得した代理サーバへ接続する (SSL 等は使っておらず、プロトコルも平文)
  7. 設定した接続情報が代理サーバへ送られる (サーバ名、ユーザ名、パスワード、SSL 使用の有無など。これも平文。符号化はされてる風。)
  8. (代理サーバがログイン後)buddy の情報が平文で送られてくる (SSL 使用の有無に関わらず)
というわけで、
  • パスワードが第三者(IM+ の運用者)のサーバへ送られる
  • SSL されてない
の2点から落第点。(テストに使ったサーバでのパスワードは変更しといた)

しかし、ユーザ名・パスワードを入力させる app は、その扱いがどうなってるか、もっと明記して欲しいものだ…。

Re: GNU diffの地味だけど便利な機能

http://0xcc.net/blog/archives/000208.html
を試してみた。side-by-side は確かに便利な時がある。
残念ながら --strip-trailing-cr は 2.7.3 からでした > http://bit.ly/FPllw
> diff --version
diff - GNU diffutils version 2.7
> cat a
0
1
2
3
a
b
c
> cat b
1
4
3
a
B
c
d
> diff -u a b
--- a Sat Feb 21 22:43:52 2009
+++ b Sat Feb 21 22:43:58 2009
@@ -1,7 +1,7 @@
-0
1
-2
+4
3
a
-b
+B
c
+d
> diff -W10 -y a b
0 <
1 1
2 | 4
3 3
a a
b | B
c c
> d
> diff --suppress-common-lines -W10 -y a b
0 <
2 | 4
b | B
> d
>

大規模サービスの運用事例 (抜粋)

http://blog.hacklife.net/archives/51788873.html の各リンク先をざーっと読んでみた。
(わりと古い情報も多い。05-08 の情報。)

YouTube (Apr 07)
  • キャッシュの有効利用
  • IO の徹底的な並列化の追求
    • 大きなディスク少し vs 小さなディスクたくさん
  • 独自レプリケーションシステム

livedoor
  • 1ラック60台@3kVA
  • ディスクレス
  • BGP4のTEには限界がある
  • multimaster DB
  • 「ここの負荷が上がるようならここを増強する」というポイントを意識しておくとスケールしやすい構成が組める
  • データ転送 <<<< その他の処理 (レンダリングとか)
  • 平均値はあてにならない (平均 0.2秒、MIN 0.1秒、MAX 240秒)
  • チューニングはクライアントサイドとサーバサイドの両輪
  • 10万件のデータのソート → ユーザが必要としてるのは先頭の10件

hatena
  • LVS + keepalived
  • CPU負荷のスケーリングは簡単、I/O負荷のスケーリングは難しい
  • 現在のコモディティ:8GB~16GB (as of Nov 08)
  • テキスト走査と転置インデックス

LiveJournal
  • run in parallel ?
  • common resource causing blocking
  • partition datase (can't join but never mind)
  • InnoDB: fast as hell
  • MogileFS

flickr
  • Unicode for all (really easy)
  • UTF-8 is 7-bit transparent
  • port exhaustion: 64,511 ports/120 sec port ~ 535 max concurrent connections per IP
  • Always RAID10 (w/ battery backup for write caching or no caching at all)
  • 15K drives >>> 10k drives

twitter
  • ユーザごとにデータを重複して持たせることが、この問題に対する解法のひとつだ。
  • データ更新のタイミングであらかじめ必要なデータを非同期に構築しておく (GREE)

eBay
  • Scale Out, Not Up
  • Virtualize Components
  • WindowsNT/IIS
  • J2EE
  • Impact of Latency
  • Partition Everything, Async Everywhere, Automate Everything, Remember Everything Fails

del.icio.us
  • SQL でスケーリングするのではなく、データを複数マシンに分散させる方法を考慮すべき

Pathtraq
  • 32GB-64GB per server is today's sweet spot (memory)
  • search in compression form

Gree
  • 複数のサービスでの機能連携は前提にしておいたほうがよかったなぁ
  • slow-logをみてEXPLAINしてみたり
  • 各ウェブサーバでちょっとずつソースコードが違う。衝撃。(笑)

mixi
  • 水平分割(機能)と垂直分割(ユーザID)
  • Partition map for level 2: Manager based and Algorithm based
  • マシンのメモリが4GBあるにも関わらず,割当を3GBとしているのは,これ以上の割当を行うとメモリがswapする恐れがあるためです。

っていうか、MySQL ばっかだな。

facebook by Adium

Adium で facebook chat がサポートされてた。けど、今他にオンラインの人がいないからどんな風に見えるのかよく分からない。

よつばと8

おもしろかった!ツボすぎる。
同期の子供とかリアルよつばとらしい。
うらやましい…。新刊待たなくていいんだもんな。

WDS (Windows Desktop Search)

WDS (Windows Desktop Search) で検索時に検索対象フォルダを指定する
には「フォルダ:フォルダ名 検索語句」とすればよい。
「フォルダ名」を含むフォルダ以下にあるファイルが検索対象になる。
なお、「フォルダ名:フォルダ名 検索語句」は意味が違うの
で注意。

Google Calculator

Google Calculator のメモ
1GB in MB : 1 gigabyte = 1024 megabytes
1GB in 1 day : N/A
1GB / 1 day : (1 gigabyte) / (1 day) = 12.1362963 kBps
1 GB / 1 day : (1 gigabyte) / (1 day) = 12.1362963 kBps
1 gb / 1 day : N/A
1gb / 1 day : N/A
1 GB / 1 Day : N/A
1 GB / 1 DAY : N/A
case sensitive なのがカワイイ。(まぁ、kbps と kBps が違うんだから当たり前かもしれないが)

駅探

到着駅の下を引っぱったら経由駅が指定できるようになった! (2ch
より)

iPhone板TIPS

初心者用 iPhone まとめ @wiki - iPhone板TIPS
http://www33.atwiki.jp/iphone/pages/27.html

Tips#13 全文引用を避けたい
→ SHIFT+DELで全文削除

Tips#14 3G経由時のYoutubeの再生画質をWi-Fi経由並みに上げたい
→ Truveo Vedeo Search

は知らなかった。