« 2005年3月 | トップページ | 2005年5月 »

2005年4月の15件の投稿

2005.04.30

[P2P]GWの予定

GWですが、ある程度時間が確保できるようなので、次のことを行う予定です。

・某講演、Skype勉強会ためにNAT越えに対する勉強・資料作成
・Blog、P2P勉強会で好評だったDHT入門を再構成してHPに掲載する
・5/14(土)開催の「Talking Night ~SNSを考える」でP2P-SNSについての
 プレゼンをするための準備(プレゼン資料はGW中に掲載できればいいなぁ。)
「Talking Night ~SNSを考える」
http://mixi.jp/view_event.pl?id=854917

明日は茨城方面にでかけて心身ともにリフレッシュする予定です。

| | コメント (0) | トラックバック (0)

[SNS]SNSはハブを作り、オフ会はクラスターを加速し、Blogは信頼関係を維持する

SNSとしては専らMixiを利用している。そういえば、最近マイミクが100人を突破しました。
さて、SNSで知り合った人というのが最近多くなっている。その多くは実際に会った人が多い。

今のことをもうちょっと補足する。知り合いが出来る過程というのは大抵次のとおりになると考えている。

[1]SNSで幾つかのコミュニティに参加する。
[2]そのコミュニティで発言をすることで、他のコミュニティ参加者が自分の存在を知る。
[3]他のコミュニティ参加者の一部の人は自分のBlogを見る。そこで印象が深くなる。
[4]いくつかコミュニティで発言をすると、そのコミュニティの中心メンバが自分の存在を気になるようになる。
[5]オフ会に参加する。
[6]オフ会でコミュニティ中心メンバと話をする。それをきっかけにその中心メンバと話している他のコミュニティとも知り合う事が出来る。
[7]自分のblogをきっかけにお互いの印象が深まる。
[8]マイミクが増える。
[9]Blogのコメントをして信頼関係を維持する。

こんな感じだろうか。

SNSの存在により、各コミュニティに中心メンバができる。この中心メンバがコミュニティのハブとなり、他のメンバと知り合うきっかけを促進させる。このときにはリアルにあってない同士がマイミクになる事はレアケースと考えられる。
(これはもしかするとコミュニティやその人の性格に依存する事が多いのかもしれない。積極的にコミュニティに発言している人、つまり中心メンバはヴァーチャルでもマイミクが増加するだろう。)

実際にマイミクになるにはリアルで会った時、つまりオフ会を通してだ。このときコミュニティの中心メンバが他の人を紹介するケースが多い。信頼できる人(中心メンバ)が紹介する人は、ヴァーチャルでは知らない人であっても受けいることができるのだろう。それによって、中心メンバ(ハブ)を通してクラスター化が加速する。
少なくとも私の世代(20台後半~30台後半)はリアルで会わないとその人を信用するのは難しいということのなのかもしれない。もっと若い世代になればリアルで会わなくてもマイミクがどんどん増加する、そんな時代になるのかもしないが。

さてSNSでのBlogは2つの効能があると考えられる。それは
[1]他メンバからの印象を強くする
[2]マイミクの信頼関係を強化する

まず[1]については知り合う初期段階で起きる事だ。日記を通してその人の趣味・性格がわかり、記憶に残る。これによってコミュニティでの発言、オフ会での出会いに対して印象が深まる。
私はむしろ[2]を重要視する。マイミクへのBlogへのコメントをつける事で、お互いコミュニケーションでき信頼関係を維持できることである。基本的には人間というのはコミュニケーションの数が多いとより親密になるらしい。

まとめると
[1]SNSのコミュニティ:知り合う下地を作る
[2]SNSのオフ会:多くの出会いの提供の場
[3]SNSのBlog:知り合った後の良好な関係を維持する

ということになるだろう。

SNSは今後も色々なタイプが生まれるだろうが、コミュニティ・オフ会・Blogが上手く連携して促進する機能を持たないと成功しないだろう。

| | コメント (0) | トラックバック (0)

2005.04.27

[Skype] Skype Network Administrators Guide公開

Skype Network Administrators Guideが公開されました。
(情報はアリエルネットワークの岩田さん経由。)
http://www.skype.com/security/guide-for-network-admins.pdf
レビューは近日中に行います。

| | コメント (0) | トラックバック (0)

2005.04.25

[日記]業務の回し方

私の担当は技術面の調査からサービス仕様へのコメントまで幅広く行う。ネットワーク構成を検討し、時には検証もする。機器の設定ファイルをチェックする時もある。いわゆる「なんでも屋」に近いかもしれない。

自分の仕事に一番近い業種といえば多分ネットワークSEなんだろう。ネットワークSEという分野も幅広くて、物理レイヤがメインのところもあれば、アプリケーションレイヤまで見るところもあるそうだ。またネットワークSEといっても関連部署の調整を行うところもあるとのこと。これは今の業務とかなり重なっているケースだ。

最近考えるのは、多数の部署から課題処理の要望があって、それについてどこまで自分が関わるべきかということである。業務分野が広い分、自分がその業務でないとはっきりいえないことも多い。(また自分の担当業務と整理されてない事も多い)といってその依頼を全部やってしまうと、とても自分では処理しきれない。他の人はこういうアバウトな境界の業務をどうこなしているんだろう?

上記に関する難しい事例として(それも実際には頻繁にある)挙げられるのは、ある課題をクリヤしないと先に進まないのだが、誰もがそれについて自分の業務でないと言う場合だ。一番の落とし処は「調整担当」となる私になるのでは、ということを主張される場合も多い。悩ましいところだ。
今後は課題の優先順位や分野・質によって[論理的に]仕事を断る事をうまく実践しないといけないと思った。

もうひとつ考えているのは自分のスキルアップについてだ。自分の業務は多くのサービスの案件が同時期にある場合が多く、ひとつの事にじっくり腰を据えて取り組む事が難しい。そうなると調整がメインになってしまい、肝心の技術力習得がおろそかになってしまうことが多い。ここ最近自分のスキル不足を痛感している。
多数の業務をこなしていても、核となるトピックをきちんと押さえる能力を身に付けないといけない。
本当は技術研修を受けたり、実際に機器をさわれる時間を確保できれば良いのだが。。。

機会があったら他社のネットワークSEさんと会って、業務の回し方について聞いてみたいです。

| | コメント (0) | トラックバック (0)

2005.04.24

[P2P]Skype勉強会について

先日お知らせ致しましたSkype勉強会ですが、講師について下記の方と講師を調整中or調整予定です。

・某P2P関連の方
・某副社長

どちらもskype関連の第一人者です。あとは私も時間があったら講演(多分技術面。DHTとかNAT越えとかかな。)するかもしれません。
会場、日時がまだ未定なので上記講師陣が確定していない事に注意して下さい。
本当はlivedoorの関係者やskype端末作っている人も呼びたいんだけども、誰かコネないかな~。あとは通信アナリスト、マーケッティングしている人とか。
skype関連で講師を推薦(自薦を含む)して頂ける方ご連絡をお願い致します。

※会場についてもこれから確保する予定です。会場を調整して頂ける方いらっしゃったらこちらもご連絡をお待ちしています。

| | コメント (0) | トラックバック (0)

2005.04.17

スーパー歌舞伎初体験。

先日、彼女の誘いでスーパー歌舞伎を見ました。出し物は「ヤマトタケル」で、スーパー歌舞伎を最初に興したときの出し物だそうです。(その後改訂しているようですが。)

歌舞伎は高校の時に国立劇場で見た1回きりでそれ以来全然見てませんでした。その時には確か解説イヤホンを渡されて聞いていたので、意外に面白かった印象があります。
そういえば古典芸能というと雅楽(舞を含む)を聞いたことがあるのですが、こちらはとても関心があったにもかかわらず、動きの起伏が小さいので必死に眠くなるのを抑えた覚えがあります。もう一度見たら印象変わるのかな。。。
能や狂言も一度みたいけども、どんなものなんでしょうね。

さて、話題を戻してスーパー歌舞伎ですが、これが私の「歌舞伎」に対するイメージを払拭するのものでした。確かに演出や言い方、花道、型等歌舞伎の影響は大いにあります。が、次のように歌舞伎とは違う特徴があると感じました。
[特徴]
・言葉がわかりやすい現代語
・音楽が西洋楽器による録音演奏(一部和楽器による演奏もあり)
・演出が派手(舞台セットが壊れる、チャンバラ、樽を投げつけるシーン等)
・舞台装置を巧に使う(ライティング、回転盤、宙吊り、ドライアイス等)
・役者の身振り等動きが多い

私のような世代の人でも充分たのしめるので、一度行ってみるといいでしょう。こういうのを見ると、歌舞伎もチャレンジしてみたい!と思いますね。

ところで、このスーパー歌舞伎ですが私は歌舞伎の素人だったので拍手するタイミングがイマイチつかめなかったのがちょっと残念でした。演技中に何回かキメのポーズがあって、その直後に拍手をすればカッコよかったのに、なかなかできないものです。次回は是非拍手をキメたいですね。

| | コメント (0) | トラックバック (0)

2005.04.14

[P2P]P2Pプロキシはどこで使うか?

最近の国内外のニュースを見ていてぼんやりと思ったのだが、おそらくP2Pプロキシというのは日本国内というよりも国外で使われるべきものかなと考えました。

国によっては情報の入手先が規制されていて、特定のWEBページなどにはアクセスできないとのこと。情報が色々な経由から入って客観的に判断することが必要なのに、そのような規制があるのは情報時代の現在となっては悲劇的だ。

世界中にP2Pプロクシユーザがいて、閲覧するWEB内容やURLが暗号化されていれば、国によってその通信を規制をするのは難しいし、ユーザも匿名の中で安心して情報を入手できるんだろうな、と。結果的にユーザは多くの情報を元にそれを自分自身で客観的に判断することができる。最初はそのような判断をするのは難しいかも知れないが。。。P2Pプロキシで有名なTORが米海軍で作られたのは、もしかして単なる軍事利用という意味を超えてそこまで狙っているのかもしれない。

#参考#
Torとは?
P2P匿名プロキシサーバのTOR
Torは串弾きを潜れるか?

以前も書いたようにDHT(分散ハッシュテーブル)を使えば簡単に、そして強力な匿名性を取り入れたP2Pプロキシが出来る可能性がある。

もしかするとP2Pは世界の流れを変えてしまう、そんな強力な技術なのかもしれない。

| | コメント (1) | トラックバック (0)

2005.04.12

[P2P]ファイル交換のUDP使用の懸念点

ある掲示板において、とあるファイル交換ソフトのUDP化が議論されているようだ。時間がないので残念ながら内容自体はあまり読んでない。

そもそもなぜUDP化するのだろうか?すぐに思いつくのは次の2つだ。

[1]NAT、ファイアウォール越え通信が可能となる
[2]通信元IPアドレスが偽造できる

[1]についてはこのBlogでも何度も書いてあるがUDP HolePunchingという技術を使う事が考えられる。
この技術によってルータなどのファイアウォールの設定をいじる必要はない。これはSkypeと同じことだ。

問題は[2]だ。
通常ファイル交換で行われる通信はTCPだが、これは送信元アドレスを偽造するときちんとした通信はできない。
もちろん、DDoSのように「わざと」送信元アドレスを偽造して送信先ノードに負荷を掛ける方法はTCPでもあるが、コネクションを張ることができないのでそれ以上の通信はできない。

UDPを使えば、送信先にあるポートで通信する事さえ制御してあげれば、UDPで送信元アドレスを偽造してファイルを伝達することは「理論的には」できる。

これを発展させると、ある時間やタイミングなどで送信元アドレス、ポートを変化させて誰から通信が来ているかサッパリ分からなくする事は可能だ。

だが、このことはとても大きな問題を抱える事になる。

まず、UDPはそもそもパケットロスをあまり考慮していない通信に向いている。例えば音声通信など多少のパケットが落ちても、遅延をさせない通信などに有効だ。
インターネットの世界は一般にパケットロスが発生しやすい。ファイル情報は情報が一部でも欠けるとうまく再生等が出来ない場合があるので、そうなると何度も再送処理(これはアプリケーションで処理する)が発生する。
そのためネットワーク全体に負荷がかかることがある。
このような再送処理を極力避けるためには例えばストリームでよく使われるデータ補完機能「FEC」などを利用する事が考えられる。とは言え、ある程度パケットロスが大きくなるとFECだけではうまくいかなくなる。

UDPはトラフィックを「自分の好きなように」に吐き出すことができる。これはTCPにようにフロー制御がないためである。このことはネットワーク環境や相手のノードにお構いなくトラフィックをドバーと出す事になる。それはネットワーク帯域を食い尽くすことになり、ルータなどにも大きな負荷がかかり、結果としてネットワーク全体に大きな影響が出る可能性がある。ストリームのようにTCPで制御の通信を行うという手はあるし、もしかしたらUDPパケットの中に制御用信号をいれることも可能かもしれないが。

今のことをもっと発展させてみよう。注目するのはUDPが送信元アドレスを詐称でき且つ大量のトラフィックを流せる事だ。これは基本的にDDoS攻撃をしていることに近い。
TCPの場合、相手がいなければOS側でその通信を終了する事が考えられる。(リトライはあるかもしれないが。)
だが、UDPは流しっぱなしの通信なので、アプリケーション側で勝手に大量のトラフィックを無差別に吐き出す事もできる。
こうなると、以前私が可能性を指摘していた「広域ネットワーク型DDoS攻撃」となりうる。そのストーリはあるきっかけで(例えばウィルス感染等。若しくは意図的に開発者がその機能を入れ込むかもしれない。)で感染ノード(ゾンビ)が無差別にUDPトラフィックを吐き出してしまい、バックボーンを含めネットワーク全体がダウンしてしまう、という恐ろしい事態が発生する事だ。それも誰が原因だか不明のまま。。。
アプリケーションには通常バグがあるから上記なことは充分考えられる。

ではもしこのような通信を制御するにはどうすれば良いのだろか?
まず、詐称対策だがISPは自分で払い出しているIPアドレス空間以外の送信元アドレスについては通信をブロックする事が考えられる。もうひとつはこのようなファイル交換のUDP通信は大きな帯域を消費するので、長時間そのような通信をしているものをブロックする事が考えられる。これは現在売られているP2P帯域制御装置を改良すれば可能と考えられる。または単純だがストリームなど特定のUDPポート以外はルータ、ファイアウォールで塞いでしまうのも手だろう。

P2Pによるトラフィックは現状ISPに非常に大きな負担を強いているが、UDP化によって、ネットワークにより深刻な事態が起きるのかもしれない。

| | コメント (0) | トラックバック (0)

2005.04.11

[音楽]シュトックハウゼンが来日するぞ!

今日は横浜でお花見でした。場所は根岸森林公園。とても風が強かったのですが、天気が気持ちよく芝生でごろりんと寝転びながらゆっくり時間を過ごしていました。よかったなぁー。

さて、久しく現代音楽ネタを書いてなかったのですが、凄いニュースが飛び込んできたので書いておきます。
前衛音楽の巨人、シュトックハウゼンが6月に来日します。

電子音楽、トータルセリー、偶然性の音楽、空間音楽等様々な手法を開拓した20世紀を代表する巨匠です。最近ではヘリコプターを4台飛ばしながら、それぞれ弦楽カルテットのメンバーを乗せ、演奏させるという奇抜なアイデアで、周りの人を驚かせています。今回はレクチャーをするということで、これは音楽ファンには絶対見逃せないイベントです!!

第21回東京の夏音楽祭2005「宇宙・音楽・心」
http://www.arion-edo.org/tsf/2005/index.jsp

シュトックハウゼンはなんと28年ぶりの来日だそうです。これを見逃すともう来日はないかも。。。
また、今回はオペラ:光(リヒト)の一部を演奏。これはシュトックハウゼンが長年作曲をしていたライフワークともいえる非常に巨大なオペラです。上演機会がほとんどないので、これも非常に貴重な体験となるでしょう。

6/23(木)シュトックハウゼンが語る「作曲家と演奏家~リヒト=ビルダーをめぐって」

来日記念演奏会:
シュトックハウゼン:リヒト=ビルダー(光=イメージ)
6月24日(金)19:00開演
6月25日(土)19:00開演
6月26日(日)16:00開演
「24・25・26日」
リヒト=ビルダー(光=イメージ)(2002年/41分)~連作オペラ「リヒト(光)」から「光の日曜日」第3場(演奏会形式)
[24日]電子音楽:少年の歌(1955-56年/14分) テレムジーク(1966年/18分)
[25日]電子音楽:コンタクテ(1958-60年/36分)
[26日]テープ上演:天使=行列~連作オペラ「リヒト(光)」から「光の日曜日」第2場(2000年/45分)
 
テープといえどもホールで本来の多チャンネルで聞くと全然違うんだろうなぁ。

20世紀の古典から委嘱新作まで:
アンサンブル・モデルン
■ 日時 : 6月28日(火)19:00開演
■ 会場 : 東京オペラシティコンサートホール:
タケミツメモリアル

シュトックハウゼン:アデュー

さてと、6月は残業できない日が多くなるなぁ。。。。今回は絶対演奏会&レクチャー行くぞ!
 

| | コメント (0) | トラックバック (0)

2005.04.09

[DHT]DHTによるデータの部分列検索の考察

DHTは部分列検索が容易ではないのだが、これについてどのように実現するのか考察してみよう。これが実現すればあいまい検索やフレーズ検索にも繋がっていくかもしれない。

つまり、「バッハ バイオリン協奏曲第2番」というデータについて「バッハ」、「バイオリン」としても検索できるようにしたいということだ。

まず基本技術としては、データを各要素に分解することから始まる。つまり、「バッハ」「バイオリン」「協奏曲」「第2番」と分解する。この技術は形態素解析という技術を使えば実現可能だ。
詳しくはここを参照して下さい。
日本語形態素解析入門

この各単語の要素のハッシュを取って、{hash(単語)、データ}というペアをNode_ID=hash(単語)に登録すれば良いわけだ。

逆に、例えばある単語が含まれるデータ(例えばファイル名)を検索するならNode_ID=hash(単語)に格納しているデータからサーチすれば良い。

ところが、この技術だと少し困った事がある。それは主に2点だ。

[1]特定ノードNode_ID=hash(単語)にたどり着いてからさらに絞り込むのに時間がかかる
[2]ある特定の単語のハッシュ値を管理するノードにデータが集中しすぎる

これについて考察してみましょう。

まず[1]については、ある程度簡単に克服できる。それはBloom Filterという技術を使う事だ。
Bloom Filterはハッシュ値を使って、データがある単語を含んでいる「かもしれない」ことを高速に判別する技術だ。詳細は
[P2P]Bloom filterの解説文~無印吉澤
を見てほしい。

Bloom Filterにおいて、あるデータの要素が格納しているかどうか判別するハッシュ列をBloom_Filter_Array()としよう。
今、あるノードNode_ID=hash(単語)に格納するデータを
{hash(単語)、Bloom_Filter_Array(データ),データ}とします。
単語1、単語2を含むデータを検索したい場合、次の手順を踏みます。

[手順1] Node_ID=hash(単語1)にアクセスする。
[手順2] 単語1、単語2がデータに存在するか確認するため、 Bloom_Filter_Array[単語1,単語2]を計算する
[手順3] Bloom_Filter_Array(データ)AND Bloom_Filter_Array[単語1,単語2]=0ならデータに単語1、単語2は含まれてないが、0以外なら含まれている「かもしれない」。

ただし、Bloom_Filter_Array[単語1、単語2]はBloom_Filter_Array(単語1) XOR Bloom_Filter_Array(単語2)を表わします。
これで高速に単語の絞込みをすることができました。

■STEP2
これではまだ、[2]が改善されていません。そこで次のような事を考えます。

ハッシュ空間H(z bit=x bit + y bit)を次のように構成します。
 ・上位x bit は hash(単語)
 ・下位y bit は Bloom_Filter_Array(データ)

今、あるデータに対してHに含まれるハッシュ値を返す関数をHash(単語、データ)とします。
まず有るデータをDHTに登録するには形態素解析をして、データに含まれる単語についてNode_ID=Hash(単語、データ)に対して{Hash(単語、データ)、データ}を登録します。これで準備ができました。

[手順1] 単語1、単語2を含まれるデータを探したい場合、上位x bitがhash(単語1)、下位y bitがBloom_Filter_Array[単語1.単語2]となるハッシュ空間Hに含まれるハッシュ値Hash(単語1,単語2)にアクセスします。

[手順2]ChordなどのDHTは隣接ノードとリンクをしています。そこで、Node_ID=Hash(単語1、単語2)となるノードから上位x bitがhash(単語1)+1,下位 y bitが0となるNode_IDのノードまでデータBloom_Filter_Array[単語1、単語2]をバケツリレーで渡します。ただし、Node_IDが管理するハッシュ空間がBloom_Filter_Array[単語1、単語2]とANDを取った時に0ならすぐにデータをBloom_Filter_Array[単語1、単語2]を次の隣接ノードに渡して手順3に行く必要はありません。あるいは更に高速化するには、自分のNode_IDよりも大きくてBloom_Filter_Array[単語1、単語2]が0でない一番小さいハッシュ空間Hを管理するノードにBloom_Filter_Array[単語1、単語2]を投げるとすればもっと良いですね。トラフィックが増えてしまいますが、上記の範囲で自分とリンクしているノード全てのデータを渡してしまうのも手です。(あるノードに対して同じデータが2回以上来たら、そのデータを無視して終了とする)
(※リクエストスピードを2倍にするなら、hash(単語1)+1,下位 y bitが0からHashが小さくなる方向にも要求をかけるのもアリです。)

[手順3]ノードが保持しているデータについて単語2があるかどうか計算します。

DHTによる部分列検索について考察しました。STEP2については一部バケツリレーを使っているので、もう少し検討すると処理スピードが高速になるかもしれませんね。なお、今回は検索した単語は2つですが、3つ以上でも同じような方法で実施できます。

| | コメント (3) | トラックバック (0)

[科学]星がない銀河があるなんて。

自然科学、特に天文学に興味がある人は多い。私は物理学専攻だったが、天文関連に携わった人を何人も知っている。天文関連の研究は観測するのも大変だが、理論を検証するのも難しいのでかなり厳しい世界だそうだ。それでも毎年多くの人が天文系の研究室に入ってくる人はとてもチャレンジブルで好感が持てます。

それはさておき、銀河というと大抵天の川など星の集まりをイメージする人が多いだろう。ところが最近星が全く存在しない銀河が発見されたと言うニュースが流れた。

Astronomers find star-less galaxy  ~BBC NEWS

大きな質量がある空間存在し、それが銀河のように回転しているが、星が全く存在しないそうだ。5000万光年先の天体でイギリスとプエルトリコの電波望遠鏡で発見された。天体名はVIRGOHI21と名づけられている。

また、興味深い点を引用。

Dr Robert Minchin, of Cardiff University, said: "From its speed, we realised that VIRGOHI21 was a thousand times more massive than could be accounted for by the observed hydrogen atoms alone.

"If it were an ordinary galaxy, then it should be quite bright and would be visible with a good amateur telescope."

とのこと。

以前から光も電波も発しない物質、「ダークマター」が宇宙の大部分を占めると言われてきたが、今回そのようなダークマターが運動している事を確認できたことはとても面白いことだ。
ダークマター

アマチュア観測家にとってはダークマターような光らない天文なんてつまらない、と思われるかもしれないけども今後はダークマターの研究が進んで宇宙の構造が明らかになるとうれしいですね。

 

| | コメント (0) | トラックバック (0)

2005.04.07

[英語]お薦め英字ニュースサイト

最近英語読解力を上げるために英字WEBページを最近継続的に読んでいる。
テクニカルな英字ページでもそれなりに読解力は上がると思うのだが、やはり色々な話題が入っているニュースサイトの方が良さそうだ。

そういうわけで色々探したところ良さそうなのはasahi.comの英字版。
asahi.com[English]
主に日本のニュースを取り上げているだけにわかりやすい。

国内ニュースとしてもう少し難しくなるとJapan TimesがWEBページを作っている。
The Japan Times Online

個人的に一番のお薦めはイギリスBBCのWEBページ。
BBC Home
ココのページの情報量は凄い。ニュースにしてもイギリス国内からアフリカ、アジアまでくまなく網羅している。さすがは世界のBBC。それもトピックも最新時事から科学までヴァラエティーに富んでいるし、なによりも読みやすい記事であるのが良い。
それと、BBCだけあってストリーミングで英語放送(それも無料)が聞けるのがウレシイ。

ちなみにCNNもニュースサイトがあります。こちらも読んでみようかなと思います。
CNN.com

*追記(2012/11)

英語力を基礎から向上したい人はVOAがお勧めです。これは英語を母国語としてない人向けのニュースサイトです。バラエティー豊かな記事で、英文は易しめにも関わらず良質な記事を書いていまvす。ポッドキャストも無料で使えます。

VOA ~Voice of America

| | コメント (0) | トラックバック (0)

2005.04.06

[Blog]BlogからVlogへ広がる世界と課題

Googleが動画を扱えるブログを開始する事は多くの人の関心を集めている。
グーグル、「ビデオブログの実験」へ--個人向けにアーカイブサービス提供 ~CNET

その前に日本でも注目すべき動きがあった。gooが動画ブログを始めたということだ。
動画でブログを楽しもう!~goo
動画ブログ開始(サンプル)

この動画Blogだがアメリカと日本では明らかにターゲットが違うと考えられる。

アメリカではデジタルビデオを所有する人間、おそらくデジタルビデオを購入する事からメインターゲットは20代~40代の家族を持つ男性だ。またビデオ編集能力がある人に限られる。これらのターゲットはインターネットのヘビーユーザと重なる。またはPCに強い関心をもつ10代後半~20代後半の男性も可能性としてはある。

しかし日本の場合(すなわちgoo)は明らかに違う。これは投稿の際に動画をFOMAなどの携帯のビデオ記録機能を使えるからだ。現在の動画記録機能の携帯を持つ人の率から考えるとアメリカより「ライト」なWEBユーザまでターゲットとして想定する事が出来る。つまり、動画Blogを書き込める人のポテンシャルは日本はとても大きいのだ。

現在、MixiやBlogで携帯からの読み、書き込みが普及している事を考えると(さらに画像を添付する事も含めて)すくなくとも日本ではこのような動画Blogがブレークする可能性は大いにある。むしろ日本固有(つまりベンダーは携帯に高機能を持たせ、それを使いこすユーザが多いこと)の文化に適した物であるとも言える。もし阻害要因があるとすれば、自分、友人が写っている動画をそのまま不特定多数に配信するのに大きな抵抗があることだろう。
そういう意味で最初は風景、食べ物、イベントの様子などがvlogのコンテンツとして集まる可能性がある。もちろん、vlogリーダ的な人が現われ、自分が出演することも考えられるだろう。この辺はBlogと同じだ。

gooの場合、動画Blogを始めたのは単なるユーザ獲得、囲い込みだけではないはずだ。戦略的にはFOMAのテレビ
電話機能を一般ユーザに根付かせる要因になると考えているのではないだろうか?(ちなみにgooはNTTグループ)
また、動画を投稿する際のパケット量も大きいから、ユーザが定額制に移行すること考えられ、これはARPUが増える事に直結する事から携帯事業者に大きな収益が見込めるだろう。もちろん、動画動向でなく、携帯で閲覧するときも同様である。
FOMAとポータルの連携を考えると、今後はテレビ電話の動画をある時間保存させ、それを特定の人だけに見せるサービス、なんてことができるのかもしれない。むしろアマチュアが撮る「動画」の性質を考えるとその方が成功するモデルだと思われる。

さて今回のニュースはヨーロッパでも大きく紹介されている。私が面白いなと思ったのはBBCのニュースである。
Google to start 'video blogging' ~BBC

この記事で注目すべき所を引用する。
Video blogging - vlogging - is still a new phenomenon but is expected to take off as web space becomes cheaper - or even free - and digital cameras become ever more sophisticated.

ここで、動画Blogのことを「vlog」という新しい用語で紹介している。WEB logが「Blog」呼ばれたように、動画Blogも「vlog」と呼ばれるがすぐにやってくるのだろうか。。。

ではvlogの世界は明るいのか?と言われると必ずしもそうではない。主な課題点を上げてみよう。

一つは明らかに動画を収容するためにポータルサイトは巨大なストレージを用意する必要があるからである。想定されるビジネスモデルとしてはある一定量以上のストレージを使う場合には有料とすることが考えられる。とはいえ、これもvlogが多くのポータルで採用されれば、mailやBlogのように無料の使用容量の拡大合戦が始まり、ポータル側が一向に収益をもたらせない結果に陥る可能性は充分にある。

もう一つは多くの人がvlogを利用すると、ポータルサイトはアップデート及びダウンロード(つまり不特定多数のユーザからの視聴)の際に非常に多くの帯域を確保する必要があるのである。これを解決するアイデアは(すくなくとも私は)見当たらない。CDNを使う事も考えられるが、対処療法に過ぎないだろう。

ただし、vlogをポータルで使わないとなると話は別だ。つまり、P2Pネットワークを使いvlogを扱うようになればトラフィックの問題は解決できる。P2Pネットワークを使い、BBS、wiki、Blogとアプリケーションは進化してきたが、近いうちにvlogもP2Pで実現されるのかもしれない。ただし、動画のファイルサイズは非常に大きいからvlogをP2Pで実現したとしたとしても、ノードの負担は今までよりも桁違いに大きくなるだろう。

ユーザ側の影響としてはPodcasting(特にSkypeによるPodcasting)が始まっている事を考えると、RSSと連動して将来の携帯端末を用いて多くのvlogを当たり前のように閲覧する時代が来るのかもしれない。そして恐らくその端末は携帯電話になるだろう。


| | コメント (4) | トラックバック (0)

2005.04.04

[P2P]P2Pの定義を考えてみる

なぜだか最近P2Pの定義について考えてみたのでメモ。

ご存知の方も多いと思うがP2Pについてはまだ明確な定義がない。漠然としたイメージはあるけども、なんだか掴みづらい、そんな感じだろう。

この問題の難しさは大局的にP2Pを見ると全てのノードが対等に見えるのに、極小的にみるとノード間がクライアント=サーバ的に振舞う事だろう。つまり見方によって2つの異なる性質が見え隠れするのだ。

そこで、こんな定義はどうだろう。

「複数のノードの集合Aがあり、Aの要素の数が充分大きくかつ各要素がAに存在する時間が充分大きければ、ノード集合Aから任意に選んだノードPは、ノードPのリソースをノード集合Aに存在するあるノードQに提供する時間が存在するシステム」

なんだか数学の定義っぽくなってしまったが(すみません、大学の専攻が物理だったので。。)、これだと上手く説明できるかもしれないですね。もうちょっと簡単にできるかなぁ。

こういう定義は意外と数学屋さんが整理するとすっきりすると思うのですが、如何でしょう?

| | コメント (2) | トラックバック (1)

2005.04.02

[DHT]クラスターの概念を取り入れたDHTの提案

先日、DHTでスモールワールドの概念を取り入れたSymphonyを紹介した。
スモールワールドを応用したDHT:Symphony

Symphonyの大きな特徴として、参加しているノード数に関わらずリンク数が同じであることが挙げられる。
逆にいうと、DHTの実装者は自分でノードが他ノードとリンク数を好きに設定できる。
ちなみにホップ数はリンク数を2k+2とすると、O([log(N)]2/k)だ。

ところで、最近ノードのリンク数について色々と考えていた事がある。
というのはDHTではリンク数がノードのよらず対称である。しかし、ノードにはCPUやメモリーなどの差もあるし、それよりも深刻なのはノードによってDHTに参加している時間は大きく異なるのである。
そのようなことを考えると、リンク数は非対称な空間を形成した方がDHT全体にとってはありがたいのではないかと。

ここでは上記の考えに従ってSymphonyを改造していこう。

1)参加するノードは他ノードと総計2k+2のリンクを形成する。リンクの仕方はSymphonyと同じ。
2)参加するノードはCPUやメモリリソースにより、リンク上限Zを決定する。
3)参加するノードはある単位時間毎にリンク数を2pずつ増やしておく。
4)ある時間が来ると、 リンク総数 (2k+2)+2p > Zとなるタイミングが来る。それ以上はリンク数は増やさない。
5)リンク上限ZはPCリソースによってゆるやかに増減可能である。それによりリンク総数がZを超えた場合には、
ある確率(P(x)~1/x,xは自分のノードからのハッシュ空間の距離)の従いランダムにリンクを切断する。

※ちなみにGnutellaでは長時間参加しているノードは、引き続き参加する確率が高いというデータが出ている事を紹介しておこう。

このようにすると、
■PCリソースが大きいノード
■DHTに参加する時間が長いノード

についてはリンク数が増えることになる。これにより上記2条件を満たすノードはクラスタを構築し、結果的にはDHTのホップ数が減少するはずである。ただし、ホップ数の評価はしていないので興味のある方は計算して欲しい。
ちなみにSymphonyに対抗してこのDHTをConcertoと名づける事にしよう。(笑)
⇒concertoは「協奏曲」のこと。あるノードがクラスターを形成することにより、ソリストのように力をつけることから。

リンク数を非対称にする試みは他の人も色々と考えているようだ。このような事を考えてみると面白いDHTが構築できると思う。

| | コメント (1) | トラックバック (0)

« 2005年3月 | トップページ | 2005年5月 »