« 2005年4月 | トップページ | 2005年6月 »

2005年5月の18件の投稿

2005.05.28

[skype]skype conference 2005 JAPANの講師陣について

skype conference 2005 JAPAN(skype勉強会)の講師陣ですが、大方調整がついたのでご報告します。なお、諸事情等により講師や講演内容が変更となる可能性があります。 いずれの講演者もskypeに関して日本有数の有識者ばかりで、とても貴重な講演が聴けると思います。是非ご期待下さい。

<講師陣&講演内容(予定、一部調整中)>

□P2P Today 横田氏
□Skype News HK氏 (調整中)
横田氏はP2P TodayというP2Pニュースサイト、HK氏はご存知の通り、Skype newsというskype情報サイトの管理人です。
横田氏、HK氏にはskypeの歴史、最新動向について講演して頂く予定です。
P2P Today http://wslash.com/
skype news http://hkspage.livedoor.biz/

□アリエルネットワーク 徳力氏
P2Pグループウェアで有名なアリエルネットワークの方で、skypeについて多数の講演、著作を行っています。
skypeを取り巻く現状、ビジネスモデル等の基調講演を予定しています。
図解P2Pビジネス(著作)

□ソフトイーサ 池嶋氏
ソフトイーサの副社長で、「skypeやろうぜ!」というサイトの管理人でもあります。skypeの技術面について解説する予定です。
skypeやろうぜ! http://ikejisoft.com/?Skype%A4%E4%A4%ED%A4%A6%A4%BC

□@niftyモバイルフォーラム 清成氏
@niftyモバイルフォーラムにおいてskypeについて活発的に記述をされ、またskypeの本も書かれています。
skypeの現状そして将来性等について講演して頂きたいと考えています。

@niftyモバイルフォーラム http://fmobile.nifty.com/
Skype―世界規模の電話代無料革命(著作)
 
□無印吉澤 氏
BlogにおいてSIP及びP2Pに関する興味深い記述をしている方です。
講演では最近ホットトピックとなっているP2P-SIPについて解説する予定です。
無印吉澤 http://muziyoshiz.jp/

□!!スペシャル講演者!!
え!あの会社の方が?(調整中)

※時間がある場合には私もskypeの要素技術であるDHT(分散ハッシュテーブル)について解説するかもしれません。

なお、開催時期は都内で8月~9月を予定しています。会場を安価で提供して頂ける方ご連絡をお願い致します。

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

2005.05.26

[P2P][DHT]P2P型分散データベースの提案

Oracleがグリッドについて積極的に取り組んでいるが、今回はDHTを使ったスケーラブルな分散型データベースを提案したい。なお、データベースについてはDB、分散型データベースはDDBと省略する事にする。

さて、ご存知のとおりDHTを使うと、一般的にあるデータdataはNode_ID=hash(data)というノードに格納する。
DBについては一般に主キーというのがあって、これを基に検索などの処理を書けることになる。
今回はDHTによるDDBの可能性を考えるために簡単なモデルを提案する。実際にはDDBを運用する上でもっと多くの課題があるはずだし、それはこのBlogを見て頂いたみなさんと共に解決していきたい。

今、あるDBのテーブルがあるとする。このテーブルには主キーがある。
DDBを使うととても巨大なDBを扱える可能性がある。まずそれにはDDBのテーブルを分割する必要がある。

まず、主キーについてはハッシュ値を計算し、主キー(及び主キーに紐づいた他のテーブル項目)をハッシュ値の昇順でソートする。テーブルはあるハッシュ値をトリガーにして複数に分割する。つまり、全体のテーブルをTableとすると
[式1]Table=Table(0.A)+Table(A+1,B)+Table(B+1,C).....
と分割できるはずだ。なお、Table(S,Q)は主キーのハッシュ値において、SからQについて構成しているテーブルを意味している。なお、このテーブルはノードやネットワーク負荷、DBサイズによって自律的に分割、結合を行う。
なお、Table(S,Q)を保持するノードはNode_ID=Sとしよう。

これだけだと単にTableの分割を行っただけだ。そこで実際にSQL文を叩いて作業をするにはどうすればよいのだろうか?

今、バーチャルDBノードと言うのを定義する。略してVDBノードと呼ぼう。これはあるノードAがVDBノードにSQL文を投げれば、ノードAから見てVDBノードがあたかも全てのDBの処理をしているように見えるノードを意味する。

VDBノードはNode_Id=hash(Table_name)である。VDBノードは式[1]のようにテーブルを分散したときに、その分散したテーブルを保持するノードのNode_IDのリストを保持する。今、このリストを分散テーブル管理リストと呼ぼう。つまり分散テーブル管理リストは
[式2]{0,A+1,B+1,C+1.....}
となる。

これで準備が整った。
では、これからSQL文を実際に発行して処理させるようにしよう。
まず、SQL文を発行するノードAはVDBノードにSQL文を通知する。VDBノードはSQL文を分散テーブル管理リスト{0,A+1,B+1,C+1....}を保持しているので、Node_ID={0,A+1,B+1,C+1....}にSQL文をマルチキャストする。なお、VDBノードは事前処理を行い、不要なSQL文を処理に関係ないノードに送らないようにする。
分散テーブルを保持しているノードNode_ID={0,A+1,B+1,C+1....}はSQLの処理結果をVDBノードに通知する。最終的ににはノードAにSQL処理の結果を通知することになる。

異なるDBテーブルとの結合等についても処理はややこしくなるが、可能であろう。

今回はP2P型分散データベースについて簡単ながら提案・検討を行った。DHTを使うと、とても大きいサイズのDBが構築可能となるかもしれないし、それを高速に処理できるかもしれないので、研究すると面白いかもしれない。

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

2005.05.25

[P2P][DHT]P2P分散プロキシの検討:その3

前回はP2P分散プロキシにおいてDHTを改良してルーティング元を匿名する方法を提案・紹介した。

今回は通信自体の匿名性について議論したい。
匿名性を高めた分散プロキシとしてTorを挙げる人が多いだろう。これはOnion-routing(Mix-net)を使って匿名性を高めている。

実は私もかなり昔にP2PでMix-netを使った匿名通信を解説、提案したことがある。
解説については、
P2Pでの匿名通信路(原理編)
提案については、
P2Pでの匿名通信路(実践編)

DHTにも同様にMix-netを適用できるのでここでの解説を省く。

ところで、前回解説したDHTによってルーティング元を匿名することができれば、実はMix-netを適用しなくても匿名性を担保できることをこれから説明する。

そもそも、Mix-netは多重に暗号化することによって、ルーティング先、ルーティング元を隠蔽する技術であった。ところが、今回WEBアクセスのようなものに使う分散プロキシを考えると、当然ルーティング先(つまりGWノード)はわかる。なぜならGWノードはNode_ID=hash(url)であり、そこに行くようにルーティングしなければならないから。

残るはルーティング元を隠蔽する事だが、これは前回説明したDHTの改良で可能だ。ということは、結局Mix-netのような厳しい匿名通信路を使わなくても良いことがわかる。またそもそもMix-netのような公開鍵方式で暗号化する方式はノードのリソースを大幅に消費するのであまりWEBアクセスのための分散プロキシには向かないだろう。(大きな遅延が発生する恐れがある。)

ただし、当たり前のことだがGWノードと接続要求ノード間は暗号化する必要がある。そうしないと、中間プロキシが盗聴できるからである。

さて、GWノードと接続要求ノード間をどうやって暗号化するかということである。

実はこれもDHTを使えば簡単である。各ノードは電子証明書を発行し、それをDHT内に蓄積する。
接続要求ノードはDHTからGWノードの電子証明書を入手し、それを元に共有鍵をGWノードの公開鍵で暗号化する。これを中間プロキシを通して、GWノードに渡せば良い。暗号通信はこの共通鍵で行う。
なお、GWノードの証明書はGWノードのニックネームをnameとした場合、Node_ID=hash(name)に格納している。

この電子証明書は自己証明書でも良いし、PKIやPGPのようにしても良い。
自己証明書でも良い理由はハッシュ値を検証することにある。
いま、GWノードはNode_ID=hash(name)である。
GWノードと思える電子証明書を取得した場合、当然電子証明書にはニックネームnameが書いてる。
このnameのハッシュ値がhash(url)であれば、これがurlにアクセスする真のGWノードあることがわかる。これはハッシュ値からハッシュを計算するもとの文字列を計算するのが非常に困難であることを利用している。結局GWノードと接続要求ノード間の中間侵入攻撃は電子証明書とこのハッシュ値の検証を使えば困難であることがわかる。

これでP2P分散プロキシの匿名性についての議論はひとまず終わりにする。
次回は分散プロキシにおける匿名と非匿名のバランスについて考えてみよう。


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

2005.05.23

[DHT][P2P]P2P分散プロキシの検討:その2

前回はP2P分散プロキシの設計の概略を書いた。
今回から数回に分けてセキュリティや匿名性の議論を行う。匿名性と非匿名性のバランスについても後ほど書ければと思う。

今、Chordを使って分散プロキシを設計することを考えてみよう。
実際にWEBサーバにアクセスするノードはURL=urlとするとNode_ID=hash(url)とすることにしよう。このノードをGWノードと呼ぶ事にし、urlに接続要求したノードを接続要求ノードと定義する。

さて匿名性が高いということはGWノードからみて接続要求ノードがわからないこととほぼ同値である。

Chordを使って分散プロキシを設計すると、実は匿名性があまり高くならない事が考えられる。その理由は一体なんでしょう?

それはChordが「きれいに」設計されたDHTだからである。Chordにおいて、ノードAのリンク先はノードAのNodeIDから2n離れたNodeIDのノード群となる。ということは、GWノードや中間プロキシとなるノードからすると、接続要求ノードが「大体この辺にあるな」と推測できる(というよりもNodeIDの範囲を絞る)事ができるのである。ここで中間プロキシとは接続要求ノードがGWノードにルーティングする際に使用するノードで、それ自体がGWノードと接続要求ノードのプロキシになるノード群を意味する。

このような事を避けるためには、ランダムネスを取り入れたDHTを入れることも考えられる。例えば、DHTとしてSymponyを入れることにより、このような推測はややしにくくなる事が考えられる。

もっとも、Sympnonyを取り入れたとしても接続要求ノードのNodeIDの範囲を絞る事が可能である。
そこで、ルーティングにもランダムネスを入れることが考えられる。

DHTの場合、非常に効率よくルーティングするため、GWノードへ一番効率のよい中間ノードへルーティングすることになる。そのため、下記のようなルーティングポリシを実行すれば効率は多少劣るが匿名性は高くなるだろう。

・各リンク先において、GWノードに近づくリンク先へ行く確率をp,逆に遠ざける確率をqとする。
 p+q=1である。
・pは各ノードでランダムに設定する。ただし、一般にpはp>>qであるような確率発生関数を設定すること。
・GWノードに効率よくルーティングするリンクほど、実際にルーティングする確率が高くすることに確率発生関数を設定する。つまりルーティングする毎に確率発生関数を計算し、それを基に乱数を発生させて、ルーティング先を決めるわけだ。ランダムネスを取り入れつつ、効率良くルーティングしやすくなるように設計していることに注意!
・qの確率で、逆方向(つまりGWノードに遠ざける)にルーティングする。

このようにすれば、GWノードから中間プロキシから接続要求ノードを推測するのは困難になるはずだ。

次回は暗号、その応用としてMix-net(Onion-routing)を取り入れた際にどのぐらい分散プロキシの匿名性が高まるか検討してみることににする。


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

2005.05.20

[DHT]DHTオフ会参加者募集について

DHTオフ会についてMixi以外からの参加者を募集開始しました。
ただし、参加人数枠に限りがありますので参加表明はお早めにお願い致します。

DHTオフ会開催概要:
□日時:6/26(日)13:30~
(開始時間は参加人数により前後します。)
□開催場所:筑波大 (詳細な場所は後日参加者にお伝え致します。)

□講演者
産業技術総合研究所 小島一浩氏:
「DHTとComplex NetWork(スモールワールド)について」 (仮)

Tomo's Hotline & Tomo's Homepage 西谷 智広
「DHTの応用:SNS,ソーシャルブックマーク,分散プロキシとDHT」 (仮)

※プレゼンをして頂く方、募集中です。なお、プレゼン時間に制限は特にありません。

□参加方法
☆Mixiの方
下記のURLから応募して下さい。
http://mixi.jp/view_event.pl?id=974759

☆Mixiに参加してない方
 ・氏名(ひらがな)
 ・所属
 ・DHT、P2Pとの関わり
 ・連絡用メールアドレス
 ・懇親会の参加の有無(3000円程度、18:00~20:00時ぐらいを想定)
の5点を明記の上、
yohei962@gmail.com までメールして下さい。取りまとめは事務局の田中ヨヘイ様が行います。
※なお、参加者の方は後日連絡用MLに加入して頂きます。
応募者1次締め切りは5/27(金)で、応募者多数の場合抽選とさせて頂きます。(5月下旬に当選者の方にオフ会の詳細情報をお知らせ致します。なおプレゼンをして頂ける方を優先とします。)

皆様の応募、お待ちしております。


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

2005.05.18

[DHT]P2P分散プロキシの検討:その1

さて、これから数回に分けてDHTを用いたP2Pプロキシについて解説を行う。
進め方として大きく分けて
・P2P分散プロキシの実現方法の概略と実装時の注意点
・P2P分散プロキシの匿名性の議論(DHT-P2PプロキシはTorを超えられるか?)
・P2P分散プロキシの将来性
について書いていく予定だ。

さて、DHTによるP2P分散プロキシは既にHPで実現方式を書いてある。
分散ハッシュテーブルのP2Pアプリへの応用:その2

簡単に書くと、ノードAがブラウザでURL=url1を見たいときにはNode_ID=hash(url1)となるノードXにアクセスすれば良い。このときに、ノードAがノードXを検索するために介在するノードP1,P2.....PZをプロキシとすれば、ノードAはノードXに対して、多重プロキシを介することになり、結局誰がURL=url1を見ようとしているのかわからないといことになる。匿名性を薄めたければ多重プロキシを無効にすればよい。
ここでノードXのように直接ターゲットとなるWEBサーバあるいはストリーミングサーバにアクセスするノードをGWノードと定義しよう。

では、実際にP2P分散プロキシを実現するための注意点を書いていこう。

まず、ノードXはhash(url1)となっているが、このときにurl1にアクセスが集中するとノードXは当然負荷が重くなる。
負荷を分散する方法を考えよう。

簡単な分散方法として、url1にアクセスする時には、乱数をrand()として、Node_ID=hash(url1+rand())となるノードにアクセスすれば良い。こうすれば、特定ページに人気があっても、あるノードに負荷が集中する事はない。

次に今はNode_ID=hash(url1)のようにURL毎にGWノードを変えると、DHTのNW負荷が高くなることが考えられる。これはURLが異なる毎にGWノードへのルーティングを計算しないといけないからだ。またこのルーティングによってページの表示に遅延が出ることが考えられる。
これを克服するには、ある時間毎にGWノードを変えることも考えられるだろう。すなわち、Node_ID=rand()+Time()のような関数で、Time()は一定時間毎に値が変化する関数である。このNode_IDとなるノードにアクセスすべきURLの情報を渡す事になる。こうすれば、NW負荷はNode_ID=hash(url1)の時よりも大分減るだろう。

ストリームを受信するときには注意を要する。ストリーミングサーバからクライアントがストリームを受信する際、クライアントのIPアドレスが変化すれば、当然ストリームは中断してしまう。ということは、少なくともストリームが流れている間はストリーミングサーバ⇔GWノードのセッションは維持しないといけない。
一つの解として、ストリーミングを受けている間は、間にかますプロキシノードが変化しないと言う事が考えられる。それだと匿名性が薄まると懸念する人は、Node_ID=rand()+Time()となるノードを中間プロキシノードとして指定して、GWノードは固定するという手がある。こうすれば、GWノードから見ると誰から受信しているかサッパリわからないということになる。ストリーミングを受信して他方に渡す技術はP2Pストリーミングの技術が確立しているから可能であるだろう。

次回はP2P分散プロキシとしてDHTを使うと果たしてどの程度まで匿名性を高められるか検討してみる。
そしてP2P分散プロキシにおける匿名性と非匿名性のバランスについても議論する予定である。


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

2005.05.16

[SNS][勉強会]オフ会、学会、勉強会のターゲット戦略

既にご存知のように私はP2P勉強会やskype勉強会(これはskype conference JAPAN 2005になる予定(笑))の企画や運用をしているのだが、このような勉強会についてどのような人をターゲットにしていて、どのような目的を考えているのかBlogに書く機会がなかったので整理してみる。

まずはオフ会。色々な種類があるのだが、一般的なオフ会の場合ターゲットは大抵ライトユーザあるいはそのトピックに対してちょっと関心があります!と言う人が多いと思われる。(もちろん、中心メンバなどにはコアなスキルを持った人が多い。)ノリとしては「とりあえず」会って、色々なディスカッションをしたり、共通のトピックを元に出会いを楽しむということだろう。SNSを使ったオフ会の大半はこれだろう。

次に学会だ。学会に参加した事がない人ももちろん多いと思うが、こちらはかなりニッチな層をターゲットとしている。学会自体は一般的に巨大な組織で、各セッションに別れて非常に密度の濃い専門的な議論を行う。
このような場合、ある非常に特定な人と深い出会いを形成するのは可能だが、なんとなくその話題に関心がある人や、多くの人に自分のアイデアを伝える事は難しいのかもしれない。

では私が企画している勉強会(あるいはオフ会でもある程度アカデミックに近い物、SNSのオフ会では最近このような傾向が強くなりつつある。)はどこをターゲットとしているのだろうか?

ターゲットはずばり「オフ会」と「学会」の中間だ。とても曖昧な定義だが、実はこの中庸さが参加者の人気を集める原因なのかもしれないと思っている。いくつか勉強会の特徴や狙いを挙げておく。


・勉強会は「とりあえず関心があるけども、学会にはちょっと」と言うライトユーザも参加できる。
・勉強会はオフ会に比べるとややアカデミックなので、実は学会等で有名な人も参加したりする。
(上記2点はP2P勉強会で実証済み)
・上記2点に関して、参加者に対するターゲット層が広いので多くの人が参加可能になる。
・参加者が多いと(あまり参加者には気づかれてないが)一人当たりの参加費用を抑える事が出来る。
・参加者が多いと(これも参加者にはあまり気づかれてないが)著名人を講演者として呼ぶ事が出来る。
・アカデミックなメンバが普段接しないライトユーザと意見交換でき、研究等の刺激になる。
・勉強会のテーマがニッチになり過ぎないので、実はバラエティあふれるスキル、アイデアを持つ人の参加が見込まれる。その結果、参加者がそのテーマに対して「横断的な」人脈形成ができる。

P2P勉強会で一番の特徴と考えられるのは実は一番最後の項目だ。
P2Pというのは技術面、法律・制度面、ビジネス面という多くのトピックが含まれる分野で、それによって勉強会の中でもとても多様な人が集まっている。研究者、学生、ベンチャー、法律関係者、ライター、有名企業幹部etc...
このような人が一堂に会するのは実はあまり機会がなく、勉強会によって数多くのコネクションができたと言う人は多い。

もちろん勉強会はそのテーマについて、情報を共有・ディスカッションをするのが目的だが、私の当初からの目的であった「リアルでの交流」が自分の想定以上に活発であったのだ。

ではオフ会と学会について、どう考えるかと言う事だが、これは差別化戦略を取るのではなく、むしろ連携すべきだろう。オフ会⇔勉強会⇔学会という繋がりによって、多くの人がそのトピックに関心を持つだけでなく、コネクションを形成する事もできる。

次回勉強会に参加される場合には、名刺をたくさん持ってきて頂きたい。そこでプライベート、ビジネスで今後も良いお付き合いができる人とめぐり合えれば幸いである。

P.S. 本日結納を行いました。とりあえずほっとしています。

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

2005.05.13

[P2P]Solipsisの概要、情報源

まずはフランステレコムで計画しているP2PプラットフォームSolipsisについて。
PtoPを利用した仮想世界「Solipsis」の実験始まる

友人のいぐっち君が早速Solipsisの情報を仕入れてくれました。さすが外資系通信企業研究者!
[P2P] Solipsis担当者から返事キタ━━━━(゜∀゜)━━━━!!!
===
上記で紹介しているリンクを見ると、
・チャットが出来るそうです。
・NATトラバーサル使っているそうです。
・将来はDHT使うそうです。
などなど。

Solipsisの仮想空間は2次元空間(x,y)であらわされ、x、yはそれぞれ128bit空間なので、全体としての仮想空間地点はおよそ1075程度とのこと。
※あとでちゃんと読んでレビューしたいです。
===
さすが、ヨーロッパ経由のソフト開発の情報を得るには障壁がありますね。。(笑)
がんばれ、いぐっち君!

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

2005.05.12

[ネット]@Wikiを使ってみる

みなさんで情報を共有・編集ができるようにwikiを設置しました。使用したのは@wikiです。
誰でも簡単にwikiページを設置できます。また編集もBlog感覚でできますよ!
@Wiki

ちなみに私のwikiページは次のとおりです。
Tomo's Hotline@Wiki

まずはオフ会あるいは勉強会関係について情報共有できるようにしたいと考えています。
ちなみに第1回DHTオフ会のwikiページは次のとおりです。
第1回DHT(分散ハッシュテーブル)オフ会@Wiki

なお、現在のモードは誰でも編集が出来るようにしています。色々と試してみてくださいね。
テストページを設けたので、ここで色々と遊んじゃって下さい。書き込む際のテストの際にもお使い下さい。
テストページ@Wiki
いたずらはダメですよ♪

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

2005.05.11

[DHT]第1回DHT(分散ハッシュテーブル)コミュニティオフ会

第1回DHTオフ会を以下のように開催します。

※参加表明は  http://mixi.jp/view_event.pl?&id=974759  でお願い致します※
後日Mixi以外からの参加を受け付ける予定です。

□日時:6/26(日)13:30~
(開始時間は参加人数により前後します。)
□開催場所:筑波大

□講演者
Tomo 「DHTの応用:SNS,ソーシャルブックマークとDHT(仮)」
その他の講演者、講演内容は現在調整中です。

参加者、プレゼンをして頂ける方を募集します。
(なお、プレゼン時間は短くても構いません。 オフ会ですので自己紹介を兼ねて気楽にプレゼンを して頂けたらうれしいです。)

※オフ会後、懇親会も行う予定です。 懇親会のご案内は別途行います。

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

[DHT]今後考察するためのメモ。

近日中に考察、あるいはBlogに書くかも知れない内容。

□DHTでTorのようなシステムの構築。Symphony+ランダムネスを取り入れたルーティング+Onionルーティングでできそう。まあ、HPでは通常のPure-P2Pの場合を書いているのでそれを手直しすることになるでしょう。

□DHTでソーシャルブックマーク。以前書いた事のある内容を更にブラッシュアップ。Yahoo.comのMy_Pageの概念などを取り入れられないか?P2P-Proxyなどと組み合わせてクリックしたWEBページ情報を自動的にDHT載せる、なんてこともしたら面白かもね。

□DHTと位置情報+メタデータの組み合わせ。blogでも色々書いているんですが、もっと面白いことができそうなんですけどもね。ハッシュ値⇔位置情報の変換をうまくすると、ある地点からの近傍の「特定」情報などを一気に取得する事が出来そうな予感。

□DHTでセンサーネットワーク、あるいはアドホックネットワーク。既に誰かがやってそう。。

□DHTとグリッドの組み合わせ。グリッドをもう少し勉強しないとまずいなぁ。

□DHTを絡めたVPN。DHTならではの付加サービス等の差別化はできるのか?あるいはもっと拡張してNW機器にDHTのような高レイヤルーティング機能が具備すると一体どんな事が起こるのだろうか?それは補助的な役目それとも本質的な役目になる?

□DHTでのP2P-ストレージが出来た場合のその後の将来像。一体どんなサービスの可能性があるんだろう?

□DHTと意味ルーティングの関連。そろそろこの辺も勉強しないと。

まだまだDHTで面白そうなことができそうですね。

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

2005.05.08

[P2P]今後の予定

HPの内容を久しぶりに見直したのですが、情報が随分古いのが多いので、少しずつ修正・補筆したいと考えています。後はHybrid-P2PとPure-P2Pの比較表とか合法的なP2Pファイルシェアリング、P2P-DRM、Pastry、SymphonyなどのDHTの説明の章も付け加えたいと考えています。

また、こんな内容を付け加えて欲しいなどの要望があればご連絡をお願い致します。
※そろそろ1人で記事を書くのが辛くなってきたのでHP内容の一部をwikiにしようかなと思ったりもします。
P2Pに関するwikipediaみたいになれば良いのですが。

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

2005.05.07

[P2P]「P2P-IP電話とskype」アップしました。

お待たせしました、「P2P-IP電話とskype」をアップしました。
http://homepage3.nifty.com/toremoro/p2p/skype.html

今回は初心者向けなので、応用編でいずれもっと突っ込んだ内容を書こうと思います。

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

2005.05.06

[P2P]お知らせ等

先ほどまでHPの修正・補筆をしていました。

□変更点等
・「分散ハッシュ」⇒「分散ハッシュテーブル」に修正(まだ修正漏れがあるかも。)
・DHT入門の誤字脱字の修正(結構ありました。。。orz)
「P2Pと認証,P2PでのSNS」について修正・補筆

□HPでP2Pのルーティングや掲示板について説明していますが、DHTの登場によって説明をする重要度が薄れてきていますので、今後は削除する事を検討しています。(または内容をDHTと絡めて大幅修正)
削除予定対象ページ:
・P2P掲示板の考察(前編、後編)
・P2Pとルーティング(前編、後編)

□skype勉強会ですが8月下旬~9月上旬で調整中です。
現在調整している講師陣は次のとおりです。()は講演内容[調整中]

・某P2Pニュースサイト編集者(skypeの最新動向について)
・某P2Pアプリ企業の方(skypeの概要等の基調講演)
・某ソフト企業の方でskype関連サイトの方(skypeの技術面についての講演)
・某blogの方でP2PやSIP,IPv6について書かれている方(P2P-SIPについての講演)

このようなすばらしい講師陣が集まったので、今回私は事務局に徹したいと思います。

skype勉強会でプレゼンをしたいと言う方はご連絡をお願い致します。事務局スタッフも募集中です!
また場所については調整中です。都内またはその近辺で50~100名程度収容できる場所について安価でご提供できる方いらっしゃいましたらご連絡をお願い致します。

skype勉強会というネーミングがイマイチなので将来性を期待して「Skype Conference JAPAN 2005」にでもしようかな。どこかのパクリみたいですね。(笑)カッコいいネーミング、お待ちしています。

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

2005.05.05

[DHT]分散ハッシュテーブル(DHT)入門アップしました!

Blogで好評だったDHT入門ですが、この度HPにアップしました。

分散ハッシュテーブル入門(DHT)~その1
分散ハッシュテーブル入門(DHT)~その2
分散ハッシュテーブル入門(DHT)~その3
基本的には以前Blogで書いた内容と一緒です。時間があれば今後絵などを付け足したいと考えています。

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

[P2P]P2PによるSNS資料

Talking Night ~SNSを考える~ というオフ会でP2P-SNSのプレゼンをする事になりましたので、資料を作成しました。コメント等があればご連絡をお願い致します。

「P2Pを活用したSNSの提案」
http://homepage3.nifty.com/toremoro/study/study.html

※ベースは第2回P2P勉強会と同じです。多少手直しをしています。

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

2005.05.04

[SNS]名刺の共有とSNS

以前、P2P勉強会&プレ飲み会で名刺交換を行った時に言われた事なのだが、多くのメンバで名刺交換をするととても大変なので、誰かが名刺を集めてそれをメンバ内に公開したほうがいいのでは?と言われた。

確かにその通りで、N人がいて全員と名刺交換をすると、全体でn(n-1)/2の作業量が必要である。しかし誰かがハブになれば幹事に名刺を渡すだけで良いので作業量はnとなる。

ここでポイントなのはあるメンバ、コミュニティの人だけ名刺を公開して欲しい人が存在することだ。
となると自然と名刺の公開は限定したメンバ内に閉じる機能が必要である。

SNSを使った名刺交換は次のようなイメージである。個々のメンバはカテゴリ(タグ)をつくり、それによって自分の名刺を公開できる範囲を決められる。例えばあるコミュニティに入っている人のみ、あるいはあるオフ会に参加した人のみ公開など。このような機能がSNSには求められていくのかもしれない。またSNSのようにオフ会に参加した人の友人まで公開など多彩な公開制限機能があると面白いだろう。

社内で使う完全なビジネスSNSの場合、もっと面白いことが出来る。これは業務あるいはプライベートでもらった名刺をスキャナなどで取り込み、それをソーシャルタギングのように共有することである。これに検索機能がつけば、タグあるいは会社名などにより、その人自体にコネがなくても、すばやく「リアル」な形で合いたい人とコミュニケーションをとることが可能だ。またもちろん名刺に対してはメンバ間でコメントを共有する事も可能だ。
(※この社内による名刺交換についてもプロジェクト内のみ公開など制限をする場合が必要かもしれない。例えば他人に知られたくないプロジェクトの状況を隠蔽したいときなど。もちろん友人までの公開などの機能も有った方が良いだろう。)

まとめると名刺の共有+SNSによって2つのことが期待できる
1.自分の名刺をあるコミュニティ、イベント参加者などに公開することにより、名刺交換の煩雑さを解消できる。
2.自分が頂いた名刺をカテゴライズ、共有することで他者が自分のコネを利用する事ができる。

SNSのコミュニティ・イベントを見るとビジネス・アカデミック寄りなものが多く出現してきた事からこのような機能は今後強く求められると考えている。

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

2005.05.02

[P2P]skype勉強会の進捗状況5/2版

skype勉強会の進捗状況は以下のとおり。

現在講師をして頂く方は次の3名で調整中。
□某有名P2Pニュースサイトの方
□某P2Pアプリ企業の方で多くのskype関連の講演をしている方
□某ソフト企業の方でskypeのサイトを立ち上げている方

※時間があったら私もDHTやNAT越えで講演する予定です。

他には、P2P-SIPやskype携帯電話の講演があるとうれしいんだけども。。。
P2P-SIPはあの方に頼むか。。。

あとは場所ですね。八王子の各種設備の予約ができるようになったのですが、多くの人が足を運ぶには遠いですよね。八王子で構わないのであればすぐに調整に入るのですが。。。

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

« 2005年4月 | トップページ | 2005年6月 »