« 2004年5月 | トップページ | 2004年7月 »

2004年6月の11件の投稿

2004.06.30

[P2P]P2P勉強会プレ飲み会

P2P勉強会の講師陣で7月~8月初旬で打ち合わせを行う予定です。
その際、講師陣以外でも若干名の方を集めて一緒に飲み会をしようと考えています。

P2P勉強会で講師陣にコメントしたい、こういう方向性で講演して欲しいという要望がある方はプレ飲み会参加のメールを私(tnishita@yahoo.co.jp)に出して下さい。

ただし募集するのは若干名なのでP2Pに対して自分の意見が言える方が優先されると思います。ご興味のある方は是非。。
(※現在、日時を調整していますが、開催は土日あるいは金曜日の夜になると思います。また、日程の都合上、講師陣は全員でなく一部の方の参加になる可能性があります。最悪でも私とP2P Todayの横田さんは出席できるように調整します。)

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

2004.06.27

[P2P]P2P勉強会のちょっと良い情報&懇親会やります。

P2P勉強会ですが、現在参加希望者が収容人数を超えているためにキャンセル待ちの人が出ている状態です。
大変申し訳ござません。m(_ _)m
P2P勉強会について

ですが、、、現在とある出版社と交渉中で現在の収容人数より大きい場所でP2P勉強会ができるかもしれません。
もし実現すれば収容人数が大幅に増えるのでキャンセル待ちの人も参加できると思います。また追加募集をするかもしれません。(といっても現在キャンセル待ちの人を優先するので、参加したい方はこの機会にキャンセル待ちの御連絡を是非した方が良いと思います。)

ところで、P2P勉強会の参加者ですが大学教授や研究員、院生、ライターなど多彩なメンバーとなっています。非常に刺激的な交流ができると思い、私も今から大きな期待をしています。これがきっかけにP2Pの研究者・技術者同士の交流が盛んになれば嬉しいですね。

また、P2P勉強会の後にせっかくの機会なので懇親会を開きたいと思います。P2P勉強会はともかく、懇親会は参加するぞー!という人は是非ご連絡をお願い致します。P2Pの有識者とざっくばらんに意見交換できる貴重なチャンスです。また懇親会の幹事を募集中です。是非!!皆様の参加をお待ちしております♪

なお、キャンセル待ちを含めて勉強会参加の申し込みは終了致しました。

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

[P2P]電子チケットのP2P流通

NTT Docomoのコマーシャルで携帯を使ってコンサート会場に入れるCMをご覧になった方も少なくないだろう。既に電子チケットは実用化に動きつつあり、もう数年もすれば電子チケットで入場するの普通の事となるだろう。

まず、電子チケットの特徴を挙げておこう。

1)利用者がチケットセンターまでチケットを取りに行く必要がない。

2)コンサート主催者がどのような属性のユーザが入場したか簡単に把握できる。

3)電子チケットとそのユーザが会場内で購買した物あるいは今後のコンサートチケットを関連づければ、関連グッズなどのマーケティングにも利用できる。(これは私のアイデア。既に実施されているかもしれない。)

4)電子チケットの偽造が困難。(※むしろこれは電子チケットとしての要件を満たすために必ず考慮されている事。)

電子チケットと携帯電話は非常に親和性が高い。その理由として通常市民が外出時に持って行く電子機器において一番割合が高いのが携帯電話だからである。(ついでに2番目はウォークマンなどの携帯音楽機器とのことだ。)

また、携帯電話は通信機能が有るので簡単に電子チケットを入手できる。更にFOMAを代表にして、第三世代携帯には独自の認証番号を有するから、これを用いて個人特定することが可能である。利点としてはそれだけでなく「携帯電話」という閉じた世界で通信のやり取りができるのでクラッキングしにくいということも挙げられるだろう。

電子チケットの実現例として有名なのが携帯電話でバーコードを表示する事である。第三世代携帯となるBluetoothなどの近距離通信機能がついてくるので、バーコードに頼らない電子チケットが出てくるかもしれない。
(というのはバーコードの場合には画素情報なので、うまくするとこれを偽造できるかもしれないからである。)

さて、電子チケットで一つ問題になるのが電子チケットの譲渡である。これがなかなか難しい。
つまり、電子チケットでは偽造を防止するため「その人」以外には電子チケットが流出・複製できないようにしてある。
ということは、Aが電子チケットをBに譲渡するには、次のような要件を満たすことが必要だ。

1)AはBに電子チケットを「確実に渡す」必要がある。改ざんや紛失はないこと。

2)AはBに電子チケットを渡した際には、完全にその電子チケットの権利がなくなる。

3)BはAからもらった電子チケットが「正当である」と評価できること。

4)Bは確かにAから電子チケットをもらった事を確認できること。(これは要件的には弱いかも。)

クライアント=サーバモデルならともかく、P2Pモデルでは難しいところばかりである。特に3)はP2Pモデルでは非常に困難を伴う。

とはいえ、このようなP2P流通はNTTをはじめ、いろいろな人が研究をしているので期待しよう。

おそらく、このようなP2Pの電子チケットの流通は携帯電話で成り立つであろう。といのは先ほど示したように携帯電話は「閉じた世界」なので、不正なアタックがしにくいからである。このアタックがしにくいといのはコンサート主催者からは特に強い要件である。また、このような「閉じた世界」であれば、ソフトで対処できない問題はハードを使って解決できるので、それが携帯電話の使用を後押しできる。

電子チケットの流通はまず、Bluetoothのような近距離無線機能によって実現されるだろう。その後、iアプリや専用のメール機能を使って本格的なP2Pのチケット流通が期待できる。

しかしここでまた難しい問題が出てくる。どのようにして電子チケットの対価を払うかということである。これをきちんと処理にするには、やはり電子マネーの登場が必要だろう。もちろん、電子振込みやWEBのオークションサイトを使う事も考えられるが、これは今のところ一般市民にはやや障壁が高いと言わざるを得ない。その意味でまずBluetoothのような人間による確実な認証が必要である場合がモデル的には(モラル的にも)確実であり、実現も早いだろう。

ただし、携帯電話ではご存知のとおりFelicaを搭載して部分的にだが電子マネーの機能を有するようになる。携帯会社は完全な電子マネーの機能も視野に入れているかもしれない。これに期待しよう。

携帯電話は閉じた世界なので高いセキュリティとモビリティが期待できる。パソコンやPDAなどによる電子チケットの流通は携帯電話で実現した後(それも当分先)のことになるだろう。

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

2004.06.21

[P2P]これから考察したいこと。

今日は時間がないので、これから考察したいところをメモ。
私が考察するだけでなく、いろいろな方の意見を交えながら精査していきたい。

1)クライアント=サーバモデルでのWEBとP2P WEBの違い(例:モジュールの流通など)
⇒ビジネスモデル等まで本当に変わるのか?

2)P2Pでのソーシャルネットワーク。P2Pになるとどのようなことが嬉しいのか?実現方法は?

3)あるルータがXMLによるルーティングができるようになったらしいのでそれを使った面白そうなビジネスモデル。SIONetと関連?

4)P2Pの認証について。PKI,PGP,ID+Password,ゼロ知識証明、どれがどのようなシーンに適合するのか?

5)P2Pによる広告モデル、インセンティブモデルなど。どのようにすればビジネスとして成り立つ?

6)P2Pによる電子チケット流通。(NTTがある程度実装をしたらしい。)どのようなシーンで役立つ?
新たなビジネスモデルは?(リアルな世界との連動があると面白そう。)

7)P2Pによる自律的なマルチキャスト(ストリーム)配信方法。自分で最適なノードと接続して、ノードが抜けてもストリームが断せず配信すること。(一部は既にBlogで紹介済み

8)携帯電話の定額制を活かしたモバイルとP2Pの連携。位置情報、バーコード、クーポンなどの複合的な連携。

9)家電とモバイル等のP2Pでの連携。IPv6、モバイルIP、m2m-xを視野に入れて。

10)「放送と通信の融合」時代のP2Pでのコンテンツ流通と課金システムのあり方。クライアント=サーバモデルでのコンテンツ流通は本格的VOD時代では破綻しそうだが。。。コンテンツの2次利用は?

11)P2P(P2P WEBを指し、P2Plog,P2P掲示板、P2Pチャット、P2P IMを含む)によるコミュニティの変化。WEBと同様な変化が起こるかも?

とりあえずこんな感じかな。まずはソーシャルネットワークについて考えていこうと思う。
今回挙げたテーマで面白い事があったらコメントかトラックバックを宜しくお願いします。

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

2004.06.20

[クラシック]アンサンブル・プラネタ インストアライブ

ちょっと情報的には遅くなってしまったけども、先週の土曜日(6/12)に新宿HMVでアンサンブル・プラネタのインストアライブが行われた。リハーサルの時から多くの観客が駆けつけ、サイン会も大盛況だった。

HPにも書いた事があるのだが、以前はあまり声楽というのに興味がなかった。その理由は
1)ビブラートが過多であること
2)音程が不安定であること
であった。特に楽器経験がある私にとって2)は声楽の曲を聴いていると自分自身がなんだか不安定になるようで気持悪くなる事があった。(※今はそんなことは無くなったけども。)

ということで声楽の曲を避けていたのだが、ある時新宿タワーレコードでいつものように買い物をしている時に、素敵なハーモニーの声楽の曲がBGMがあった。聴こえる全ての瞬間、従来のア・カペラだと思えないぐらい素晴らし調和をしていた。それがアンサンブル・プラネタとの出会いの瞬間だった。

アンサンブル・プラネタはビブラートを押さえ、そして完璧とも言えるぐらい、音程がぴしっと決まっている。まさに自分が欲しいと思った声楽のあり方であった。また、クラシックや民謡を歌っているのだが、そのアレンジがモダンで斬新的であることも忘れてはならない。これがアンサンブル・プラネタが多くの人を引付けている理由であろう。

さて、今回のインストアライブは5枚目のアルバム「愛のロマンス」のプロモーションのためのものでした。HMVやタワーレコードでCDを大きく扱っていて安心しました。
アンサンブル・プラネタの響きはクラシック嫌いでもきっと好きになる魅力があります。是非とも一度CD屋で視聴してみて下さいね。

アンサンブル・プラネタ公式HP

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

2004.06.18

[P2P]P2P WEBその2~アプリケーションの流通

先日P2P WEBについて自分の定義を書いたのだが、IKeJI様からコメントをもらい振り返ってみると、自分の定義がややシステム寄りの考え方になってしまったと思っている。ただ、このとき述べたかったのはP2P WEBだと通常のクライアント=サーバモデルにおけるWEBサーバとは違ったシステムモデルができるかもしれないことを強調したかった事が挙げられる。

何を言いたいのかと言うと、静的なWEBページを表示させる技術はクライアント=サーバモデル(以下CSと略)のWEBでもP2P WEBでも同じ事だ。P2P WEBではHTMLなどをオーバレイネットワークで流通すればよい。

ところが、動的なページはそうはいかない。CS WEBではCGIなどのモジュールを追加すればよい。しかしP2P WEBではそもそもCGIなどのモジュールを流通させるという発想が今までなかったのだ。

そこで、先日言いたかったのはCGIなどのモジュールをオーバレイネットワークで流通させると面白い事ができるかもしれない、ということである。つまりHTMLファイルでなく、モジュールを流通してしまおうと言う事だ。

モジュールが流通される方法の一つを書いておこう。

1.モジュール開発者は作成したモジュールにおいて電子署名をつけておく。そして、自分のノードにモジュールを埋め込む。電子署名はPKI的でなくPGP的な方が良いだろう。
(※モジュールに電子署名をつけることは、マイクロソフトがパッチや関連メーカのデバイスことでも知られている。ようは、変なモジュールを流通させてノードが不安定になることを避ける事を意味している。また、ソースコードを電子署名する研究も進んでいる。)

2.オーバレイネットワークで(仮想的に)隣接しているノードはそのモジュールの情報を交換する。そして他のノードに新たなモジュールがある場合にはそれをインストールする。その際にはモジュールの電子署名を確認し、正当性をチェックする。(ただし、モジュールをインストールするかどうかはユーザが決定できる。)または、ノードAがあって、Node_ID=hash(name_A)というノードBがあれば、ノードAのモジュールをノードBとノードBが落ちた場合のためにその付近のハッシュ空間のノードに流通させると言うモデルもある。

3.基本的にはモジュールはオーバレイネットワークで拡散し、一定時間後は全てのノードがそのモジュールを搭載し、新たな機能を提供する。(※開発者がモジュールの拡散範囲を限定しない場合)

このような方式は特にP2Pアプリあるいはミドルウェアが機能追加あるいはバグフィックスをするためにパッチを宛てる時に有効だ。また、自分で作ったモジュールはもちろん自ノードにインストールできるが、開発者用の秘密鍵がない限り、流通しない。そのため、自分欲しい機能に特化したノードを自ノードに限り作ることができる。

これまではP2Pとファイルの流通に注目が集まっていたが、このような「機能」すなわちアプリケーションの流通を考えると今まで想定してなかった面白い世界が広がってくると思えてならない。


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

2004.06.16

[P2P]P2P WEB ~P2Pとサーバ=クライアントモデルの狭間で

最近色々な方がP2P WEBについて議論している。まだP2P WEBについてはっきりとした「定義」がされてないので混乱している状況と言っても良いかもしれない。私もはっきり言ってP2P WEBの概念を完全に把握している訳ではない。

ここで、P2P WEBの「自分なりの定義」をしてみたいと思う。もしかすると通常の認識よりも拡張しているかもしれない。(※定義については色々な方のコメントを頂きたいと思っています。)

定義1:個々のノードはクライアントとして「ブラウザ」を通して各種のサービスの提供を受ける。

定義2:個々のノードには最低限、クライアントにHTML(XMLでも可)を表示させるようなWEBサーバが入っている。ノードによってはWEBサーバのバックエンドにデータベースアプリケーションが存在する。

定義3:(上記に関連して)サービスは動的なページも含まれる。

定義4:個々のノードのリソースにはハッシュ、URIなどの一意的な意味情報でアクセスできる。IPアドレス等の知識は(通常使用する分には)不要。

ここで、各ノードは分散ハッシュで構成することと仮定する。分散ハッシュを導入すると余計な議論を省く事ができるからである。

まず、定義1、定義4は分散ハッシュで既に実現していることであるから、ここでは取り上げない。

問題は定義2、3である。これはサーバで言うとWEBサーバにCGIを入れているケースが想定される。

上記を実現する方法で簡単に思い浮かぶのは、DDNSを使ったサーバ構築である。
分散ハッシュでいうと、自分が構築しているサーバAをオーバレイネットワークに公開したいとすれば、サーバAの名前をnameとしてNode_ID=hash(name)と言うノード(ノードBとしよう)にノードAのメタ情報(IPアドレスなど)を通知すれば良い。このようにすれば、ユーザにDDNSの知識がなくても、サーバはオーバレイネットワーク上に公開できるし、Ringochなどのゲートウェイを通して通常のインターネットユーザにもリソースを提供できる。

ノードは自分で管理しているので、「自己責任」の下、どのようなアプリケーションを入れようが設定しようが構わない。もちろん、自ノードが落ちると、自ノードへアクセスしようとする人は接続する事ができない。回避する方法として先ほどのノードBがプロキシになる方法がある。つまり、クライアントがノードAにアクセスする時には必ずノードBを通ることとする。プロキシのキャッシュ機能により、「ある程度」ノードAの情報を提供できる。

もう一つの方法はやや難しい。(そして本当にどこまでできるのか私も、わからない。)
それはCGIなどの機能を他ノードの引き渡す事である。つまり、ノードAはノードBに対して、CGIや情報を渡す。管理者Aの要望を実行しているのはノードAではなく、ノードBである。そして、ノードBはノードB自身が落ちた場合に備えてCGIをある一定ハッシュ空間内のノードに複製する。

しかし、これではノードAが悪意のコードを入れることによりノードBをクラッシュすることができる。
そのため、対策の一つとしてはCGIの機能などを制限する事が考えられる。P2PミドルウェアによってCGIの実行の制御管理がされていることを意味する。(おそらくCGIが他ノードから渡された時にミドルウェアで脆弱性等をチェックするのだろう。)これが実現できれば、ノードが複数落ちたとしても柔軟に動的なWEBサービスが実現できる。実装にはグリッドなどの知識が利用できるかもしれない。Wikiはこれの一種の限定版と見なせるかもしれない。
(このようなミドルウェアやOSでCGIの機能を制限している例としてiアプリなどが挙げられるだろう。)

後者が実現すれば、かなり柔軟なサービスが展開することが期待できる。例えば自分なりのオンラインゲームを始めたり、自分用にカスタマイズしたチャットルームなどができる。一般のインターネットスキルのユーザがISPなどのレンタルサーバを借りないとできなかった事が容易にできる可能がある。まるで、設定不要のフリーソフトをインストールするように。

P2P Todayの横田氏がBlogで書いているようにP2P技術は普通のインターネットユーザにサーバ(P2Pなのに[サーバ]というのは定義的には変かもしれない。サーバ機能といった方が適切かな。)を与える革命的な技術になるかもしれない。

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

2004.06.13

[P2P]P2P型WEBプロキシのセキュリティ

近頃2chなどでP2P型WEBプロキシについて盛り上がっているので、今回はそのセキュリティ面を考察してみる。

まず、分散ハッシュを使えば容易にP2P型WEBプロキシが作れる事を先日のBlogHPで示している。

簡単に書くと、ノードAがあるHP(このURLをurl_aとしよう)を参照する場合、Node_ID=hash(url_a)と言うノード(ノードBとしよう)へ接続するようにすればよい。いまノードA⇒ノードBへの検索過程でノードC,Dが介在すれば、結局ノードB,C,DはAに対する多重プロキシとなり、ノードA⇒ノードC⇒ノードD⇒ノードBへの通信となる。

ここで、FW氏は検索過程のノード(ノードC,ノードD)が分散ハッシュの方法によってはノードAの存在する分散ハッシュ空間のエリアを限定することをができることを指摘した。そしてその解決策として分散ハッシュのルーティングテーブルにおいて、ある程度ランダムに次ノードへの通信をむける事で解決する事をBlogで示した。これによりP2P型WEBプロキシの「匿名性」については保障できる。

ところで、匿名性以外にも深刻な問題がある。それは各ノードが通信内容を見えてしまう事である。そこでこの事項について整理してみよう。

1)パスワード、ID
平文でパスワードを流すようなHPにアクセスする場合には注意が必要である。パスワードを盗聴され、成りすましされることが考えられる。これを回避するには認証時にSSLを使ったページを利用する事が考えられる。

2)Cookie
これは意外な盲点かもしれない。通常、HPではセッション維持のためにCookieを使う。このCookieを盗聴して他人が使うとなりすましをされる可能性がある。特にインターネットショッピングなどではCookieを使う事が多いので注意が必要である。Cookieについては日経ネットワークの6月号にわかりやすく書いてあるのでそれを参照してほしい。

3)HPのなりすまし
各ノードはプロキシとなっているので、各ノードが要求しているアクセス先HPを詐称して自分の作成したHPを表示する事が可能である。一番深刻なのはインターネットショッピングなどのHPを詐称する場合で個人情報のほかにクレジットカードの番号などを盗み取られる事が考えられる。(同じようにパスワードを入力するような画面を作って、パスワードとIDのペアを盗み取ることも考えられる。)

このように、P2P型WEBプロキシが実現したとしても、ユーザ自身が気をつけないと痛い目に合う可能性がある。P2P型WEBプロキシが普及した際にはそのリスクを考慮に入れながら使用して欲しい。

P.S.おかげさまで2万アクセスを突破しました♪今後もよろしくお願いします☆あと、のだめカンタービレ9巻を早速購入しました。今回も面白く、買いですよ。

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

2004.06.10

[P2P]分散ハッシュシステムでのNAT越えの考察

分散ハッシュ(DHT)の論文などを見ていると、システムにおけるNAT越えの問題についてあまり取り組んでないように思える。分散ハッシュではある特定ノード間でルーティング情報を交換しないといけないので、NAT越えの問題はもっと注目されても良いはずだ。

ここ数日間,分散ハッシュと親和性の高いNAT越え技術について考察したのでここで説明したい。今回提唱するモデルを「2重分散ハッシュテーブルモデル」と呼ぶことにしよう。

まず、ノード集合(Node_A)にはグローバルアドレスを持つノード集合(Node_G)とプライベートアドレスを持つノード集合(Node_P)がある。つまりNode_A=Node_G+Node_Pである。今特に問題なのはNode_P⇔Node_Pの通信なので、これにフォーカスしてみよう。これができればNode_P⇔Node_Gの通信もほぼ同じ技術で解決する。

今、Node_Pに属するノードP1,P2がある。P1はP2と通信したいとしよう。hash_XはノードXのハッシュとし、Next(hash)は分散ハッシュテーブルにおいてハッシュ値hash以上の最初に実在するノードとする。

まず、ノード全体の集合Node_Aは分散ハッシュテーブルDHT_Aを持っている。ここで、グローバルアドレスの集合Node_Gはあらたに別の分散ハッシュテーブルDHT_Bを持つ事にしよう。ただし、ハッシュ関数はDHT_AもDHT_Bも全く同じであり、例えば、グローバルアドレスのノードGがDHT_Aでハッシュ値hash_Gを持つとすれば、DHT_Bでもハッシュ値hash_Gを持つ。つまり、DHT_Gではプライベートアドレスのノード分だけそっくりルーティングテーブルから落としたDHTと考えて欲しい。分散ハッシュのChordで言うと、同じハッシュ空間で全ノードを格納しているリングと、グローバルアドレスノードのみ格納しているリングがあって、グローバルアドレスのノードの位置(つまりハッシュ値)は全く同じになっている。

まず、P1は適当なグローバルアドレスノードと接続してDHT_GにおいてNext(hash_P1)となるグローバルアドレスノードを見つける。これをG1とする。一回P1がG1を見つければ、P1⇔G1は定期的に通信をすることにする。(理由は後述する。)次にP1はDHT_GにおいてNext(hash_P2)となるグローバルアドレスノードをみつける。これをG2とする。P2⇔G2は先ほどの説明より定期的に通信をしている。これで準備が整った。

ここからP1⇔P2の通信を行うために、(UDP Hole punching +STUN+Jxtaの原理)をミックスしたアプローチをとる。UDP Hole puchingやSTUNについては先日のBlogHPを見て欲しい。

1)P1はG2と通信することにより、P2と通信するためのポートとIPアドレスを知る。またP1はG1に対してP2と通信したいというメッセージをP2宛てに残す。

2)P1はP2に対してG2から教えてもらったIPアドレス、ポートにUDPで通信をする。まだP1⇔P2の通信は確立しない。

3)P2はG2と通信して、P1から接続要求があることを知る。また同時にP1のIPアドレスとポートを知る。これにより、P2はP1へそのアドレスとポートへUDPで通信をする。これにより、P1⇔P2の通信が確立する。(ただし、P1,P2がSymmetric NATでないとする。)

4)P1⇔P2の通信ができない場合、P1,P2のどちらかまたは両方がSymmetric NATであることがわかる。そのため、P1⇔G2⇔P2という通信をすることによりNAT越えを行う。

このようなステップを取れば、通信ノードの両方でNATがあっても通信ができる。すなわち、STUNサーバがグローバルアドレスのノードに分散していると考えてもらえば良い。これができれば、各ノードはルーティングテーブルを容易に交換できるから全ノードの分散ハッシュテーブルDHT_Aを構成することができる。

本考察では各ノードの通信を成立するためにグローバルアドレスのノードだけによる分散ハッシュテーブルを導入した。今回のモデルではグローバルアドレスのノードに対してほぼ均等に負荷が分散されるが、例外としてSymmetric NATを使用し且つ通信量の多いプライベートアドレスのノードXにおいて、DHT_GにおけるNext(hash_X)となるグローバルアドレスのノードに大きな負荷がかかるので、その辺の負荷分散を検討するともっと面白いモデルができるだろう。

(補足)分散ハッシュテーブルを1つにしても同様なことが実現できます。つまり、グローバルアドレスのノード間で通常のDHTでルーティングして、プライベートアドレスのノードはある規則によって特定のグローバルアドレスのノードとルーティングテーブルを回すという方法です。(つまり、プライベートアドレスのノードはグローバルアドレスのノードにぶらさがているというイメージです。)実装は本章の提案よりもやや面倒なことになるかもしれません。

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

2004.06.06

[クラシック]「のだめカンタービレ」面白すぎ!

久しぶりに心から面白いと思うマンガに出合ったそれが「のだめカンタービレ」
指揮者を目指す千秋と、彼に片思いする天才?ピアニストの「のだめ」が繰り広げるクラシックの世界。クラシックのマンガと言うとどうしても堅く思われてしまうのだが、これは全然抵抗がないはず。特にクラシックに興味を持っている人は是非買いのマンガだ!

ところで、この「のだめカンタービレ」に登場するクラシック曲を集めたCDがある。
その名も「のだめカンタービレ」。残念ながら絶版なのだが、マンガがマンガだけに、Amazonのユーズド価格で¥50,000もする。凄すぎ!
これなら、収録曲をバラで買った方が良いと思うのだが。。。まあ、それだけ人気があるということか。

一応、現代音楽をHPで扱っている以上このマンガで登場する20世紀音楽を紹介しておこう。

ラフマニノフ:ピアノ協奏曲第2番

ガーシュイン:ラプソディー・イン・ブルー

ジョリヴェ:パーカッション協奏曲

ラフマニノフのピアノ協奏曲第2番は特に第2楽章が美しい定番のピアノコンチェルト。ラフマニノフはこの他にも「音の絵」「前奏曲集」などピアノ曲を中心に本当にきれいな曲が多いので是非聞いて欲しい。

ガーシュインはクラシックにジャズのセンスを持ち込んだ作曲家。代表作はこのラプソディー・イン・ブルーで一種のピアノ協奏曲となっている。特に出だしのクラリネットのソロはかっこイイ!!CM曲などでもおなじみのはず。

ジョリヴェはフランス近・現代音楽の大家。フルートの名曲「リノスの歌」しか聴いたことがないので、こんどCD買ってみよう。

そのうち、マンガで現代音楽が出てくる事を期待しましょう。

ちなみに「のだめカンタービレ」は第9巻が6/11に出ます。楽しみ♪

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

2004.06.01

[P2P]P2P勉強会日時決定!

先日からお知らせ致していますP2P勉強会ですが、場所、日時が決まりましたのでお知らせします。

勉強会名「オーバーレイネットワークの現状と未来について」

■日時:
9/4(土) 10:30~16:00(予定)

■場所:
東京都現代美術館  第一研修室
※アクセスマップ

■講演者及び講演概要(予定)

横田 真俊 氏(P2P Today):最近のオーバーレイネットワークの現状

Tomo(Tomo’s Hotline):分散ハッシュの概要及びその応用、セキュリティについて

徳力 基彦 氏(アリエルネットワーク):P2Pコラボレーションについて

亀井 聡 氏:オーバーレイネットワークのトラフィックについて

fukutommy 氏:P2P掲示板「新月」の仕組みの概要について

小柴 聡 氏(NTTコミュニケーションズ):P2Pコンテンツ流通「NetLeader」とマイクロソフト社のDRMについて

須之内 雄司 氏(慶応大学):NAT越えに関する技術動向について

■参加費:無料

日本でも有数のP2P有識者が講演する滅多にないチャンスです。是非とも参加して頂きたいと考えています。

※定員に達したため、申込は終了とさせて頂きます。

今回は会場でプロジェクターが借りられないので、会場までプロジェクターをお持ち下さる方を募集します。
(是非!!)

※オーバレイネットワーク勉強会の動きについてはこのBlogにて随時紹介する予定です。

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

« 2004年5月 | トップページ | 2004年7月 »