「「おめでとうメール」の遠慮を」記事へのコメント

ちょっとねぇ、、、

[minish (370)]

ユーザに使ってもらう事で利益を上げているのに、 自分たちの都合の悪い時は使わないでねって、不思議ですよね。

サーバや回線の負荷が問題であれば、それなりに増強をすれば良い訳で、他の会社はともかく、ドコモはそれをやる位の利益が上がっているはずなんだろうと思うんですけどね。

Re:ちょっとねぇ、、、

[tty77 (4123)]

> サーバや回線の負荷が問題であれば、それなりに増強をすれば良い訳で、

たしかにそうなんだけど、そういうとんでもない「ピーク値」に
あわせて増強していくのはどうなんだろう。

電力会社でも、ある程度のピーク値にあわせて発電所をつくっていると聞いたことがある。
ex) 工場始業時間に水力発電を使うとか
それでも、夏の午後はとてつもない消費量になる。それを回避するために
「冷房の設定温度を1度上げてね」とでんこちゃん(東京電力onlyだけど)
節電を呼びかけているわけです。

だから、年末年始という、とてつもなく消費量が上昇するところに関して
規制をかけるあるいは自粛を呼びかけるというのは意味のある行為だと思う。

他にも

[SAY (54)]

ごく一時期の最大ピークに合わせて設備投資をしてその分が料金に跳ね返ってくるのをみんな歓迎するわけはないと思うのだが。
まるで整備新幹線やら高速道路整備計画のように採算性を考えない行為なんて一部を除き多くは歓迎しないでしょ。

Re:ちょっとねぇ、、、

[aurora (5149)]

発電所はともかく，サーバや回線の場合はピーク時に合わせて一時的に増強することもそう難しくないと思います．

Re:ちょっとねぇ、、、

[335 (4199)]

参考までに、

電力の場合は一応、常時稼動してなきゃいけない原子力＆火力と
水力、揚水などで住み分けがあるのだと思いますが、回線ってそ
ういうわけにはいかないよな・・・ピーク値にあわせて作る以外
にあるのだろか・・・ってことでピーク下げよう賛成に賛成。

でもでも、叩き売りしたとか変な流行りを作ったってのは罪も
あるな、きっと。

Re:ちょっとねぇ、、、

[G7 (3009)]

送電は、今ほしい電力を今供給してもらわないことにはどうにもならないので、
ピーク時に合わせて発電所を作る必要が(遺感だが)ありますが、
メールってもともと「遅延しても良い」仕掛ですよね。

メールサービスを行なう会社(電話屋ふくむ)が、
「メールは状況しだいで遅配もありえるメディアです。御了承。」
といえば済むことだよね、とか言ったら、せっかちな日本人には
おこられるんでしょうかね?(^^;;;;

余談：
年賀状と同様に、バイトの回線を雇えばいいじゃん?とか
一瞬思ったが、回線は最初からNTTとかが持っている分で
手一杯なのでしたね(^^;
あ。回線じゃなくメールサーバーの問題でしたっけ。
じゃあ、SETI@homeみたいに、各家庭のpcに配送区分けを
分担して行なってもらう、ってわけにはいきませんか?(ぉ
べつに無料ボランティアでなくてもいいですし。

#高河ゆん氏の漫画によると、世のお父さんたちはサンタさんの協力者であるらしい(笑)

Re:ちょっとねぇ、、、

[Ryo.F (3896)]

> あ。回線じゃなくメールサーバーの問題でしたっけ。
> じゃあ、SETI@homeみたいに、各家庭のpcに配送区分けを
> 分担して行なってもらう、ってわけにはいきませんか?(ぉ

携帯電話会社のような通信事業者の場合、
当然ながら通信の秘密を守らねばなりませんので、
個人用 PC に配送分散って訳には行かないと思います。

経路が制御できないのは困る

[brake-handle (5065)]

メールを送受信するホストが重たくなるのと、回線が重たくなるのとでは実際には取るべき対策が異なります。

ホストが重たくなるのであれば、例えばSMTPならMXの多重化をやることになります。これは端末とパケットをやり取りする場合でも比較的簡単に実装できそうです。

問題は回線が重たくなった場合です。無線の場合、もともと空間自体が回線(多くの場合はphysicalおよびdatalink layer)になってしまうため、多重化が非常に困難です(符合分割でもやれば何とかなるかも知れないが)。また、このためにそもそも経路制御という発想が全く頭にありません。この点では、BGPやOSPFなどのrouting protocolによりload balanceが可能なInternetよりも弱いといえます。

Re:経路が制御できないのは困る

[knabe (178)]

多重化はもとから行われていると思いますが。
# 周波数領域の多重化＝使用する周波数帯域狭く（＝ビットレートを落として）
# 占有帯域を狭くして、割り当てられた周波数帯域にできるだけ多くのチャネルを
# 確保する。
# 時間領域の多重化＝同じチャネルに異なる接続のパケットを時分割で流す。
# 符号領域の多重化＝CDMA。実用化されてますな。PN 符号化系列を接続ごとに
# 変えてやることで、それぞれの接続を識別する。
# 空間領域の多重化＝お互いに干渉しない程度の距離に設置した、隣接しない
# 基地局同士で同じ周波数を使用する。

問題は、宛先の端末がどこにいるのかわからない、という点にあるのではないかと。
すなわち、ボトルネックは端末の所在を把握するデータベースではないでしょうか。

Re:経路が制御できないのは困る

[Anonymous Coward]

宛先端末の位置はLocation Registoryで管理されてます。

# 推測ですが
問題は、メールの処理件数自体が非常に多いことと、メール到達時 に端末が圏外の場合、到達可能となった段階でpushするわけですが e-mail機能は後から足したものなので、mail spoolに溜まっている メールが、

Re:ちょっとねぇ、、、

[Silphire (7255)]

> サーバや回線の負荷が問題であれば、それなりに増強をすれば良い訳で
増強などしなくても、もう少しきちんとしたスパムメール対策をすれば、その空きで何とかなるのではないかと思いました。無料利用分を増やすだけではまだ不十分でしょう。

Re:ちょっとねぇ、、、

[kagechan (7132)]

メールサーバもそうなんですが、おそらく、交換機への負荷がかかってしまうのではないかと…。
発呼するときにしろ、メールを出すときにしろ、一旦認証要求と認証応答(俺は正当なモバイルをもっているんだよ～という証明をする)をしないといけませんので。それをするのは交換機なわけですから。
交換機には複数台の BSC がつながっていて、その配下にまた数多くの基地局がつながっているわけですから、交換機が過負荷になって故障でもしたら大変な影響が出てしまいます。