アカウント名:
パスワード:
が結局わからない。制御信号の図 [nikkeibp.co.jp]を見るとAndroidとアプリが同種の"信号"を出してることになるのかな。
わかんないですね。チャットとVoIPはパケットの出し方がずいぶん違うような気がするし、制御信号とかいうのは恐らくは物理層の話だろうしよくわからない。
制御信号というのはIP使えばかならず出るのかな？ 特別なアプリを起動していないAndroidは、間欠的な同期処理に伴うデータのやり取りがある程度。IPで持続的接続を行うようなアプリは定期的かつ割と頻繁にパケットを飛ばすから駄目とか。
この図からは単純に通信使うアプリが増えたから倒れましたとしか受け取れないけどなあ？
それにしても「知らぬほど増えてたようで通信障害」というのはQoSで聞きたい言い訳じゃなかったですね…。
http://plusd.itmedia.co.jp/mobile/articles/1201/26/news091.html [itmedia.co.jp] によると
この制御信号とは、無線通信の準備のために端末とキャリア設備の間でやりとりされるもの。従来のiモードケータイ（フィーチャーフォン）では、発信・着信の際や、端末が移動して基地局が変わった場合に発生していた。
だそうです。基地局が変わった際のセッション維持のための通信って感じですか。
ぱっと見て・端末と基地局の接続に許可を出すための手順・アプリが(IP層で)使う接続手順という異なるものを "制御信号" でひとくくりにしているように思えるんですよねー
なんというか一般向けにわかり易く書こうとして、省略すると意味が通らなくなる大事なところを省いちゃった感じ。こういうのは総務省に出す報告書でちゃんと書かれるんでしょうかね。
あと28分に1回という謎の数字もよくわからない。
ひょっとして、制御信号の実体は、ICMPとかKeepAlive関連の応答パケットとかなのかな？
http://ja.wikipedia.org/wiki/%E5%85%B1%E9%80%9A%E7%B7%9A%E4%BF%A1%E5%8... [wikipedia.org]なんとなくこれかなと思ってみました。
http://image.itmedia.co.jp/l/im/mobile/articles/1201/26/l_yo_dc03.jpg [itmedia.co.jp]この表を見ると同時接続数容量は現行機容量・トラヒックの２倍以上ありOKであるが、信号数/hが現行機容量・トラヒックからダウンしており、明らかな設計ミスです。少なくとも、信号容量も、現行機の倍にしておかなくてはいけません。あと震災時等の過負荷マージンを見込んでおくと尚いいでしょう。ドコモもシステム監査的なストレス検査が必要かも。
便乗ですけど、同じく単位時間当りに処理できる「信号量」という量の定義がよくわからないです。処理できるパケット数をバイトまでブレークダウンしたやーつー？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
「制御信号」の正体 (スコア:3)
が結局わからない。
制御信号の図 [nikkeibp.co.jp]を見るとAndroidとアプリが同種の"信号"を出してることになるのかな。
Re:「制御信号」の正体 (スコア:2)
わかんないですね。
チャットとVoIPはパケットの出し方がずいぶん違うような気がするし、
制御信号とかいうのは恐らくは物理層の話だろうしよくわからない。
制御信号というのはIP使えばかならず出るのかな？ 特別なアプリを起動していない
Androidは、間欠的な同期処理に伴うデータのやり取りがある程度。
IPで持続的接続を行うようなアプリは定期的かつ割と頻繁に
パケットを飛ばすから駄目とか。
この図からは単純に通信使うアプリが増えたから倒れましたとしか
受け取れないけどなあ？
Re: (スコア:0)
それにしても「知らぬほど増えてたようで通信障害」というのは
QoSで聞きたい言い訳じゃなかったですね…。
Re:「制御信号」の正体 (スコア:2)
http://plusd.itmedia.co.jp/mobile/articles/1201/26/news091.html [itmedia.co.jp] によると
この制御信号とは、無線通信の準備のために端末とキャリア設備の間でやりとりされるもの。従来のiモードケータイ（フィーチャーフォン）では、発信・着信の際や、端末が移動して基地局が変わった場合に発生していた。
だそうです。
基地局が変わった際のセッション維持のための通信って感じですか。
NTTドコモの発表は味噌もクソも一緒にしている感じ (スコア:3)
ぱっと見て
・端末と基地局の接続に許可を出すための手順
・アプリが(IP層で)使う接続手順
という異なるものを "制御信号" でひとくくりにしているように思えるんですよねー
なんというか一般向けにわかり易く書こうとして、省略すると意味が通らなくなる大事なところを省いちゃった感じ。
こういうのは総務省に出す報告書でちゃんと書かれるんでしょうかね。
あと28分に1回という謎の数字もよくわからない。
Re: (スコア:0)
ひょっとして、制御信号の実体は、ICMPとかKeepAlive関連の応答パケットとかなのかな？
Re:「制御信号」の正体 (スコア:1)
http://ja.wikipedia.org/wiki/%E5%85%B1%E9%80%9A%E7%B7%9A%E4%BF%A1%E5%8... [wikipedia.org]
なんとなくこれかなと思ってみました。
Re: (スコア:0)
http://image.itmedia.co.jp/l/im/mobile/articles/1201/26/l_yo_dc03.jpg [itmedia.co.jp]
この表を見ると同時接続数容量は現行機容量・トラヒックの２倍以上ありOKであるが、
信号数/hが現行機容量・トラヒックからダウンしており、明らかな設計ミスです。
少なくとも、信号容量も、現行機の倍にしておかなくてはいけません。
あと震災時等の過負荷マージンを見込んでおくと尚いいでしょう。
ドコモもシステム監査的なストレス検査が必要かも。
Re: (スコア:0)
便乗ですけど、同じく単位時間当りに処理できる「信号量」という量の定義がよくわからないです。
処理できるパケット数をバイトまでブレークダウンしたやーつー？