続・J:COM NETサービスのデータ送信量制限について
ついに恐れていたアレが来ました。
J:COM NETサービスにおける大量データ送信に関する見直しのお願い
という文書が配達証明で送られてきました。どういう場合この文書が送られてくるか
「J:COM NETサービスのデータ送信制限について」
に書きました。そういう記事を書いているくらいですから自分の送信量はNetLimiterでチェックしています。送信量が問題になるようになった10月から三か月間オーバーしそうになったら蛇口をしめ、余裕ができたら緩めるということをやっておりこれまで日々の送信量が(NetLimiterの数値を信じれば)二日続けて制限を超えたことは一度もないはずです。
NetLimiterについては(この記事とはぜんぜん関係ありませんが)
「 帯域制御 NetLimiter 4 のProとLiteの違いを調べてわかった驚愕の事実」
「NeLimiter4の使い方 - 帯域制御(通信量制限)の方法」
「NetLimiter4の使い方 - コネクションごとの帯域制御(通信量制限)の方法」
--------
今回指摘があったのは1日と2日の送信量のようです(文書には具体的に何日とは書いてありません)
NetLimiterでは日々の送信量をTraffic Statですぐに調べられます。
1月1日 24.1GB
1月2日 29.9GB
1月3日 26.5GB
でした。1月2日はちょっとあぶない感じですが、少なくとも2日連続してということはないようです。そこで今度は毎時のデータ送信量を調べてみました。
=====
上のグラフはいったん毎時の送信量を数値データとして取得したものをグラフにしたのですが、ここから1日分を集計すると上とは違った数値になります。
1月1日 27.2GB
1月2日 33.6GB
1月3日 26.9GB
どういうわけか日々の集計とは違います。しかも1月2日の送信量が30GBを越えています。でもこれだったらやっぱり怒られる心配はないはずです。
-------
となるとNetLimiterのいう送信量とJ:COMのいう送信量の定義が違うという可能性が出てきます。NetLimiterで測った送信量とJ:COMの把握している送信量はどのくらい違っているのか気になるので聞いてみました。
2日連続30GBオーバーを確認したがどれだけオーバーしたかは把握していない
というのが公式な回答らしいです。こうなると今後どうしたらいいかわからなくなります。
-------
もう一度グラフを見てみます。送信量は時々刻々と変化していますので測定の起点をどこにするかで1日(24時間)の送信量は違います。起点(?)を1日12時にしてみます。
1月1日 12時~ 1月2日 12時 30.1GB
1月2日 12時~ 1月3日 12時 35.1GB
これだと連続して1日(24時間)の送信量が30GBを越えています。またこの結果は上の公式回答の他に(たぶん)しぶしぶ答えてくれた非公式(?)回答とも符合しています。
------
おそらくこれが理由だと思い再度JCOMサポートに問い合わせてみました。
送信量計測の1日の定義を教えてほしい
と。そうしたら
午前0時から翌日の午前0時
とのことでした。
でもこれは違っているんじゃないでしょうか。納得できないからもう一度確認してほしいとお願いしました。明日あたり返事をいただけるはずです。
私の予想(推測)は
24時間の送信量を継続して監視し30GBを越えたら、その時点から再度24時間の送信量を測って30GBを越えたらアウト
です。
-------
補足1
この件翌日J:COMから連絡があったのですが、予想外の回答でした。
J:COMの公式な見解(?)は
1. 午前零時から翌日午前零時までの送信量が二日続けて30GBを越えると警告が発せられる。
2. それ以外のルールについては開示できない。
3. ユーザの送信量の具体的な値は警告を発した場合も含めて開示できない。
です。これがほんとうだとすると私の受け取った回答には開示できないはずのことが含まれていました。どのような回答を受け取ったか書かないのは答えてくれた担当者に迷惑がかからないようにしたいからです。
ところで2.、3.に関してはしつこく教えてくれと食い下がりました。教えてもらえないと帯域制御をどういう方針で行えばいいか決められないからです。けっきょく根負けして2.と3.が開示できないのはわかったらからどうして開示できないのかその理由だけでも教えてほしいと聞いたらおもしろい答えが返ってきました。
電気通信事業法第4条の規定によります。
この条文はこういう場合適用されるものなのでしょうか。私の利用するサービスに関する規定や私の日々の送信量をどうして私に対して開示してはならないのか不思議です。
そもそも、ルールは教えられないがルールは守れ、という主張をしてそのことに疑問を感じないJ:COMのサポートはもっと不思議ですが。
-------------------
関連
「J:COM NETサービスのデータ送信制限について」
「続・J:COM NETサービスのデータ送信量制限について」 (この記事)
「帯域制御 NetLimiter 4 のProとLiteの違いを調べてわかった驚愕の事実」
「NeLimiter4の使い方 - 帯域制御(通信量制限)の方法」
「NetLimiter4の使い方 - コネクションごとの帯域制御(通信量制限)の方法」
「公開 VPN中継サーバープロジェクトのボランティアサーバーを立ち上げてみた」
「VPNサーバーの帯域制御 - ローカルグループポリシー(QoS)がダメでNetLimiter 4に走る」
「VPN Gate - ボランティアサーバーの接続数に見るアジアの情勢」
「アクセスログに見るOS(Windows)の栄枯盛衰」
「過去記事の一覧(測定、電子工作、天文計算): セッピーナの趣味の天文計算」
« (改訂版)高精度10MHzの出力ができそうなGPS受信モジュール | トップページ | 2MHzが(10MHzも!)出力できたGPS受信モジュールGE-612T(u-blox6/LEA-6) »
「パソコン・インターネット」カテゴリの記事
- さくらインターネットのレンタルサーバーでGOで書いたCGIを動かした(苦労)話(2021.04.19)
- SHOWROOMのAPI - 「ライブ情報」の取得(GO言語のソースつき)(2019.10.26)
- SHOWROOM 星集め・星投げツール スケジュールの詳細化 BreakDownSchedule() (三周のやり方を例に)(2019.09.25)
- SHOWROOM 新・自動三周ツール -- GO言語によるブラウザ制御 (1) main()(2019.09.17)
コメント
この記事へのコメントは終了しました。
« (改訂版)高精度10MHzの出力ができそうなGPS受信モジュール | トップページ | 2MHzが(10MHzも!)出力できたGPS受信モジュールGE-612T(u-blox6/LEA-6) »
きちんと計測している人に対してなので、営業(渉外?)担当さんは苦労するに違いないですね。
よくネットワークで使われるウィンドウ制御だったということで、セッピーナさん予想は正解なんでしょうね^^。
こういった計測→推論、記事はけっこう好きです。
投稿: ほよほよ | 2016年1月 7日 (木) 08時48分
なるほど、こういうのをウィンドウ制御というんですね。
この件JCOMから連絡があって、1日というのはやっぱり0時~24時だそうです。
それじゃおかしいと言ったらセッションを切らずに日をまたいだら送信量が通算されるとか言い出しました。具体的にどういう通算の仕方をするか教えてほしいと聞いたら開示できないないそうです。
JCOMさん、ルールを守れと言いながらルールは教えられない、というかなり強気な姿勢です (^^;;
投稿: セッピーナ | 2016年1月 7日 (木) 09時43分