「とあるAndroid向けメッセンジャーアプリ、ユーザー数増加で携帯電話ネットワークを落とす」記事へのコメント

問題のIMのプロトコルはなんだったんだろうか？

[Kando (36875)]

/.本家からリンクされている記事
"The Android IM app that brought T-Mobile's network to its knees" [fiercewireless.com]
によればT-Mobileがそもそも公開していないらしいが…。

最近XMPP [e-words.jp]の本とかを読んでいたのでストーリーの「IMによる頻繁な更新が問題」と言う下りが気になったけど、
リンク先の記事ではスマートフォンによるストリーミングに注目

Re:

[Anonymous Coward]

よく知らないままに突っ込んでみるけど、

＞さすがにビデオチャットでストリーミング動画のやり取りにはかなわない気はする。
一度繋がった特定の相手のスループットと、不特定多数のユーザーに切り替える（スイッチング？）
コストが違うってことはないのかな。一度繋がった相手に大量伝送するより、ランダムアクセスの
方がコストが高いというのは、メモリでもHDDでも普通にあることだから。

Re:問題のIMのプロトコルはなんだったんだろうか？

[Kando (36875)]

帯域幅を考えていました。

実際、リンク先ではhigh-bandwidth applicationって書いてるのでやっぱり問題は帯域幅かなと。
となるとプレゼンテーション情報の配送じゃなくてやっぱストリーミングなのかなーと。

＃メモリでもHDDでもランダムアクセスのコストが上がる場合、問題は帯域幅じゃなくてレイテンシ（遅れ）。
＃帯域幅は一定時間内に送れるデータの量。データを送る「速さ」。シンプルなバスなら正味バス幅に比例するイメージ。
＃レイテンシは「データくれ」といってから「あいよ」とデータが来るまでの時間。反応の「遅れ」。
＃ランダムアクセスだとレイテンシは毎回発生する可能性あり。
＃連続アクセスであればあるデータの転送中に次を要求するというように
＃並列性をうまく利用できれば最初の1個目以外のレイテンシは隠ぺいできる。
＃その場合帯域幅が支配的。

問題のIMのプロトコルは不明だけど、XMPPの場合は、サーバがいるので、
プレゼンテーション（オンライン、オフライン、在席、不在とかのあれ）情報は
クライアント同士が直接送りあっているわけでなく
サーバが管理してて必要なクライアントにだけ通知を配るようにして最適化しているそうな。
一方、ストリーミングは効率（おそらくサーバへの接続の帯域幅）の問題から
サーバを通らずクライアント同士で送りあうらしい。