nunnun's weblog

仕事のお話。

いわゆる非同期処理の話なのだが、あまり僕自身もこの領域は詳しくないので、調べてつつわかったことをアウトプットしてみます。

RPCを利用して処理を実行する場合、何もしないと同期処理となる。
つまりコールをして、結果が返るのを待ち、結果が返ってきたら処理を再開する。
これだと結果が返るのを待っている間は、"待つ"という処理を行うだけなので、CPUを有効的に活用できず非常にもったいない。そこで処理が終わるまで他の処理をさせておき、処理が終わったら結果を取得し、残りの作業をするという"非"同期的処理を行う必要がある。
Ajaxなどでよく利用されるXMLHttpRequestなどは非同期処理を活用しているわかりやすい例だ。

非同期処理のハンドルの仕方には大きく2つの手法がある。

• Futureに代表される、時間がかかる処理に結果をもらえる引換券を渡し、それを任意のタイミングで結果をもらいに行き処理を行うという方法
• CallbackやDeferredに代表される、処理が終わったら実行時にあらかじめ定義した関数を実行する方法

それぞれ長所短所が有るのだが、僕が作ろうとしているものにおいて、それぞれ問題がある。

• Future
  結局誰かがFutureを監視する必要がある。
• Callback
  非同期処理を行った後さらに別の非同期処理を行い、さらにその後に・・というフローではコーディング・運用両面で大変そう。

ただこれは非同期処理を呼び出すクライアントサイドで、あまり大きな問題にならない。

問題となるのはサーバサイドだ。
たとえばRPCでクライアントからリクエストを受けた後、サーバは別のホストにhttpコネクションを張り、そこから値を取るという処理をしたい場合、それぞれの処理単位で同期的に処理してしまえば楽だろうが、そうすると結局そこでブロックされてしまい、クライアントでブロックされないだけでシステム全体で見たらブロックが発生してしまう。

という問題をどのように解決したらいいか考えているのだが、まだ考え中。

また考えて考えがまとまったらエントリーに上げたいと思います。

というわけで2chにアップしたら、明朝もくれとのことだったので、明朝も作ってみた。 

こっちがIPA P明朝（プロポーショナル）

こっちが等幅

で、ついでにフォントを流し込むスクリプトも改造してみた。
今までは、毎回パッケージを作ってKindleにコピーしてUpdateしてっていう流れで、フォントを変えるにも大変だったのでMass Storageモードで見えるディレクトリにフォントをおくことで対応するようにした。

Mass Storageモードでつないだときに、
/fonts にあるフォントを置き換えることでフォントを置き換えることが出来るようになっています。具体的には、

• Mono.ttf
  どこで使われているかわからん
• Sans.ttf
  上部のバーとかメニューのフォント
• Serif.ttf
  本文とかに使われるフォント

となっているので、好きに置き換えて再起動すればフォントが適用されるようになっています。
ただし、今までと同じく、変なフォントを指定した場合最悪起動しなくなる可能性がありますので、要注意。

ダウンロードと詳細なスクリーンショットは続きから。 

[追記]

yoshiさんが、2.3用のunicode font hackを作られたみたいです。
Kindle Software Update Version 2.3に対応したUnicode Font Hack

Continue reading

Kindle DXを購入してしばらくたつが、
unicode hack fontで導入できるDroidフォントでは気に入らないので、
練習をかねてM+IPAフォントを導入してみた。

こんな感じ。ちょっと個人的にはいまいち。

IPAフォントなので、公開して問題ないはずなので、作成したファイルを公開します。
Kindle DXでは動作を確認しておりますが、Kindle、Kindle 2では動作は不明です。

フォントの置き換えは最悪起動しなくなる可能性がありますので、
くれぐれもお気をつけください。

またこれらを使用した結果、動作しなくなったとしてもこちらでは一切サポートはできませんので、自己責任にてお使いください。

Kindle 2,DX用M+とIPAフォントを組み合わせたフォント [kindle_mplusipa_font.tgz]

[追記 2009/09/17]

明朝も作ってみました。
http://blog.nunnun.jp/amazon_kindle_dx_font_hack_2.html 

IPv6のトンネルをタダで提供してくれてる
Tunnelbroker [Hurricane Electric] が、昨日東京にもトンネル終端を設置してくれた模様。 

早速トンネルを張ってみたのだが、どうやらKDDIからだと太平洋を往復してしまうみたいで、
ちょっと残念。（まぁKDDIはサービスとしてv6トンネルあるからそれを使えということかｗ）

traceroute to 74.82.46.6 (74.82.46.6), 64 hops max, 52 byte packets
 1  gateway (10.10.10.1)  0.828 ms  0.464 ms  0.507 ms
 2  211.18.15.34 (211.18.15.34)  4.918 ms  4.918 ms  4.512 ms
 3  211.18.15.46 (211.18.15.46)  4.751 ms  4.671 ms  4.444 ms
 4  nhshibuyart103h.v4.kddi.ne.jp (211.18.15.62)  5.899 ms  6.248 ms  5.894 ms
 5  sjkmlsw103.v4.kddi.ne.jp (211.5.4.25)  5.852 ms  5.953 ms  7.504 ms
 6  sjkmlsw02.v4.kddi.ne.jp (61.202.2.189)  6.204 ms  5.207 ms  5.145 ms
 7  tkycore04.v4.kddi.ne.jp (210.168.192.5)  6.554 ms
    tkycore04.v4.kddi.ne.jp (210.168.192.53)  7.064 ms
    tkycore04.v4.kddi.ne.jp (210.168.192.37)  33.354 ms
 8  otecbb302.kddnet.ad.jp (203.140.128.105)  7.150 ms  7.298 ms  8.649 ms
 9  otejbb204.kddnet.ad.jp (203.181.97.169)  7.133 ms  6.826 ms  6.919 ms
10  pacbb002.kddnet.ad.jp (203.181.100.94)  306.598 ms  202.313 ms  207.730 ms
11  ix-pa7.kddnet.ad.jp (124.211.34.130)  122.330 ms  126.824 ms  125.322 ms
12  124.215.192.82 (124.215.192.82)  124.002 ms
    203.181.104.170 (203.181.104.170)  111.577 ms  111.307 ms
13  10gigabitethernet4-1.core1.sjc2.he.net (72.52.92.70)  116.991 ms  115.286 ms  115.321 ms
14  10gigabitethernet1-2.core1.tyo1.he.net (72.52.92.238)  250.585 ms  250.835 ms  250.782 ms
15  tserv22.tyo1.ipv6.he.net (74.82.46.6)  238.623 ms  238.672 ms  238.623 ms

v6的にも太平洋を往復してしまうので、うち(KDDI)から使うのは微妙。

ただ、Asahi-netとかだと20msぐらいでいけるという話もあるので、ルータとかでv6をトンネルするにも安価でサービスを提供している事業者がいない日本において、v6の実験とかに使えてよいのではないかと思う。 

技術ネタ。

2週間ほど前に、IHANetなるインターネット上の有志のネットワークに参加した。
IHANetとはいわゆるISPが行う、AS番号を割り当ててBGPとかのルーティングプロトコルで経路を交換して、インターオペラビリティの実験や個人のスキル向上をしましょうというグループで、Tomochaさんとかいろいろな人がいます（笑

個人的にはまったポイントが有ったので、軽くまとめ。

• Cisco IOS(12.4系)でlink-localアドレスを用いて経路をBGPにより交換する場合
  

  router bgp 64535
   neighbor peer peer-group
   neighbor FE80::2008:1%Tunnel8 remote-as 64525
   neighbor FE80::2008:1%Tunnel8 peer-group peer
   neighbor FE80::2008:1%Tunnel8 update-source Tunnel8
  !
  address-family ipv6
   neighbor peer soft-reconfiguration inbound
   neighbor FE80::2008:1%Tunnel8 activate
   network 2001:268:355::/48
  exit-address-family
  !

  といってlink-localアドレスにインターフェイスを追加する必要がある。
  当たり前のようで、はまってしまったので注意。

• IPv6がmtu 1280以上のパケットをはじく
  これは未だ何が原因だがわかっていないのだけど、IIJ系からMTU 1280以上のパケットを送るとKDDI大手町のトンネルルータから先パケットが届かなくなる。
  KDDI側の問題は考えづらくたぶん僕の問題だと思うが、とりあえず以下のコマンドで直った。
  

   ipv6 virtual-reassembly max-reassemblies 1024

後は最近家にiSCSIに対応したNASを導入した。
元々会社にiSCSIを導入してESXi周りをすっきりさせようと思ったのだが、コストがべらぼうにかかる(Dell MD3000iにSAS 1TBx15を積んで100万ぐらい)のと、ぶっちゃけストレージをGbEなんかに乗せて大丈夫なの？っていうのが有ったので、見送った。ただ、現実問題いつかストレージ周りを統合させないといけなくなったときにどんなもんかわからないのもイヤなので、家で購入してiSCSI + ESXiでどの程度スループット出るか試してみることにした。

購入したのは、QNAP TS-509 Pro
またセットアップしたところまでなので、何とも言えないが単純NASとしてはかなり早い。
NASとしては優秀だが、iSCSIとしてシステムドライブを入れたりするとどうなるのかはかなり興味深い。
ベンチマークとったりして試したいと思う。