世界に恥ずかしい仕組み「SPモード」に思う

NTTドコモから発表があいついているが、内容については
初期の報道が一番詳しい。つまり・・・
>spモードシステムの詳細については執行役員 サービスプラットフォーム部長の澤田寛氏が説明。spモードシステムはユーザーを認証する「ネットワーク認証サーバ」、ユーザー情報を管理する「ユーザー管理サーバ」、端末の接続状態を管理する「セッション管理サーバ」から構成されている。今回、端末からの再接続によってユーザー管理サーバの能力を超える処理が発生し、輻輳、そして通信障害が起きた。この輻輳により、spモードサーバで電話番号とIPアドレスをひも付ける際に不符号（アンマッチ状態）が起き、他のメールアドレスが設定されてしまう不具合につながったという。

光伝送路の全断は人為的ミスによるものだが、「保全作業上のミスが起こらないように、工事関係の人も含めて徹底したいが、仮に起きたとしても、サーバの処理能力が高ければ（今回の不具合は）発生しなかった」（辻村氏）とした。

今回の不具合を受けて、スマートフォンの販売計画（2011年度で850万台）を修正することは考えていないが、「現在は原因や影響の広がりを分析しているので、その上で考えたい」とした。

————-

おかしい・・・どう考えてもシステム的に変だ。輻輳はとうぜん考えておかなければならない通信処理システムの基本設計事項であり、処理能力を大幅に超えた場合もサーバー処理が緩慢になり繋がりにくくなる事はあれ、少なくとも見知らぬところにメールが届くのは言語道断である。

まさしくこれは想定外の津波の高さが来たから仕方がないという東電の言い草とまったく同種の言い逃れであり、技術的にも低レベルのありうべからざる不具合であるばかりか、国のコミュニケーション基盤を支えるエンジニアリングを本業とする会社のとるべき態度ではない。

ではどこがどうシステム設計上悪いのかを考えてみたい。

下の図をみて、はてなこんな事がありうるのだろうかと首をかしげたくなる。ユーザ管理サーバーが輻輳でうまく働かなくなっているのにも関わらずなぜセッション管理サーバーがIDが勝手に処理して進むのか納得がいかなかった。

そこで今回の高木浩光氏の指摘、ドコモ システム不十分の指摘もを見て唖然とした。つまりセッション管理サーバーのIDはIPアドレスそのものであった！というか正確にいうとセッションIDの概念がないセッションサーバーだから。呆れてものも云えないそもそも携帯サイトにはそのような感じでつくられている。したがってそれをならってそのままスマートフォン対応したものだから通常のインターネットの世界では考えられない脆弱な仕組みができあがったというのが真相のようだ。

興味のある方は下記をご覧あれ。

・高木浩光氏のインターネットにおけるセキュリティとプライバシーの両立
・ockeghem(徳丸浩)の日記

それを当たり前の世界にするには云々という説明は、つまりはコストが掛かるので直ぐにやりたがらない利用者の安全を無視した私企業としての儲け主義であり、公共通信を預る会社の云う事ではなく呆れるばかりであろう。

Android/Java Mediaplayer と SoundPool

本日先ほど学校の合宿から帰ってきました。
ちょっとAndroidの話だけどJavaもかぶるので、Java Advent Calendar 2011のネタにします。26日約束だったのにネットが使えなかったので27日になってしまいました！（Oh!my god.）どうもすいません。

学生の卒業研究でAndroidでドラム作成の相談をされた時の事を少しお話。
通常、音楽はMdiaPlayerクラスを扱うのですが、例えば１０個のドラムを画面に配置して、クリックされたときにその位置に対応するドラムの音をならせばよい。
つまりこんな感じ。。。
public class drumSound extends Activity {
private MediaPlayer mp[10];
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
context = this.getApplicationContext();
//–
for (10個分のドラムサウンドファイルをクリエイトする) {
mp[i] = MediaPlayer.create(this, R.raw.music01);
mp[i].prepare();
・・・・・
}

@Override
public boolean onMotionEvent(MotionEvent event) {
if (event.getAction() == MotionEvent.ACTION_DOWN) {
int x = getX(int);
int y = getY(int);
if (1つ目のドラム位置だったら) {
try{
mp[i].start();
}catch( Exception e ){
Log.d(“Err”, “err mpPlay : ” +path );
}
}else if (2つ目の・・・・
ただし、メモリにゴミを残さない様にdestoryメソッドをオーバーライドしておかないといけない。

最初のコードの例だと、多重再生ができなく１回目の再生終了後にしか次のドラムの音が鳴らない。
したがって、ここはSoundPoolクラスを使って下記のように多重再生できるようにする。

public class drumSound extends Activity {
private SoundPool sdPool;
private int sdIds[10];
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
context = this.getApplicationContext();

sdPool = new SoundPool(10, AudioManager.STREAM_MUSIC, 0);
for (int i=0; i<10; i++) {
sdIds[i] = sdPool.load(context, soundResouces[i], 1);
}

@Override
public boolean onMotionEvent(MotionEvent event) {
if (event.getAction() == MotionEvent.ACTION_DOWN) {
int x = getX(int);
int y = getY(int);
if (1つ目のドラム位置だったら) {
sdPool.play( sdIds[0], 1.0F, 1.0F, 0, 0, 1.0F);

でも、よーく考えたら違う位置のドラムは良いが同じドラムなら前に鳴らしていた音はほぼ消されないとハウリングのような音の具合になるので、sdPool.play()の直前に下記を追加して一度ストップさせてから再生すると良い。

sdPool.stop(sdIds[0]);

ドラムの場合は、短い再生音なので良いがデフォルトで再生時数秒のリソースが限界のようだ、もっと長い音を多重で再生するには先のMediaPlayerのインスタンスをスレッドを使って明示的に再生することになる。
例えば、ある程度の長さのメロディーを割り当てた鍵盤楽器があってそれを制御するには次のようなコードになるはず。

private Thread thread[10];
………….
@Override
public boolean onMotionEvent(MotionEvent event) {
if (event.getAction() == MotionEvent.ACTION_DOWN) {
int x = getX(int);
int y = getY(int);
if (1つ目のミュージック鍵盤位置だったら) {
if (thread[0]) {
mp[0].stop();
}
thread[0] = new Thread(newRunnable(H
public void run(){
mp[0].play();
while (mp[0].isPlaying()) {
sleep(50); //50ms毎にチェック。
}
}
thread.start();

Metro style app のプロジェクト

とうとうMetro style app のプロジェクトが動きだしましたね。ここからMetro style app development関連の情報をダウンロードしてFirst Apps Contestに応募できます。
Metro style appについての日本語説明は、後のリンクにありますが、要はPadやSmartPhoneを意識したタッチインタフェースを備えまた、インターネットへも連携するアプリケーションが同じ開発環境で作ることが出来るという訳です。
尚、XAMLはWPF（Windows Presentation Foundation）≒Silverlightを作成する為のフォーマットです。