ご無沙汰しておりました。

会社にもそれなりに慣れて下期からの怒濤の工事を前に、少し余裕があったので
今流行の?iPhone5Sを買ってきました。というか正確にはiPhone5から買い換えてみました。

巷ではプラチナバンドやら800MHzやらという言葉とLTEとかがセットでよく見かけます。

まぁ難しい話は追々するとして、ここでは「700~900MHz」の電波は移動して使う無線機(携帯、スマホ、トランシーバなどなど)
には都合のよいものとお考えください。

で、LTEは3Gより通信速度が速いとか、遅延が少ないとか、これも通信を行う上では都合がよいとお考えください。

今回の本題は、iPhoneでその都合のよい電波をちゃんと使ってるかチェックする方法の紹介です。

ご存じの方も、そうでない方もとりあえずiPhone持ってる方は電話アプリを起動して「#3001#*12345*#」宛に電話かけてください。

するとiPhone内の妖精さん(iPhoneの妖精とかいうとSiriになりそうですが、違います)が電話に出てくれます。で、画面が変わります。

FieldTest1.png

上の画像のような変な画面が出てくるかと思います。
「Field Test」・・・フィールドテストですか。なにテストするんでしょうね。

ここでのテストはフィールドというなの私たちの住む街での電波受信試験のことです。

近場(neighbor)の基地局が何個あって、いくつ受信してる~とかもわかるのですが、
今回は放置します。

今回使うのは「Serving Cell Info」です。

押してみましょう。

FieldTest2.png

なんかいろいろ出てきた。

注目は

  • Download Bandwidth
  • Frequency Indicator
  • Download Frequency

です。

上からそれぞれ、ダウンロードに使用する電波の幅(帯域)、これは大きい方が速くなります。
次に3GPPで決められている電波の周波数区分、そしてダウンロードに使用する電波の周波数です

上から2つ目と三つ目の意味はほぼ同じです。

「Download Bandwidth」の値別ダウンロード速度は以下のように決められています。

  • 5MHz・・・37.5Mbps
  • 10MHz・・75Mbps

LTEのカテゴリー(変調方式、誤り訂正や同期に関する情報など)などでも速度が違ってきます。

次に「Frequency Indicator」と「Download Frequency」ですが、これも3GPPで以下のように決まってます。

表記方法は「Frequency Indicator」-「Download Frequency」-「実際の中心周波数」-「日本のキャリア」

  • 8-3500-930MHz-SoftBank(推定)
  • 18-5900-865MHz-au
  • 19-6050-880MHz-NTTドコモ(推定)

「Download Frequency」というのは「Download Bandwidth」によって前後するため、au以外は推定にしておきました。
こちらはわかり次第記載します。

まあそういうことで、上の画像のような表示になっている場合はauでプラチナバンドLTEが使えているということになります。しかもダウンロード速度最高75Mbpsで。

もちろんそんなに速い速度は出ませんが、なかなか快適に使えてますとだけ添えておきます。

 

※以下のサイトを参考にしました。

http://www.arib.or.jp/english/html/overview/doc/STD-T63v9_20/5_Appendix/Rel9/36/36508-960.pdf

http://www.infraexpert.com/study/wireless46.html

新年あけましておめでとうございます。
ということで一応新年の挨拶を。

さて、いつものように(いつも通り開催できるように動いてくださっている皆様に感謝です)コミックマーケットが東京ビッグサイトで開催されました。

例によって例のごとく私も一般ではありますが参加しました。
まぁ一般サークルや企業ブース、コスプレ広場といろいろ巡ってめちゃくちゃ楽しかったですが、そんな中で通信について少し。

三日間で50万人が訪れているあの場所での通信事情ときたら毎度大変なことになってますが、まぁ今は中の人ではないので傍観者としての意見を。

巷ではよく「ドコモならつながる」だとか「ソフトバンクは回線がゴミ」とかという噂がささやかれていますが、私が確認できた&予想したことを順に記載していきます。

まず、確認できたこと。

私が確認した移動中継車(括弧内は合計アンテナ素子数の予想)
NTTドコモ: 1台(4)
au by KDDI: 1台(3)
ソフトバンクモバイル: 3台(10)

2日目(30日)
会場前東館待ち行列
Xperia(SO-01B)にb-mobile U300のSIMを入れた環境でおおよそ300kbps。遅延はいつもより多め。
Galaxy(SC-02B)にドコモ純正SIMを入れた環境でおおよそ10~20kbps(ネットワークサービスを利用できない場合があった。ただし一度補足すると通話は可能であった)遅延はいつもよりかなり多め。
PocketWifi(GP02)にGMO(e-mobile)のSIMを入れた状態でiPad2にてテザリングして8:30頃は下り3Mbps、上り500kbps前後。ただし9:30過ぎに下り250~400kbpsに減速。上りは200~300kbps前後。遅延量も増加。
Softbankは1.5GHz対応ガラケー(944SH)にてパケット通信や通話は可能。遅延等は体感で少し遅いぐらい。詳細不明。
回線速度は全体的に午後から次第に回復していった感じでした。

3日目(31日)
西館企業ブース待ち行列で、会場前のe-mobile回線で常に6~8Mbpsを記録していた。(どうしたし)
ちなみにこちらではドコモも1Mbpsぐらいを記録(ちなみにドコモは上りの方が速かった。1.2Mbpsぐらい)
電話の呼損率は前日と同じぐらい。
コミケ終了後17時頃のソフトバンク回線の速度が6.5Mbpsを記録(平均して4Mbpsぐらい)→通常ではこんなに速くなることはありません。
おそらく用意していた回線がかなり空いたからではないでしょうか?


2,3日目総評
同じキャリア同士(ソフトバンク同士)の呼損率はいつもと同じぐらいか少し高いぐらい。(1~3回ぐらいコールし直すとつながる程度)
他キャリア同士(ソフトバンク対au、ドコモ)の呼損率は異常に高い(10~20回程度コールしてやっとかかるぐらい)
ソフトバンク→au、ソフトバンク→docomo、au→ソフトバンクはかかりにくいことを確認。
(未確認情報ですが、知り合いがドコモで通信しにくいとの報告がありました。)
どうも2日目より3日目の方が接続しやすかった印象がありました。
西館と東館ではやはりアンテナの設置場所の問題でしょうが、西館の方が全体的に高速通信できていたように思います。

携帯とは別ですが、350MHz帯を利用する登録局無線機(icom製 IC-DPR5)を持って行きましたが、どうもコミケスタッフも同じものを利用しているみたいで常に秘話のかかった通信が入っていました。(暗号化ではないですが)
西館一階から東館に向けてはかなり途切れるみたいでした。
西館の2~4階の東館が見えそうな場所からは大丈夫でした。
ちなみにアンテナが標準のものだったので登録局対応の長いアンテナに変えればもっと安定して通信できそうでした。
電池はよっぽど頻繁に連絡を取らない限り一日は大丈夫でした。

ってな感じでした。
んー、wimaxやPHSがあった方がおもしろかったかもしれませんが、それはまた追々。
それにしても後輩がドコモのスマホが文鎮w と嘆いていました。ま、仕方ないねw

んーでも実際Wimaxでも遅そうな気がしますねぇ。2.5GHzを使ってるからまだいいのかもしれませんが、OFDM自体は多重化方式ではないので、多重接続は周波数帯域の広いCDMA方式の方が勝っているように思いますが。このあたりは気になります。ま、どっちにしてもe-mobileもダメっぽかったですけど。(でも300kbpsあればまあいいかw)
電話の呼損率だけは下げてほしいですねぇ。まぁ無理だろうけど。

ちなみに勘違いがあるとあれなので少しだけ補足。
よく3GがダメでWimaxやLTE(Xi等)がいける!というのはWimaxやLTEが音声通話を(VoIPをのぞく)サポートしていないためというのが大きいみたいです。
ドコモ、au、ソフトバンク、e-mobileの各社3Gはどうしても音声通話がのるということでそのリソース確保分がきついように思います。
なのでパケット通信オンリーの場合はWimaxやLTEをおすすめします。
ついでに、ソフトバンクのULTRA SPEEDおよびe-mobileの4Gエリアは3G系統ですのでそのあたりは留意してください。

通信屋としては音声通話は3G、パケット通信は4Gと分けて利用するのがベストのように思いますね、やっぱり。
次の夏のコミケがいろんな意味で楽しみです。

今回はこれぐらいで。
えーっと、なんか愛用のIX2015でtokyo6to4経由でIPv6通信できるみたいのでメモしておきます。

v6に関してはまだまだ勉強中なのでこんなことできるよ!とかいう情報持っている方いましたら連絡していただければ、
小躍りして喜んで、調子に乗ります。


さて、NECのIX2015ですが、もともとIPv6には対応していますが、トンネル経由での利用にはやはり制限があります。
で、6over4は搭載されていますが、6to4とはアドレッシングがちょっと違うとかという関係で元々は無理かな―と思っていました。

が、どうやらできるようですw

ネットでいろいろ調べて、試行錯誤した結果繋がるコンフィグの例ができあがったので載せておきます。
ご参考までに。

前提:
IX2015がグローバルIPを持っている
6to4アドレスを計算しておく

Linux等で
printf "2002:%02x%02x:%02x%02x\n" *** *** *** ***
*はグローバルIPの第1オクテットからスペース区切りで第4オクテットまで
例:
IPアドレスが10.10.10.10の場合
printf "2002:%02x%02x:%02x%02x\n" 10 10 10 10
2002:0a0a:0a0a

まずはトンネルから
interface Tunnel0.0
  description 6to4
  tunnel mode 6-over-4
  tunnel destination 192.88.99.1
  tunnel source [グローバルアドレスを持っているインターフェース等]
  no ip address
  ip mtu [適時調整]
  ipv6 enable
  ipv6 address autoconfig
  ipv6 mtu [適時調整]
  ipv6 tcp adjust-mss auto
  no shutdown

LAN側インターフェース
interface [インターフェース]
  ip address [プライベートアドレス]
  ipv6 enable
  ipv6 address [上記で計算したアドレス]::1/64
  ipv6 nd ra enable
  ipv6 nd ra managed-config-flag
  ipv6 nd ra other-config-flag
  no shutdown


よくわからなかったらご連絡いただければできる限り対応いたします。

映画にもなりましたが、あちらはFaceBook。

でも私が気にしているのはmixi。

 

よくこの二つは比較されますが、決定的に違う点があります。

FaceBookが実名しかだめだからイコール実社会という関係式のおかしさが一つ。

mixiは匿名だから=バーチャルというのもおかしい。

 

結論から言うと、(もちろん私の考えの範囲内ではありますが)ネットワークの本質をみると、

mixiの方が現実に近い。ということ。

たとえばFaceBookで同僚とネットワークを組みます。名前で検索できます。続けて母校の先輩後輩も探せます。

でもこれら検索した人たちは、確かに実際に自分とつながりがあるとは思いますが、「近しいようで限りなく遠い存在」と思うのです。

だって、先輩後輩同僚と言っても、全然話をしたことなかったらそれは「他人の延長」では?と思うのです。

逆にmixiは匿名と入っていますが、匿名だからこそ「本当に知っている人」しか見つけられないはずです。

この違いはどう思いますか?

 

一方で「実社会」に近づけようとして「実名」を強いたことにより「仮想的」なものに、
もう一方では、あくまでも「実際のつながり」に本名はそれほど必要ではないという考えから「現実」の繋がりを見いだした。

「個」を尊重するあまり「集団」になり、「集団」を維持しようとした結果「個」が生まれた。

 

FaceBookは現実社会をインターネット上でエミュレーションしているに過ぎず、
片やmixiは実際のつながりをインターネット上で構築しているに過ぎない。

おもしろいことにmixiの「名前」というのは本当にその人を識別するための、誰でも知っているわけではない「一意な合い言葉」のような意味合いを持っているのかもしれません。

 

私自身インターネットを利用して様々なことをしていますが、結局のところやはり「会って」何かをしないと、事はうまく進まない。
あくまでもインターネットは「道具」。その点で言うと、FaceBookは「インターネット」が主体であり、人間は道具に過ぎない。
mixiは「人間という存在」が主体であり、「インターネット」は道具に過ぎない。

 

根本的に考え方が違うから、買収がどうとか、勝ち負けの問題ではないと思います。

世間一般からしてみれば、おそらくFaceBookが日本での登録者数がmixiをすぐに抜くだろうと考えていると思います。
これはそうだと思います。ですが、その繋がりの「価値」は?

元々ソーシャルネットワークとは、繋がりに価値を見いだすもののはず。繋がりが希薄か否かをそれら繋がりに含めて見つめないと本当の価値を見失う。

そういった点で日本人というのは、とあるアニメキャラから借りた言葉で語ると、「日本人の心情は、察しと思いやり」。そんな日本人って、繋がりの濃さといったものを常に意識し、日常生活で利用しているのかもしれない。

最近さくらインターネットさんがVPSを初め、使い勝手が良さそうだったので契約をしたのですが、
そこで使われている技術にKVMがあります。

気になったので早速自宅に環境を構築。

構築の時に少し手こずった個所をメモ。


自宅内にVLANを構成している関係でやはり仮想マシンにもVLANを食わせてやりたいという欲求が出てきます。
よくよく考えるとブリッジ+VLANという環境を構築したことがなかったので手こずりましたw
(というよりブリッジがよくわかってないw

まずザックリとした接続図をまとめてみました。
(実はこの接続概念がわからなかったのでエラーが出て止まってたのは内緒ですw

kvm_network.png


はい、実はこの接続図さえわかってしまったらサクサクつながります。

残りの設定を少しだけ。

[/etc/sysconfig/network-script/ifcfg-eth1]
DEVICE=eth1
HWADDR=[NICのMACアドレス]
ONBOOT=yes
TYPE=Ethernet
BRIDGE=br1

[/etc/sysconfig/network-script/ifcfg-eth1.1]
DEVICE=eth1.1
ONBOOT=yes
BRIDGE=br1.1
VLAN=yes

[/etc/sysconfig/network-script/ifcfg-br1]
DEVICE=br1
TYPE=Bridge
BOOTPROTO=none
ONBOOT=no
STP=off
DELAY=0
PIFDEV=eth1
PEERDNS=no

[/etc/sysconfig/network-script/ifcfg-br1.1]
DEVICE=br1.1
TYPE=Bridge
BOOTPROTO=none
ONBOOT=yes


あとは増やしたいだけインターフェースを増やして、KVMに食わせてやるだけでおk。
まさか私が案内を書くとは・・・。
というのは置いておいて。

1月30日に京都で勉強会があるので案内です~。


[京SEC第8回新年勉強会]
日時:2011年1月30日(日)12:00~16:00
場所:KRP町家スタジオ
定員:30名
参加費:無料(ただし会場費は参加者で分担負担)

内容は前回まっちゃで失敗してしまったnetcatの侵入デモと「10分でファイアウォールログ監査」及び鍋懇親会だそうです。

詳しくは以下のURLで。
http://www.kyosec.org/%E7%AC%AC%EF%BC%98%E5%9B%9E%E5%8B%89%E5%BC%B7%E4%BC%9A

残念ながら私はその日就活で時間が取れそうにないのですが、参加できそうな、また、興味がある人はご連絡ください。


netcatはマジで面白そう。
放置していた当ブログも技術系備忘録として復活しようかと思います。

だけど、あんまり期待しないでね♪

ということで9月に(盛大に)引きこもってPHPを書いていました。

 

あ、更新が1年以上ぶりと言う突っ込みはなしの方向で。

 

え、別に忘れてませんよ?

 

べ、べつにわすれてたわけじゃないんだからね!!

 

あー、自分で言うのもなんだけどうざいね。うん。知ってる。ごめんね。

MIT、無線電力転送の実験に成功

さすが天下のMIT。

そりゃベッ○ーも卒業してますよ。

となると、限定空間でなら無線LANと無線電源で完全無線化も夢では無くなったわけだな。

すばらしき未来。

それにしてもまだなのかね。常温核融合炉は。

ちなみに英語ではCold Fusion。どこかのソフトウェアの名前だったりして。

P.S. パラジウムリアクターいいなー。
このページは xfy Blog Editor を利用して作成されました。

 久しぶりにエディタ使って書いてます。

 さて、何から書きましょうか。

 せっかくなのでコメントにあった、他社との競争の中、システムの稼働を急いで、テストを数工程省略して実稼働させてしまったの解決方法について書いていきましょうか。

 まず、作業量を決めてから納期を決めるのは当たり前ですし、どこでもこのように行っていることでしょう。

 ですが現実問題として先に納期が決定されることもあるでしょう。(コメントの方は該当するようです。お気の毒に)
と言ってもいられないので解決手段を考えてみましょう。

 一番簡単な方法はもちろん作業量を減らす(端的には機能を減らす)ことが一番楽で確実でしょう。ですがいくら削っても削りきれない部分はもちろんあります。

 そこをどう解決するかを具体的に考えましょう。

 実装の簡略化

 出来るなら一番いいことです。つまりプログラム自体を書かないことが一番テスト工数を減らせてバグを必然的に減少します。

 そこで現在考え出されている手法として

 ・コードジェネレータ
 ・マッパ
 ・ライブラリ
 ・オブジェクト指向
 ・アスペクト指向

とまぁいろいろとあります。各項の詳細はGoogleで検索でもしてください。

他にもフレームワークの導入などは開発工数が増えれば有効かもしれません。

開発サイクルが早いシステムならWebアプリケーションとして開発するのもいいかもしれません。サーバクライアントモデルにはなりますが、その分クライアント側のプログラムの更新は必要ありません。もしかすると今までWindowsアプリケーションで業務を行っていた方はWebアプリがミッションクリティカルな作業に使っても大丈夫なのかと考えるかもしれません。答えは微妙ですが、大丈夫でしょう。現に銀行のシステムもWebアプリ化していますから。

他の問題としてはセキュリティでしょうか。
セキュリティはアプリケーションの作りによるので、Windowsアプリ、Webアプリどちらでも脆弱性は出来ますし、どちらも完璧にできるかもしれません。インターネットに繋いでいる会社でしたらどちらも危険です。むしろ何も考えずに作られたWindowsアプリの方が危ないかもしれません。Webアプリは元々セキュリティを考慮して作られているので何もしていないWindowsアプリよりは強固なはずです。

ネットワーク全盛の現代においてWindowsアプリ単体による業務はほとんど無いと言っていいでしょう。
そうなると、もしWindowsアプリで単一の業務データを処理するならデータベースにアクセスして処理を行わなければ行けません。
そもそもデータベースは情報を共有するためにデータを汎用化して格納するという考えから生まれたものなので、データベースのデータはネットワークで共有していないと意味がないのです。

となるとWebアプリという選択もいいのではないでしょうか。

もうすぐadobeがapolloを出しますし、XAMPPもある時代ですし、一度Webアプリの開発をしてみてはいかがでしょうか。

と言うわけで?他社との競争の中、システムの稼働を急いで、テストを数工程省略して実稼働させてしまったの解決ほうになったかどうかわかりませんが、(あえてまとめていない部分もあります)この文章が解決の手助けになれば幸いです。

システム障害とは少し違ったかもしれませんが、本質はプログラムをなるべく書かずにバグをなくそう。そしてシステム障害をなくそう。

今回はそんな話。

P.S. Webアプリ開発技術についてのご相談はPHPに関してなら可能ですのでどうぞ。


このページは xfy Blog Editor を利用して作成されました。

ウェブページ

Powered by Movable Type 6.0.5

最近のコメント