携帯電話各社、年末恒例の「おめでとうコール」自粛の呼びかけ 78
ストーリー by soara
「あけおめことよろ」は朝日が昇ってからがよいかも 部門より
「あけおめことよろ」は朝日が昇ってからがよいかも 部門より
電気通信事業者協会のHPに今年も年末年始のケータイのご利用についてのお願いが掲載されました。「大晦日から元旦にかけての約２時間は『おめでとうコール・メール』はなるべくお控えください」とのこと。これは事件・事故などで警察や消防への出動要請など急を要する連絡に支障をきたさないための配慮ですが、この時間帯皆さんはいつもどうされていますか。またはこの時間連絡がつかなくて困ったという経験がおありでしょうか。
なお１１０番通報における位置情報通知システム は運用されているものの、まだ全国展開されていなかったり電波の状況によって取得できない場合があるので、実際に１１０番通報するときは必ず口頭で住所地や目標物等を伝えるようにしましょう。
そしてまた・・・ (スコア:5, すばらしい洞察)
「いいか、お前ら、絶対にメール送ったりするなよ！」
やってることがダチョウ倶楽部と同じ。
-- gonta --
"May Macintosh be with you"
なぜかドコモだけ混雑想定時間が短いんですよね (スコア:5, 興味深い)
au by KDDI [kddi.com]
Softbank [softbank.jp]
EMOBILE [emobile.jp]
上記3社は単なるコピペのような気もしますが、ウィルコムとドコモは時間帯表記がちょっと違うのです。
ウィルコム [willcom-inc.com]
ご利用が集中すると予想される時間帯 [willcom-inc.com]
NTT docomo [nttdocomo.co.jp]
同業他社が2時間想定しているのに、みかかdocomoは30分だけ。しかも iモードメール送信状況 [nttdocomo.co.jp]というページまで準備している念のいれよう。ギネス申請する会社はさすがですね。でも今年純増数第１位のソフトバンク [j-cast.com]は年始は不通になったりしないんでしょうか。老婆心ながらちょっと心配（笑）
# その時間は仕事中なmasakun
モデレータは基本役立たずなの気にしてないよ
Re:なぜかドコモだけ混雑想定時間が短いんですよね (スコア:3, 興味深い)
>老婆心ながらちょっと心配（笑）
ソフトバンクは年越し時だけでなく、年中通じないので問題ありません。
# 60歳を超えた母にソフトバンク携帯電話を持たせたら、「いつ電話をかけても
# 通話が途切れる」とかで、すぐにメールの打ち方を覚えていました。
Re:なぜかドコモだけ混雑想定時間が短いんですよね (スコア:2, 興味深い)
これの定義が各会社の回線の太さや
基地局の平均収容数を元に想定されるなら、
なんら不思議ではないでしょう。
設備投資の規模の差が出てるだけだと思います。
でも、今日のコミケではDoCoMoだけやたらつながりにくかった気がします
移動無線基地局車でなかったのかなぁ？
この辺のデータ見てみたい！
Re:なぜかドコモだけ混雑想定時間が短いんですよね (スコア:1, すばらしい洞察)
Re:なぜかドコモだけ混雑想定時間が短いんですよね (スコア:3, 参考になる)
一方、ドコモ・FOMAのタイプSSやauのプランSSでは1000円分の無料通信があり、しかも1月1日は月初で無料通信がフルに使えます。
この違いは大きいでしょう。
マラソンで二位を抜いたら何位？
Re:なぜかドコモだけ混雑想定時間が短いんですよね (スコア:1)
ないことが分かっているから誰も本当のタダについての話なんてしていないんですよ。
LIVE-GON(リベゴン)
サーバの死活監視メールとか (スコア:4, 参考になる)
年末年始はコレがあるのであてにできないなぁと思い、サーバと年越しすることに決めました。
例年だと、この時期はサーバメンテなどをすることが多いので、
必要なメンバーが集まっていることもあり、「連絡が付かなくて困る」という経験はあまりないような気がします。
混沌の中にこそ真実がある・・・かもしれないけど探すのめんどい
Re:サーバの死活監視メールとか (スコア:3, おもしろおかしい)
ここ数年、職場でゆく年来る年を視聴しています。
今日も１８：００〜２６：００まで詰めますが、経費節減で人間用空調が止められているので、ハ
クキンカイロをデュアル構成で装備する予定。冬山用の耐寒ウェアや寝袋も押し入れから発掘済み。
ちょっとえらくなったので、昨年は新人にサーバのお守り（死活監視だけ）を担当させたのですが、
あろうことか女（他課の同期らしい）を仮眠用の会議室に連れ込んだというインシデントが発生し
ました。そこで女っ気のないわたしが出戻ったという次第です。
‥‥いや、泣いてないよ！ ちょっとあくびしただけだって！
Re:サーバの死活監視メールとか (スコア:1, 興味深い)
前の課長は若手の頃、夜詰めしてた機械室に看護婦のおねーちゃん連れ込んだっていってたなー…
となりが病院だったので調達は容易だったそうな。
こういうこと？ (スコア:2, おもしろおかしい)
DIO様「思うに携帯電話という機械は便利なものだが誰も彼もが使うから混雑してしまう」
ちなみに僕はかける相手などいません。
Re: (スコア:0)
応答は返ってきませんが。
Re:こういうこと？ (スコア:2, 興味深い)
他社にも番号は違うものの同じようなものは存在している様ですよ。
# 117 と違って電話代もかかりません。
Re:こういうこと？ (スコア:1)
Copyright (c) 2001-2014 Parsley, All rights reserved.
連絡…… (スコア:2, すばらしい洞察)
幸いに呼び出された事は無いけど、年末年始は交通機関も止まるし、タクシーも少ないし、最初から緊急事態を想定したシフトになってないとダメだよね
まあ今年は年始対応シフトが必要だから地獄が……
Re: (スコア:0)
本数は少なくても終夜運転をしているところも結構ありますね。
それを利用して東京近郊大回りしたり･･･
そんなに電話が好きか？＞ALL (スコア:2, おもしろおかしい)
「一般消費者はアケオメコールを使わぬ友人知人の対応を疑問視している」
ってことですね。わかります。
＃電話嫌いなのでAC
Re:そんなに電話が好きか？＞ALL (スコア:1)
> それを可能にするのが電話や携帯メールだってことです。
すごく遠距離にいて会うことが出来ない相手だったらともかく、
電話やメールで挨拶を済ませられる間柄なんて推して知るべしだな。
本当に大切な相手には出来る限り直接会って挨拶するべきだよな。
特段に会えない事情があるわけでもない相手が電話やメールで
年始の挨拶を済ませてきたら、その人との付き合い方を
今後考え直した方がいいかもね。
という考え方もできる。
めでたくもなんともないので (スコア:1)
# 少数派なのでさしたる負荷にはならないのか。
## というか、知り合いがさらに皆無だから、2乗で効いて影響無しか。
一方、ロシアは (スコア:1)
# いまいち
-- う～ん、バッドノウハウ？
クリスマスに続いて (スコア:1)
Re: (スコア:0)
(12月半ばだったので、クリスマスも中止にしました。)
年賀いらねーぞメール(紙も電子も)も既に配布済みなので、
その瞬間のDDoSには当家は参加せずに済むはずです。
まあ、休みにはソバでもすすってることにします。
あとHACKと。
頭を使って欲しい (スコア:1)
って毎年言ってるけど、そうじゃなくて、メールを事前予約にしてバッチ配送するように
しておけば負荷分散は簡単にできると思うけど。
そういうことしてるサイトもあるんだし、サブジェクトに年賀とつければバッチ配送＆
お年玉くじの対象に！みたいな年賀状システム作ればいい。
＃ACは価値ある発言してください
Re:頭を使って欲しい (スコア:2, すばらしい洞察)
今は廃止されたけど、DDIポケットのEメールにはそういう機能がありました (解説@web.archive.org [archive.org]。2007/2/28廃止 [willcom-inc.com])。
ただサーバにそういう機能をつけるとしても、送信が一斉に行われれば結局そこで輻輳する可能性があり、まずいわけです。#1483450 [srad.jp]の言うように、予め相手の端末に配信して期限が来たら開封可能にするみたいなものの方が向いていると思います。年賀メールだけではなく誕生日とか結婚記念日とかにも応用可能なわけですし。ただしそうしたメールを端末に完全に非表示にすると、メールボックスを溢れさせる事が出来てしまうという問題がありますので、少なくともそうしたメールの有無を確認できるようにしないといけないとは思います。あとは相手方の対応の有無の確認手順を用意し、きちんと標準化してほしいですね (絵文字みたいな泥臭い手段ではなく)。機能の実現には特殊なヘッダを利用するんでしょうけど、非対応ならすぐに開封されてしまうというのはちょっと…。
Re:頭を使って欲しい (スコア:1)
『あらかじめ送っておく』ような種類の『バッチ配送』ってどういうものなんでしょう。『そういうことをするサイトが』云々とあるので、サーバーサイドでの処理かと思いましたけど、その段階ではなく？
携帯電話のメールでは、端末→センター→端末、と2度無線ネットワークを通過します。『バッチ配送』と仰ったので、センターに貯めて指定された時間に一斉に端末に送信、というものを考えました。で、(旧)DDIポケットのものを示した次第。端末での送信処理の日時指定実行機能とも受け取れないことはないのですが、これはネットワーク負荷の軽減には全く貢献しませんよね。
またセンターでワンクッション置くというのも、2度の無線ネットワーク通過が1度になりはしますが、今度は日時を数字で指定するために特定の時間帯に集中する危険があります。年賀メールの「1月1日0時0分」とかですね。年賀メールって、基本的にこういう「特定のタイムスタンプの付いたメール」に対する需要だと思います。ウェブ日記と同様かと思います (#1483185 [srad.jp])。ケータイ文化・ネット文化では「日付の数字が切り替わってすぐ」というところに価値を見出す。それが輻輳の要因かと思います。
余談ですが、「端末→端末」という直送メールは、現在はウィルコムPHSのライトメール [willcom-inc.com]のみではないかと思います (相手方端末が通信可能でないと送信することすら出来ない)。SMSもセンターを介した配信を行っています。
Re:頭を使って欲しい (スコア:1)
一歩先に進んで送ってなくても相手のケータイに着信が表示されればいいんですよ。アドレス帳やメールの履歴からFromを抽出してテンプレートを強制表示！
LIVE-GON(リベゴン)
お約束 (スコア:1)
>お年玉くじの対象に！みたいな年賀状システム作ればいい。
キャリア「……というシステムを実装してね。
ただし、追加料金なしで。ハードも現行のまま置き換えは無し。」
いっそのこと (スコア:1, 興味深い)
で、メールをサーバで預かったフリをして、相手の携帯には即座に届けてしまうが、
携帯側の機能で届いてないフリをして、0時ちょうどに届いたフリをする、と。
元旦だけのためのシステムではアレなので、誕生日などのお祝いメールに使おうってことで、
普段からテスト用の負荷を確保してさ。
Re:いっそのこと (スコア:3, 参考になる)
・・釣られた？
～～～妄想は時空を超える。
みんな電源入れとくの？ (スコア:1)
着メロで目が覚めたらムカツクので、
ケータイの電源は切って寝ます。
送った本人は0時ちょっと過ぎって思ってても、
遅延で3時とかに届いたりするからね・・
～～～妄想は時空を超える。
そしてここでも (スコア:1, おもしろおかしい)
/.Jは？ (スコア:0)
Re: (スコア:0)
いっそのこと (スコア:0)
＃想定外の請求になって「人を騙す」と言われるのがオチか。
Re:いっそのこと (スコア:1)
この不景気なおりに、そんなことを無料でやってくれる会社があるなんて思えません。orz
Re:いっそのこと (スコア:1)
ただ、少しぐらい料金を上げても、この時間帯に使用するような層には効果がないだろうけど。
かといって、何倍もの料金にすることもできないだろうし。
Re: (スコア:0)
情けない (スコア:0, 荒らし)
輻輳しないように設計をすべきだというとコストが云々といいますが、それは輻輳までの許容量を大きくすることであって、輻輳しないように設計することではありません。
Re:情けない (スコア:3, おもしろおかしい)
言っているのだと思います。
Re: (スコア:0)
local time=0:00:00を24時間にバラけさせるために！
#あ、キャリアの話でしたっけ。
Re:情けない (スコア:2, すばらしい洞察)
わざわざそれを捌き切れるような設備にしろなんて。
1を聞いて0を知れ!
Re: (スコア:0)
正月だしな
Re: (スコア:0)
Re:情けない (スコア:1)
新年の挨拶とか、近距離の通話もかなりあるはずだから、安価で小型の交換機を細かく設置すれば、輻輳は減らせるよね。専門外なので思いつきだけど。
Re: (スコア:0)
許容量を超える際の対策を練らずの大盤振る舞いよりは
前もって「自粛してね」と呼びかけてる現状の方がよほど良心的だと思う。
向こうさん商売だからサービスは充実させたい。けど
向こうさん商売だからコストと相談せにゃならん。そして
不可能なことを不可能と言わなきゃ商売が成り立たない。
Re: (スコア:0)
ぎちぎちの満員なのに次のバスを待たずに無理に乗ろうとする乗客によってドアが閉められず、
それゆえにバスが発車できず、普段よりも格段に輸送力が落ちる状態になってしまう
といった具合でしょう。
バスに乗るのを控えてくださいとお願いするのも一つの手ではありますが、
それは乗客のマナーに依存しているわけで、技術者としては匙を投げたってことだと思います。
電話の交換機の輻輳にもタイプがあって、ソフトウェアのバグが顕在化するというのもあるんです。
ハングアップもしくはデッドロックしちゃう、不正な処理をしてしまうといったものや、
実際には回線はたくさん余っているのに、それを使うことができないというアルゴリズム上の欠陥など。
Re: (スコア:0)
技術者じゃないでしょ。
おそらく中の技術畑の人は接客サイドのことなんか考えちゃいるまい。
/.JでもPG/SEサイドと営業の軋轢について
笑えるほど絶望的なストーリーが立ったことがある。
Re:情けない (スコア:1, 参考になる)
100%になったからと言ってリセットをかけているわけではないお。100%のときも全力でネットワークは稼動してるんだお。
一般的なネットワークってのはスループットを最大化するとレスポンスタイムが∞になるんだよ。つまりネットワーク内では個々の通信は全力で流れてるんだけど、特定の1通信に限るとそれがいつ届くかは分からないって状態。なにせそれ以外に無数にある通信がネットワークのすべてを占有してるわけだからね。それが輻輳って現象。
だから輻輳を防ぐ設計ってのはイコール一定のレスポンスタイムを保証するように使用率に上限をかける設計ってこと。
さすがにここまで説明すれば自分がいかに変なこと言ってたのか、理解できるよね?
Re:情けない (スコア:1, 興味深い)
バグというか、完全群にするとコストがかかるから、あえて不完全群にしてます。
ダウンする前に、使える回線があってもつながらない状態 (内部輻輳) になります
ただ、今回のは回線交換の話じゃないので、バッファを大きくとるとかでなんとかならんのかな、と。
Re: (スコア:0)
そんなのは前提のうえじゃないの？
発信規制かコストをかけて容量増やす以外の解決策があるとは思えない。