Operaはブラウザじゃぁなかったんだよ！「オフィスツアーOpera編(2008/10/10)」
Tomoさん主催のオフィスツアーに参加してきました。
今回の企業は、10/8に新バージョンであるOpera9.6をリリースしたばかりのOpera Software日本オフィス様。
Tomo's Hotline 「オフィスツアー:Opera Software(10/10[金])参加者募集開始のご案内」
http://toremoro.tea-nifty.com/tomos_hotline/2008/09/opera1010-c24d.html[mixi community] Tomo's Hotline イベント 「オフィスツアー：Opera」
http://mixi.jp/view_event.pl?id=34946900&comment_count=32&comm_id=612969
参加者延べ人数13人でOperaの凄さに驚愕していたら、あっという間に二時間半経過してしまいましたとさ。
で、個人的な結論は「Operaはブラウザじゃぁなかったんだよ！！！(kibayosさん風)」
「信者以外への布教の会」か？ 参加者メモ
Opera社のオフィスツアーということで、参加者はほとんどOpera信者な方々なのではという予想に反して、Operaメイン利用者はごく少数でした。
- 以前Operaを好んで使ってたけど、無料版に広告バナーが入って離れた人：3名
- 注) 2005年9月に無料版の広告掲載をやめ、現在はOperaに広告バナーは入らないです
- Wiiで有償Opera（500円）を買って使っている人：2名
- P2P界隈の人：7名くらい
主催者のTomoさんが、応募が殺到することを懸念してむしろ意図してOperaのコミュニティには情報を載せなかったということで、「信者以外への布教の会」として位置づけられていた（？）模様。
そして恐らくこの狙いは、的中していたのではないでしょうか？
私もこのblogをOpera9.6で書いてますし :-D
Operaイントロダクション
Opera日本オフィスの市川さんによるOpera概要説明がありました。
個人的に面白かったのは以下。
- Operaの名前の由来
- 様々な説があり、正確なところは実は社員も知らない
- 有力なものは、以下の複数の意味を融合された形
- 歌劇(Opera)の様に、様々なメディアをミックスされたものにしたい
- 運用(Operation)をリスペクト
- お薦めはOpera mail
Choose Opera 日本支部
http://my.opera.com/chooseopera-Japan/blog/
「技術力に驚愕」 技術オタク向けデモ
Opera日本オフィスのアンドレスさんによるOperaデモは、参加者から驚きの声があがりっぱなしでした。
背景画像がウィンドウサイズ変更にあわせて動的に変更されるCSS。
-o-background-size:
このCSSは標準にすべく提案中とのことでした。
誰かがつぶやきました「これはWebページ作成者が喜ぶな」。
textに様々なshadowがつけられるCSS。
デモでは、textが燃えている様に見えるCSSのコードと、実際の表示を見せてもらいました。
しかも、印刷もその画面表示のまま行えることを、PDFファイルにすることにより見せられて参加者から歓声があがりました。
誰かがつぶやきました「PhotoShopで効果をつけたタイトル画像を作る必要ないじゃん」。
CSS text shadows and background sizing
http://dev.opera.com/articles/view/css-text-shadows-and-background-sizing/
JavaScriptとCSSで、簡単にアニメーションが作成できる。
デモでは、四角いオブジェクトが落下し、バーに当たって滑り落ちていくアニメーションが、十数行程度のコードで実現されていました。
誰かがつぶやきました「Flashいらないじゃん」。
The Opera Animation library
http://dev.opera.com/articles/view/the-opera-animation-library/
YouTubeなどでは、Videoを表示させるためのコードが非常に長くて煩雑になるものを、シンプルなコードで表示可能。
また、表示させたVideoのサイズや形などもマウスで自由に変更可能にできる。
A call for video on the web - Opera
美しい数式を表示可能。
これは絶賛者多数でした。
誰かがつぶやきました「Operaで学術プレゼンしたくなった」。
Can Kestrels do Math? MathML support in Opera Kestrel
http://dev.opera.com/articles/view/can-kestrels-do-math-mathml-support-in/
widgetにより、ユーザにてアクセス権を自由に定義して、ローカルファイルの操作も可能。
File I/O API for widgets
http://dev.opera.com/articles/view/file-i-o-api-for-widgets/
Dragonflyにより、Webのリモートデバッグも可能。
誰かがつぶやきました「.NET Frameworkいらないじゃん」
Debugging widgets using Opera Dragonfly and the Opera Widget Emulator
http://dev.opera.com/articles/view/debugging-widgets-using-opera-dragonfly/
Opera Dragonfly の基本設計 (Japanese)
http://dev.opera.com/articles/view/opera-dragonfly-12398-ja/
Opera Dragonfly 入門 (Japanese)
http://dev.opera.com/articles/view/opera-dragonfly-japanese/
Remote debugging with Opera Dragonfly
http://dev.opera.com/articles/view/remote-debugging-with-opera-dragonfly/
と、「まだまだOperaの凄さはほんの一部分ですよ」と市川さんに言われましたが、参加者みんな大満足の模様。
「こんなに様々な機能が追加されているのに、Operaは動作が軽快かつインストーラもそれほど大きくないのはなぜか？」という質問をしてみたところ、市川さんは「動作の軽快さがOperaの売りなので、機能追加の都度、コアの見直しをかけている。結局それに尽きる」とお話されていました。
結果的に、「Operaはもはやブラウザじゃないな」というのが参加者の共通認識になった模様。:-D
「入信の証（？）」お土産いっぱいもらいました :-D
最後にお土産をいっぱい頂いちゃいました♪
- Tシャツ
- リストバンド
- うちわ
- きらきらステッカー
参加者全員で真っ赤なTシャツを着て、Opera社の看板の前で記念撮影しましたとさ
生暖かく見守ろうP2PSIP「SIProp勉強会(2008/9/19)」
少し時間があいてしまいましたが、2008/09/19にSIProp勉強会に参加してきました。
のべ参加人数は26人で、結構盛況だったと思います。
SIProp勉強会 告知 (講師Tomoさん提供の資料もあります)
http://www.siprop.org/ja/2.0/index.php?%B3%AB%C8%AF%2F%A5%B3%A5%DF%A5%E5%A5%CB%A5%C6%A5%A3%A1%BC%2F%CA%D9%B6%AF%B2%F1%2F2008%2F09%2F19Tomo’s HotLine「P2PSIPの解説講演をします＋近況報告」 (講師Tomoさんのblog)
http://toremoro.tea-nifty.com/tomos_hotline/2008/09/p2psip-5e45.html無印吉澤 [P2P][SIP]第10回P2P SIP勉強会（9/19）と第3回オーバレイネットワーク研究会（9/27）のお知らせ
http://muziyoshiz.jp/20080907.html
また私的メモを残しておきます。
講師のTomoさんから、主に以下の解説がありました。
- P2PSIP-WGコンセプト "draft-ietf-p2psip-concepts"
- P2PSIPにおける経路確認 "draft-zheng-p2psip-diagnose"
P2PSIPメインプロトコルである、"RELOAD ("draft-ietf-p2psip-reload")"は、130ページの大作なので、今回は対象外になりました。:-D
で、個人的な結論は、「生暖かく見守ろうP2PSIP」でした。
draft-ietf-p2psip-concepts
P2PSIP-WGの "infomational" draftです。このI-DにてP2PSIP-WG自体の方針を決めて、その上でその方針を具体化する技術議論を行うということらしいです。
そのP2PSIP-WGの活動を理解する上で最も重要なI-Dについての解説が講師Tomoさんにて行われ、SIP関連、P2P関連、その他それぞれの有識者からの厳しい意見でかなり熱い議論が交わされました。
まずは、用語定義の説明。
このI-Dが定義している用語は主に以下でした。（個人的に重要だと思ったもののみ抜粋）
- P2PSIP Peer
- P2PSIP Peer Protocolをしゃべる
- DHTなどによってlocation infomationを格納/参照/修正する
- location infomationを元に、メッセージのルーティングを行う
- P2PSIP Client (Optional)
- P2PSIP Client Protocolをしゃべる
- location infomationの参照/修正をする
- その役割などは、still under discussion
- Bootstrap Peer
- オーバーレイに参加するノードが最初に参加要請するノード
- Bootstrap Server
- Bootstrap Peerを不特定のノードに教えることができるサーバ
- P2PSIP Peer Protocol
- DHT(など)をベース
- P2PSIP Peer同士がやりとりするプロトコル
- Peer-ID (≒ Node-ID)
- オーバーレイ上のユニークなID
- DHTにおけるhash値などを想定しており、ユーザフレンドリーなものではないことを前提とする
- Resource-ID
- UserやServiceといったリソースを特定するユニークなID
- 分散アルゴリズムによってオーバーレイ上の返信可能なPeer(s)を確定する
- ユーザフレンドリーなものではないことを前提とする
とりあえず、この用語定義の段階で既に議論が紛糾 :-D
議論を簡単にまとめると、以下。
- 用語が既存のものと誤解を生じやすく、わかりにくい
- Peer-IDとResource-IDはどう違うのか？分ける意味があるのか？
- Peer-IDやResource-IDなどの一意性は誰が保証するのか？
結論が出ず、もやっとしたまま次に進みました。
続いて、シーケンスイメージの概要説明。
まずは、「シーケンスイメージ1」
Peer X Peer Z Peer Y
| | |
| | Put(U@Y) |
| |<---------------|
| | Put-Resp(OK) |
| |--------------->|
| | |
| Get(U) | |
|---------------->| |
| Get-Resp(U@Y)| |
|<----------------| |
| INVITE(To:U) | |
|--------------------------------->|
ここで、会場の思考が止まりました。
せっかくGetで"Y"を教えてもらったのに、結局最初から知っている"U"を使って Peer X がINVITEするんだったら、Getの意味なくね？
続いて、「シーケンスイメージ2」
Peer X Peer Z Peer Y
| | |
| | Put(U@Y) |
| |<---------------|
| | Put-Resp(OK) |
| |--------------->|
| | |
| INVITE(To:U) | |
|-----------------| INVITE(To:U) |
| |--------------->|
| | |
これは、シーケンスイメージ1と較べて会場納得。
まだ動きそうな気がする。
次は、「シーケンスイメージ1」を発展させた「シーケンスイメージ3」
Peer X Peer Z Peer Y Peer W
| | | |
| | Put(U@W) | |
| |<---------------------------------|
| | Put-Resp(OK) | |
| |--------------------------------->|
| | | |
| | | |
| | | REGISTER(To:U) |
| | |---------------->|
| | | 200 |
| | |<----------------|
| | | |
| | | |
| Get(U) | | |
|---------------->| | |
| Get-Resp(U@W)| | |
|<----------------| | |
| INVITE(To:U) | | |
|--------------------------------------------------->|
| | | INVITE(To:U) |
| | |<----------------|
| | | |
なんじゃこりゃー。やめてくれー。
最後に、「シーケンスイメージ2」を発展させた「シーケンスイメージ4」
Peer X Peer Z Peer Y Peer W
| | | |
| | Put(U@W) | |
| |<---------------------------------|
| | Put-Resp(OK) | |
| |--------------------------------->|
| | | |
| | | |
| | | REGISTER(To:U) |
| | |---------------->|
| | | 200 |
| | |<----------------|
| | | |
| | | |
| INVITE(To:U) | | |
|---------------->| INVITE(To:U) | |
| |--------------------------------->|
| | | INVITE(To:U) |
| | |<----------------|
| | | |
このあたりから、みんなに疲れが見え始める。
このシーケンスイメージの議論の簡単なまとめは、以下。
- とりあえず、図の"Peer Y"と"Peer W"の位置は逆にするべき
- シーケンスイメージ1は、何がしたいのかがわからない
この後、NATやセキュリティの説明もあったのですが、「P2PSIPだめだ」という空気が広がってて、「なぜだめか？」「どうだめか？」という話が盛り上がりました。
- 無理矢理DHTとSIPをまぜていて、それぞれの利点を失っている
- 重要な課題は、スコープ外または先送りにして、本当に実装できるのか疑問
- プロトコル設計ばかり先行して、実装や実際のサービスを無視している様に見える
ということで、「この場で、正しいP2PSIPを作って提案してみますか？」という半分冗談も出してみましたが、kibayosさんから「それ、もうPIAXでやってますけど」という発言が出て確かにそうだと納得。
http://www.piax.org/
私個人の意見としては、Skypeの成功(?)をきっかけとして、P2P, DHT, オーバーレイなどの流行語を、オープンアーキテクチャとしてIETFで議論したら面白そうだと誰かが思いつき、比較的親和性が高そうで良くも悪くも盛り上がっているSIPとくっつけるとみんなの注目を集められそうだと考えたのかなぁと（そして、現にIETFでも、この勉強会でも人が集まっているので、その考えは成功している）。
私としては、現在やっている開発に取り入れられるか？と微かな期待を持っていたのですが、しばらく静観することにしました。
でも、P2PSIPをネタにして、様々な分野の有識者の意見を聞き、議論できたのは非常に楽しかったです。
draft-zheng-p2psip-diagnose
P2PSIPの上で、pingやtracerouteと似た機能を提供することにより、経路到達性の確認が出来るようにするI-Dです。
pingに似たシーケンスイメージ。
Peer-1 Peer-2 Peer-3 Peer-4
| | | |
| (1).Echo Request | | |
|------------------->| | |
| | (2).Echo Request | |
| |------------------->| |
| | | (3).Echo Request |
| | |------------------->|
| | | |
| | | (4).Echo Response |
|<-------------------|--------------------|--------------------|
| | | |
Figure 4 P2PSIP Ping example
tracerouteに似たシーケンスイメージ。
Peer-1 Peer-2 Peer-3 Peer-4
| | | |
| (1).Echo Request | | |
|------------------->| | |
| | (2).Echo Request | |
| |------------------->| |
| (3).Echo Response | | |
|<-------------------| | |
| | | (4).Echo Request |
| | |------------------->|
| | (5).Echo Response | |
|<-------------------|--------------------| |
| | | (6).Echo Response |
|<-------------------|--------------------|--------------------|
| | | |
Figure 5 P2PSIP Traceroute example
これまた議論が紛糾。
- 下の仕組みが何も決まっていないのに、上の仕組みを先に決めても動くわけがない
- 上の仕組みを先に決めて、下の仕組みをそれにあわせるということなのか？
- オーバーレイでは、送信元や途中経路などを隠蔽するのもセキュリティ的な目的の一つなのに、tracerouteできたら意味がなくなる
私としては、K井さんの次の言葉が妙に納得でした。
Don't Panic!「P2P SIP勉強会(2008/8/10)」
先週、P2P SIP勉強会第二部 "P2P2PSIP読み下し" から参加しました。
P2P SIP勉強会 第九回勉強会議事録
http://www.p2psip.jp/ja/index.php?title=%E5%8B%89%E5%BC%B7%E4%BC%9A/%E7%AC%AC%E4%B9%9D%E5%9B%9E%E5%8B%89%E5%BC%B7%E4%BC%9A無印吉澤 [P2P][SIP]第9回P2P SIP勉強会のお知らせ
http://muziyoshiz.jp/20080731.html
本家議事録には、第二部の資料とビデオはあったけど議事録がなかったので、私的メモとして書いておきます。
結論としては、「インターネット関連に絡むんだったら、以下は嗜もう！」ということでした（違）。
Don't Panic!
P2P2PSIP (draft-kaplan-sip-four-oh-00) 総論
http://www3.tools.ietf.org/id/draft-kaplan-sip-four-oh-00.txt
2008/04/01に発行された、いわゆる "Joke draft" です。
SIPを知っている人が集まって、酒のつまみにするのにこんなにうまい肴だったとは！
このP2P2PSIP(=SIPv4)、一見実装したら本当に動きそうなところが怖い。
そのくらい技術的にも気合い入っている上、今のSIPv2(rfc3261 and more)への皮肉たっぷりというのがたまらない。
SIPv2からの変更点
特に私がぐっときたのが以下。
- method廃止
- 全てINVITEとその最終応答のみで行う [1.1.]
- REGISTER, UPDATE, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PUBLISH 全部廃止
- 今のSIPの複雑度合いを考えると、微妙に本当にその方が良いのではないか？と思ってしまう自分がいたりする（苦笑）
- 暫定応答(1xx)廃止 [1.1.]
- Proxy廃止 [6.]
- 全てB2BUAで中継転送も行えば、シンプルな実装になる
- そうかもしれないけど、そうかもしれないけど、やめてくれー
- 全てB2BUAで中継転送も行えば、シンプルな実装になる
- SIPSS-URI (SIP Secure Saving -URI) [9.]
- 応答コードは、200, 300, 400, 500, 600, 700(!)のみ [7.2.]
- SIPv4では、「UASがどういうときにその応答コードを送るべきか？」という視点ではなく、「UACがその応答コードを受信したときに、何をすべきか？」という視点で応答コードを定義する
- うーん、確かにそのとおりかも・・・
- SIPv4では、「UASがどういうときにその応答コードを送るべきか？」という視点ではなく、「UACがその応答コードを受信したときに、何をすべきか？」という視点で応答コードを定義する
- Priorityヘッダ廃止 [10.3]
- 全ての人が、自分の呼は重要だと考えているから
- あはははは、そりゃそうだ
- 全ての人が、自分の呼は重要だと考えているから
- Fork廃止 [11.]
- HERFP[RFC3326]とearly mediaの問題の原因となっているため
- その代わりに、KnifeとSpoonを導入
- もう、絵が最高
- 暗号化には ROT26,ROT94,ROT256 を利用 [17.]
- 鍵の共有が不要で、暗号化"されているように見える"
- 将来的には 3ROT26,3ROT94 もサポート
- ROTはシーザー暗号ってやつですな。ROT25ならアルファベットを25個ずらして、"IBM"が"HAL"になる
- ROT26はもちろん "A" -> "A" ですね
- 3ROT26は、3DESも絡めたジョークなんでしょうね
NAT関連
同じく、私がぐっときたところ
- 参考文献：ICE
- draft-ietf-mmusic-ice-129.txt, October 2017.
- 現在のICEの版数は19で、既に初版から5年近くやっている上に、ページ数も119ページと巨大なものになっていることへの皮肉ですね
- この先10年近くたってもまだdraftという痛烈なジョークが最高です
- draft-ietf-mmusic-ice-129.txt, October 2017.
- FIRE (Fast Interoperable Relay Establishment) [14.1.]
- ICEが複雑なので、その置き換えとして考案
- 事前ネゴは複雑なのでやめて、NATを通りそうなものを全て送って、通ったらOK
- 明らかにICEをFIREで溶かすっていうところから入っているよな
- TWIST (Traversal With Internet Server Transport) [14.3.]
- "do unto others as you would have them do unto you （自分にしてもらいたいことは、ほかの人にもそのようにしなさい）"
- 今度は聖書ですか・・・
- "do unto others as you would have them do unto you （自分にしてもらいたいことは、ほかの人にもそのようにしなさい）"
銀河ヒッチハイクガイドネタ
銀河ヒッチハイクガイドは、1978年にBBCラジオドラマ「銀河ヒッチハイクガイド」として、ダグラス・アダムスが脚本を書いたものが、小説化されてベストセラーになったものらしいです。
もう、[Page 4] にて "DON'T PANIC" だけで1ページ使ってますからね。
このネタ満載です。
- 全体ページ数が42ページ
- answer to life, the universe, and everything = 42
- http://www.google.co.jp/search?rls=ig&hl=ja&q=answer+to+life%2C+the+universe%2C+and+everything&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=
- 勉強会開始前に「42ページもあるJoke draftって凄いですよねー」と何気なく言ったら、外山さんに「いいフリをしますねぇ」と言われた
- ページ数がネタになっていることを知って、絶句
- draft-ietf-sip-hitchhikers-guide (著者：Jonathan Rosenberg) も実は42ページと聞いて、更に絶句
- draft-ietf-sip-hitchhikers-guide の "1.Introduction" に "Don't Panic" と書いてあるわ、参考文献の42番目に"The Hitchhiker's Guide to the Galaxy"が入っているという話でもう降参（読んだことあったのに、全く気づかなかったよ・・・）
- Max-Forwardsのデフォルト値も42
- answer to (以下略)
- Authors' Addressesにも小ネタ
- Springfield, USA, Earth Mark-I (mostly harmless) Galactic Sector ZZ9 Plural Z Alpha
- "ほとんど無害"な"破壊前の地球"を明記してありますね。"宙区"まで含んで
- Springfield, USA, Earth Mark-I (mostly harmless) Galactic Sector ZZ9 Plural Z Alpha
恥ずかしながら、私はこの本の存在を今回の勉強会で初めて知りました。
で、勉強会の帰りに早速買って読みました。
今回の勉強会での一番の収穫と言ってもいいでしょう（笑）。
EeePC + EM = 100yen 購入を本気で悩んでみた
結論：買わない
ちょうど、「新しいノートPC」と「外出先でも常時接続環境」が欲しかったんです。
それにはこのセットは非常に魅力的。
なんたって、初期投資が100円！！
http://www.emobile.jp/cgi-bin/press.cgi?id=561
http://www.rbbtoday.com/news/20080709/52652.html
で、勢いで買っちゃっても良いと思ったのですが、落ち着いて本当にお得かを計算してみたんです。
明確な制約条件としては、EMを2年間解約ができないので、そのリスクを背負う分は得をしたいと考えたわけです。
情報を整理してみました。
まずは、今回の100円になるプランのEeePCの通常価格とEMのデータプラン料金。
- EeePC4G + D02HW
- 特別価格：100円
- スーパーライトデータプラン にねんMAX
- 基本料金：2,900円/月 (23,825パケットまでの無料分含む)
- 上限料金：6,880円/月
- 制約条件：2年間の解約不可(だとおもうけど、上のEM報道発表には明記されていない)
- 参考資料：http://www.emobile.jp/cgi-bin/press.cgi?id=561
これに対して、「スーパーライトデータプラン にねんMAX」とほぼ同等の通常プランは以下。
- EeePC4G
- 現状最安：37,900円
- 参考資料：http://kakaku.com/item/00200916375/
- D02HW
- 通常価格：8,980円 (いちねん契約時)
- 参考資料：http://kakaku.com/item/00782010166/
- スーパーライトデータプラン＋年とく割
- 基本料金：1,000円/月 (23,825パケットまでの無料分含む)
- 上限料金：4,980円/月
- 制約条件：更新月以外の契約期間中の解約は契約解除料3,150円がかかる。
- 参考資料：http://emobile.jp/charge/price-list.html
基本金額と上限金額それぞれで、今回発表された100円プランにした場合としなかった場合とで2年間に支払う金額を算出してみました。
- 100円プラン
- 基本金額パターン： 2,900円/月 x 24ヶ月 + 100円 = 69,700円
- 上限金額パターン： 6,880円/月 x 24ヶ月 + 100円 = 165,220円
- 通常に買った場合
- 基本金額パターン： 1,000円/月 x 24ヶ月 + 37,900円 + 8,980円 = 70,880円
- 上限金額パターン： 4,980円/月 x 24ヶ月 + 37,900円 + 8,980円 = 166,400円
・・・2年の制約条件をつけても、1,000円しか得をしないんですねぇ。
これじゃあ、端末の料金を毎月1,900円ずつ通信料という形で上乗せされた、ただの分割払いですよね？
この100円プランを選択するのだったら、制約条件の少ない通常購入パターンにした方がよいというのが、私の結論です。
インパクトのあるプランでかなり心が動いたので、ちょっと残念〜。
RTPいらねぇじゃん「SIProp勉強会(2008/7/18)」
久しぶりにSIPがテーマになったSIProp勉強会に参加してきました。
SIProp勉強会TopPage
http://www.siprop.org/ja/2.0/index.php?%B3%AB%C8%AF%2F%A5%B3%A5%DF%A5%E5%A5%CB%A5%C6%A5%A3%A1%BC%2F%CA%D9%B6%AF%B2%F1
XConnectの中の人である武藤さんをメイン講師として、世界的なVoIPの相互接続実現を狙うXConnectの技術も含めた現状の説明を聞き、ひとしきりSIPについて熱く議論を交わしました。
その後、「5分だけ時間ちょうだい」と話始めた首藤さんの報告により、「RTP(SIPも？)いらねぇじゃん」という雰囲気になって飲みに行きましたとさw。
XConnectによる世界的なVoIP相互接続の実現 (by. 武藤さん)
中の人の武藤さんによるXConnectの解説。
H.323, SIP/1.0(RFC2543), SIP/2.0(RFC3261), その他様々な仕様や規格が非常に多くあって、実装ごとの方言も非常に多いVoIPの相互接続性は非常に困難だというのがこの分野での常識になりつつある気がします。
そんな中で、XConnectの提唱するVoIP相互接続の実現手法は、「XConnectとの同盟型モデル」ということです。
つまり、XConnectをスター型の中心点におき、XConnectとさえ相互接続性を担保すれば、他のVoIP事業者との間は、シグナリングやメディアの変換も含めてXConnectが請け負ってくれるということみたいです。
以下、私がメモったQ&A。
- Q. SPIT対策を売りにしていたが、具体的にどのような対策が行われている？
- A. SPITだと判定される閾値を越えたユーザIDを、収容している事業者に警告として通知する機能がある。そのユーザIDを自動的に使用不能には現状はしていない。
- Q. 「XConnectがシグナリングとデータの両方のセキュリティを提供」という話があったが、具体的にどのようなセキュリティを提供しているのか？認証や暗号化は何を用いているのか？
- A. 今は資料がないため、次回までの課題にさせて欲しい。
- Q. 日本国内での接続会社はどのくらいあるか？
- A. 夏ぐらいに発表すると言う話を聞いている(「もう夏ですけど」という自分つっこみありw)
- Q. 現状のシステムで、どれだけのアカウントを収容しているのか？
- A. 詳しくは言えないが、億単位。 (一同感嘆)
ひとしきり技術も含めた議論で盛り上がったのですが、「日本ではどういう形で広めていくのか？」という質問に対して、武藤さんが渋い顔をされていたのがちょっと印象的でした。
個人的な感覚としては、NやKがこういったものに喜んで接続するとはとても思えないんですよね。むしろ、自分たちでそのポジションをとりたいと考えていると思うので・・・。と、おまえが言うなと言われそうですが m(_ _)m。（2008/7/20追記）
参考：XConnectページ
http://www.xconnect.net/
http://www.xconnect.net/languages/japanese/jp_4.htm
CEO のインタビュー（英語）
http://www.xconnect.net/assets/GTBReprintXconnect.pdf
第4回 CKP 研究会報告 (by. 首藤さん)
第4回 CKP 研究会にて、IIJぶんじ氏曰く、
「計測結果、WM/Realの通信は既に 89% が TCP(HTTP含む)」
その場で交わされた意見
- HTTP万能論がますます激しくなっているな
- スタックレベルで様々な実装が既にあるから、アプリの実装がHTTPは非常に楽なんだよね
- 技術屋としては負けている気がするが、もはやコストとスピードを考えたらUDPとか言わずにHTTPで統一して作った方が良いのかもしれない
- そんなこと言ったらもはやRTPとかいらねぇじゃん
懇親会
講師の武藤さんが帰られてしまったのですが、Oさんが懇親会から参戦。
なぜかクロスセッションが複数できて、それぞれで熱い議論が交わされるという面白い状態に突入。
私が参加した議論は、
- Nさんの研究苦労話
- OさんとNさんのドロネーな出会い
- 日本の教育問題
- 博士後期課程の是非について
- 飲み会の一本締めについて
参加者覚え書き
- のりつなさん (主催)
- NiCT Mさん (会場アレンジ)
- XConnect 武藤さん (講師)
- ウタゴエ首藤さん (サブ講師(?))
- 無印吉澤さん
- 外山さん
- Oさん
- Kさん
- Nさん
- Oさん (懇親会から参加)
- 私
最も大きなRFC
ふとRFCを読んでて思った。
・・・一番大きなRFCはどれなんだろう？
仕事柄、RFC3261 SIP2.0 が最も身近なんですが、まだそれを越えるRFCを見たことがなかったんです。
少しgoogle先生に聞いてみたけど、それらしき情報がすぐには見つからなかったので、IETFのrfc index を sed & sort してみることにしました。
$ wget http://www.ietf.org/iesg/1rfc_index.txt --00:57:18-- http://www.ietf.org/iesg/1rfc_index.txt => `1rfc_index.txt' Resolving www.ietf.org... ***.***.***.***, ****:****:****:****::**** Connecting to www.ietf.org|***.***.***.***|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 880,636 (860K) [text/plain] 100%[==============================================>] 880,636 199.09K/s ETA 00:00 00:57:23 (196.84 KB/s) - `1rfc_index.txt' saved [880636/880636] $ sed ':loop; N; s/\n \+//; t loop; s/[^0-9].\+TXT=/@/; s/[ ,b].\+$//g; s/^[^0-9].\+$//g' 1rfc_index.txt | sort -rn -t '@' -k 2
さて、結果は？！
4949@867626 3261@647976 3530@600988 2801@598794 3720@578468 2911@575805 1166@566778 2626@547560 1583@532636 2178@495866 (・・以下略)
我らがRFC3261は、第2位でした。
そりゃあ、それより大きいRFCを見たことがないわけだよなぁ・・・。orz..
今回の sed コマンド解説
今回少しトリッキーなことをしたので、sedについて調べたことをまとめておきます。
興味がある人だけ読んで下さい。
今回のsedコマンドを分解すると、以下の様になります。
:loop N s/\n \+// t loop s/[^0-9].\+TXT=/@/ s/[ ,b].\+$//g s/^[^0-9].\+$//g
これを、command.sed とかのファイルにしてあげて、以下の様にコマンドを打っても同じ結果が出ます。
$ sed -f command.sed 1rfc_index.txt | sort -rn -t '@' -k 2
今回の 1rfc_index.txt をじっと眺めると、以下の様な構成になっていました。
RFC番号 RFCタイトル 著者名 発行日 (Format: TXT=サイズ bytes) 付加情報
今回欲しいのは "RFC番号" と "サイズ" だけなので、それ以外を削除して sort すれば、最大のRFCが見つかることになります。
以下、これを実現する上で紹介した "分解したsedコマンド" の解説です。
- 1行目 (:loop)
- 4行目の条件にマッチしたら、この行に戻ってくる様にします
- 2行目 (N)
- パターンスペースに次の行を読み込みます
- この時点で、改行コード(\n)を挟んで2行がパターンスペースに読み込まれることになります
- 3行目 (s/\n \+//)
- 1つの改行コード(\n)と、1つ以上の空白文字( \+)が連続してあったら、消去します
- 4行目 (t loop)
- 3行目の置換が行われた(t)ら、1行目に戻り(loop)ます
- ここまでのループで、行の先頭が空白文字から始まっているものは全て前の行と連結されます
- 5行目 (s/[^0-9].\+TXT=/@/)
- 数字以外([^0-9])から始まり、任意の個数の文字列の後に、"TXT="で終わる文字列を、"@"で置き換えます
- これにより、"RFC番号" と "サイズ" の間の文字を全て消し、後でsortするときのセパレータとして"@"を挿入しておくことになります
- 6行目 (s/[ ,b].\+$//g)
- "サイズ" の後ろに来る文字列が、空白文字か "," か bytesの "b" だったので、それ以降の行末までの文字を全て消します
- 7行目 (s/^[^0-9].\+$//g)
- 行頭が数字で始まらない行(^[^0-9].\+$)を、全て消します
これで後は、sortをして完了です。
気になったこと
- なぜか RFC5280 の行だけはうまく処理できずに残ってしまった
- 原因不明。教えて、偉い人。
- 他にも"0"だけの行、"("だけの行、空行が残ってしまった
- これも原因不明。教えて、偉（以下略）
- というか、もっとスマートな方法はないのか？
- わざわざ sed を使うのが悪い？・・・うーん、ごもっとも
- その他気づいたことがあったら、なんでもコメント下さい m(_ _)m
SBM研究会(2008/07/12)に参加してみました
門外漢ながら、SBM研究会に参加してみました。
http://toremoro.tea-nifty.com/tomos_hotline/2008/07/sbm_abf4.html
本当に無料かつ個人の企画した勉強会か？と思うほど、講演者/参加者の良/質ともに非常に高く、とても勉強になった＆楽しかったです。
ぜひ今後とも参加させて頂きたい＆今度はお手伝いさせてもらいたいと思っています。
いっぱい写真を撮ったので、とりあえずmixiにあげておきました。
http://mixi.jp/view_album.pl?id=17792682
よかったら見てやって下さい。
既に色々な方がサマリ/感想を書いている様ですが、私も自分の視点で書かせて頂きます。
横田さん
P2P関連の勉強会がきっかけで何度か飲みに行っていたのですが、講演を聴いたのは実は初めてでした。
とてもわかりやすかったかつ、特に私の様な門外漢にはSBMの概要や分類などが網羅されていて、非常に勉強になりました。
横田さんの講演で特に印象に残ったのは以下。
- del.icoi.us 成功の最大の要因は、"日々のツール" になったこと
- 一般のSBM利用率7%だけど、この会ではほぼ100%って、どんだけ濃い会だよ！
宮田さん/佐々木さん
私も技術が好きな人なので、研究面の話も聞けてお得感満点でした。
論文の紹介も非常に多かったので、SBMについて研究開発を行われる方は、資料DLがおすすめです。
http://homepage3.nifty.com/toremoro/study/SBM.html
宮田さん/佐々木さんの講演で特に印象に残ったのは以下。
- レコメンド目的にはタグの文字列はあてにならん → Anti-Folksonomy
- 顔文字や独自階層や「こりゃひどい」などでは分類にならん
素人考え的には、それらのタグの種別によって、分類手法を変えるということはできないのかなと思ってみた。
星さん
7/4にサービス開始した、コモンズマーカーの紹介。
BC4世紀のソクラテスの言葉から、2005年のはてなブックマーク登場までのSBMの(?)歴史を解説し、それを踏まえた上でかつ元編集者の視点からSBMの発展系を考えたという話の流れは説得力もあり、非常に面白かったです。
さっそく私も登録して少しだけ使ってみました。
現状の簡単な感想としては、以下です。
- 登録からインストールまでが非常に簡単
- 使い勝手や操作性もさくさく動いてストレスなし
- 右上にflashの広告が出るページだと、そのページのタイトルにつけられたコメントに広告がかぶってうまく見えない
もうちょっと使ってみて、またレポートします。
井口さん
私もP2P関連を仕事にしているので、非常に興味を持って聞かせて頂きました。
講演後に井口さんに質問させて頂いた内容も踏まえて、P2P-SBMについての私的な利点欠点は以下です。
- 利点
- サービス提供者からの情報漏洩により、多数のユーザへの被害がでる可能性を減らすことができる
- サービス提供者側設備が最小になることにより、より収益のあげやすいビジネスモデルが考えられる（かもしれない）
- 欠点
- 通常のSBMよりも現状は仕組みが複雑になり、トータルコストとして本当にやすくなるかが疑問
- NAT/FW越えによって、さらに仕組みの複雑性が増す
- ブラウザ以外のアプリケーションのインストールが必要になり、ユーザの導入障壁が高い
現状は欠点の方が多く＆強くみえますが、これを越えるのは技術ですよね。そして困難な課題を技術で越えられたら、新しいビジネスチャンスが待っていると思いますので、継続議論させて頂きたいと思いました。
小島さん
こちらも比較的研究よりなお話で面白かったです。
SocialMediaMarketに関しては、現状のままでは変に友達関係を引き継がれたり、そのままレコメンドに使われたりというのは抵抗がありますが、発展的なサービスを作る種になりそうな予感がしました。
小島さんの講演で特に印象に残ったのは、以下。
- GoogleのSocialGraphAPIを使うのは負けた気がする
- SocialMediaMarketはまだまだこれからの技術だが注目していく
神林さん
これからのSBMの展望に関して、「俺もよくわからん」というので爆笑でした。
今回の勉強会は「ウケ」がとれる講師ばっかりだったのですが、その中でも一番の爆笑だったのでは？と思いました。
様々なSBMサービス開発の "泥臭い話" が、俺もこういうの作ってみたいなぁと思わさせられちゃいました（神林さんの思うつぼ？）。
ツール類に関しては、また時間を見つけて使ってみてレポートしようと思います。
懇親会
一人一分自己紹介では、名前だけで「おー、あの人が！」という歓声があがったり、「ブログでは3日に1回アホなことを書きます」といって爆笑させる方もいたり、出会い系サイトの人事の方などもいてとても楽しかったです。
こういう会では、やっぱり懇親会も出なきゃ損ですよねー。
