Android上で効率的にサーバ側に問い合わせる通信をおこなうには?

ドコモから日本語の資料が出てきたので、それ以前に公開されていたソニーの資料と併せてメモ書き。

Androidアプリ作成ガイドライン ~効率的な通信制御に向けて~

Androidにおいて、ネットワークを使って定期的に外部サーバから情報を取得する場合に、どのような実装を取るべきか、という点を日本語で解説。

このドコモの資料は、下記2記事の内容を含んだ、よい日本語の資料では無いかと思われる。

・SONY Developer world:「Reducing power consumption of connected apps」(2010/08/23)

アプリで情報を取得しにいくタイミングを合わせましょう、という記事。
ドコモ資料の「3.2. 1携帯電話あたりの通信回数を減らす手法」に相当する内容。
SONYのでは「AlarmManager.RTCを使え、 AlarmManager.RTC_WAKEUPは使うな」とある。
(ドコモのでは「AlarmManager.ELAPSED_REALTIMEを使うことを推奨」)

Web上には細かい処理までは書かれていないため、サンプルソースをダウンロードしてから、ソースを見つつ確認のこと。

・Ericsson Lab: ネタ元blog記事消滅?
sladeshareに講演で使用したスライドがある:「Understanding Smartphone Traffic – DroidCon 2010」(2010/10/28)

こちらは、無線通信側から見た資料。
ドコモ資料の「2章 モバイルネットワーク概要」あたりの話。


・SONY Developer world:「Android Application Coding Guidelines – Power Save」(2010/04/19)
これは、今回の件にはあまり関係ないけれども、wakelockの使い方について、良い例/悪い例を挙げている。
Ericsson Labの資料で触れられていたので紹介。

perl CGI.pm 渡される引数の取り扱い

perlでCGI.pmを使ってCGIを作る際の話。
・CGIに渡されたパラメータは、別のサーバに対してのコンテンツ取得に使用する
・渡されるパラメータが何がどれくらいあるのかが特定できない
・こちらの内部管理用で不要なパラメータとして特定の文字列があるが、それは引き渡さない

こんな条件がある時に、どーやって、パラメータを取得するか、というところ。

use CGI;
my $q = new CGI;
# 不要なパラメータを消去
$q->delete('sessionid');
# 残ったパラメータを表示
foreach my $name ($q->param) {
    # $nameが持っている値が複数の場合もあるため
    # @_=$q->param($name)に格納して
    # それをforeachする
    foreach my $value ($q->param($name)){
        print "$name=$value <br>\n";
    }
}

perl LWPを使ってcookie必須のページへのPOSTアクセス

うちで主に携帯向けとして提供しているゲームコンテンツのゲートウェイサービスは、内部でHTTP::Liteを使用して、オフィシャルのコンテンツを取りに行っている。

いままでは、それで問題なく利用できていたのだが、今回の動作状況見直しの際に、1点問題となる場面が見つかった。

それは、以下の様に同じ名前のパラメータで値が異なるものを送らなければならないことがある、ということ。

&lt;input type="text" name="param" value="value1">
&lt;input type="text" name="param" value="value2">

HTTP::Liteは、POSTアクセス時のコンテンツのペイロードに連想配列を使うため、同じ名前のものを複数送ることができない。

そんなわけで、LWPを使うように仕様変更を試みた。


HTTP::Liteを使用するもの

use HTTP::Lite;
$http = new HTTP::Lite;
$url="http://~";
$http->add_req_header("Cookie", "cookiename=$cookie");
%vars = ( "param" =>; "value1");
$http->prepare_post(\%vars);
$req = $http->request("$url")
    or $flagerr=1;
$contents=$http->body;

LWP使用に変更したもの

use LWP::UserAgent;
use HTTP::Headers;
use HTTP::Request;
$lwpua = LWP::UserAgent->new;
$url="http://~";
$lwpreq = HTTP::Request->new(POST => $url);
$lwpreq->content_type('application/x-www-form-urlencoded');
$lwpreq->header("Cookie"=>"cookiename=$cookie");
$lwpreq->content("param=value1&amp;param=value2");
$lwpres= $lwpua->request($lwpreq);
$contents=$lwpres->as_string;

細かい点はいくつかあるものの、こんな感じで移行はできた。

失敗した点

最初「$lwpreq = HTTP::Request->new(POST => $url);」を「$lwpreq = HTTP::Request->new(POST => ‘$url’);」としていた。
この場合、「400 URL must be absolute」というエラーメッセージが出力されていた。
$urlにつけていたシングルクォーテーションを外したところ、正常動作した。

参考にしたLWP cookbookのサンプルは固定URLであるので、シングルクォーテーションで良いが、変数を使う場合にシングルクォーテーションを使うと駄目、という基本を忘れていたために食らいました。

もう1点、サーバに対して、Cookieの値を送る方法がよくわからなかった。
HTTP::Liteの時の例とかを考え、headerにCookieという名前で値を追加すればいい、と思い当たったので、それでやってみたところ、期待通りに動作した。

Kik Messengerの賞金付きアプリコンテストかぁ

Kik MessengerというiPhoneでも使えるメッセンジャーアプリがあるようですが、アプリ連携のSDKをリリースして、記念のアプリコンテストをやるんだそうな。
賞は3つあり、それぞれ選ばれたアプリの人に$5000が贈られるとか。

詳しくはThe Kik API Pioneers Awardsを参照のこと。

で、このKik Messengerとのアプリ連携、というのがどんな感じ、というのは、The Kik API Betaの解説内でyoutube動画で説明されてます。

アプリのネタとか、思いつくものがないけど、ちょっと興味深い感じかなぁ

動画デモの内容的にはNintendo DSのピクトチャットを思わせるあたりが^^;;;

vSphere ESXのパス選択方法の変更

IBM SVCなるものを導入し、VMware vSphere ESX/ESXiで使用することになったわけだが、設定に微妙な点を発見した。

それは、ESX/ESXi側でマルチパスの設定変更が必要だと言うこと。

まず、現状、どんな設定になっているのかを確認するために、ESX/ESXiにsshでログインして「esxcli nmp device list」と実行した。 (ESXi 6.xでは esxcli storage nmp device list )

~ # esxcli nmp device list

naa.xxxxxxxxxxxxxxe9d80000000000002d
    Device Display Name: IBM Fibre Channel Disk (naa.xxxxxxxxxxxxxxe9d80000000000002d)
    Storage Array Type: VMW_SATP_SVC
    Storage Array Type Device Config: SATP VMW_SATP_SVC does not support device configuration.
    Path Selection Policy: VMW_PSP_FIXED
    Path Selection Policy Device Config: {preferred=vmhba2:C0:T3:L11;current=vmhba2:C0:T3:L11}
    Working Paths: vmhba2:C0:T3:L11

ずらずら~
~ # 

マルチパスに関する設定は「Path Selection Policy」がソレになる。

現状は「VMW_PSP_FIXED」となっている。

これは、とりあえずアクセスできたパスをずっと使い続け、そのパスが死んだ時に初めて違うパスを使ってみよう、という「固定」の方法となる。

次に、ESX/ESXiで設定できるマルチパスの方式としてどんなものがあるのか?というのを確認するため、「esxcli nmp psp list」コマンドを実行する。 (ESXi 6.xでは esxcli storage nmp psp list )

~ # esxcli nmp psp list
Name              Description
VMW_PSP_FIXED_AP  Fixed Path Selection with Array Preference
VMW_PSP_MRU       Most Recently Used Path Selection
VMW_PSP_RR        Round Robin Path Selection
VMW_PSP_FIXED     Fixed Path Selection
~ # 

方式としては4種類あることが分かる。

それぞれについて簡単に解説をすると・・・


「VMW_PSP_MRU / 最近の使用」

最近使ったパスを優先して使う。

Active/Passive型RAIDの場合の標準設定。

LSI Logic OEM系のRAIDだとコレ。IBM DS3xxx、DS4xxxx、DS5xxxが該当になるはず。

「VMW_PSP_FIXED / 固定」

最初にアクセスできたパスをずっと使い続け、そのパスが死んだ時に初めて違うパスを使ってみようかな。という感じの使い方。

そして、最初にアクセスしたパスが復旧したら、まだ戻る。

Active/Active型RAIDの場合の標準設定。

「VMW_PSP_FIXED_AP」

基本はVMW_PSP_FIXEDと同じだが、Active/Passive型RAIDや、ALUAモード対応RAIDにも対応させた形式。

ちなみにALUAとは非対称論理ユニットアクセス(Asymmetric Logical Unit Access)で、SCSI SPC-3の使用として規定されたI/Oパス決定の仕組みです。詳しく知りたい人はEMC CLARiX 非対称アクティブ/アクティブ機能(ALUA)詳細レビューで解説されているので、参考にしてください。

「VMW_PSP_RR / ラウンド ロビン」

複数あるパス間で、バランスを取りながら使用していく形式。

Active/Active型のRAIDでないと使えない形式。


以前のIBM SVCはマルチパスの仕組みがちょっといけてないところがあったようですが、現在のIBM SVCではかなり改善されているようで、「VMW_PSP_RR」が使用できるようになっています。

しかし、設定の現状をみると「VMW_PSP_FIXED」。

まず、システムに登録されているストレージごとのパス利用方法の既定値(デフォルト)を確認するために「esxcli nmp satp list」を実行します。 (ESXi 6.xでは esxcli storage nmp satp list ) 

~ # esxcli nmp satp list
Name                 Default PSP       Description
VMW_SATP_SVC         VMW_PSP_FIXED     Supports IBM SVC
VMW_SATP_SYMM        VMW_PSP_FIXED     Placeholder (plugin not loaded)
VMW_SATP_MSA         VMW_PSP_MRU       Placeholder (plugin not loaded)
VMW_SATP_LSI         VMW_PSP_MRU       Placeholder (plugin not loaded)
<略>
~ # 

SVCの場合、「VMW_PSP_FIXED」と定義されているのがわかる。

調べてみると、IBM SVCの以前のバージョンでは固定だったらしい。

仕方が無いので手動で変更。

GUIから変更することも可能ではありますが、ディスク数が多いと、全部に対して手動で変更する必要があるので非常に大変なので、コマンドで変更した方がいいでしょう。

「esxcli nmp device setpolicy –psp VMW_PSP_RR –device デバイス名」で変更できます。(ESXi 6.xでは esxcli storage nmp device set –psp=VMW_PSP_RR –device=デバイス名)

とりあえず、ESXiでsshログインを有効にしてから、sshでログインして、SANで認識されているディスクはすべてRound Robinに設定、というものすごくおおざっぱなコマンドを実行する感じになります。

for device in `esxcli nmp path list|grep "Device: "|awk '{ print $2 }' | grep naa`
do
	esxcli nmp device setpolicy --psp VMW_PSP_RR --device $device
done

上記のスクリプトは

現行のVMware ESX/ESXi 4.0/4.1に置いて、SANのディスクは「naa.xxxxxxx~」という感じの名前で認識される。
なので、対象となるデバイス名を取り出して、それに対してパスを設定する、ということを行う。
といったもの。

エラー処理とかは一切考えていないので、ちゃんと設定できたかどうかは別途確認してください。