« 2008年6月 | トップページ | 2008年8月 »

2008年7月の6件の投稿

2008.07.24

HTTPだけでP2Pシステムを構築できないか?

現状大抵のシステムがHTTPで実現できているので、P2PもHTTPでかなりの部分構築できないのかな、と考えています。これは先日のエントリーの「P2Pシステムのインターフェース共通化の提案」の発展版です。

まずこの目論見を説明するためにP2Pを2つのタイプの機能にブレイクダウンします。

・P2Pクライアント機能
・P2Pサーバ機能

P2Pなのにクライアント、サーバと名づけるには違和感がある人もいるとは思うが、まずはこれで説明しよう。クライアント、サーバが意味することは後ほど説明します。

P2Pクライアント機能は「HTTPクライアント」です。もっと具体的に言うと、HTTPでP2Pサーバに「リンク」を張り、維持し、HTTPで各種「要求」を行います。
要求とはリンクの形成・維持(Joinなど)、DHTで言うPUTやGET要求などです。

P2Pサーバは「HTTPサーバ」です。もっと具体的に言うとHTTPでP2Pクライアントからのリンクを待ちうけ、維持し、HTTPで各種「要求」を処理します。

通常のP2PノードはP2Pクライアント機能+P2Pサーバ機能と考えられます。この亜種としてP2Pサーバ機能しかないノードやP2Pクライアント機能しかないノードというのも考えられます。これらを含めてP2Pシステムと呼ぶことにしよう。

もう少し説明を続けます。

今すべてのノードがグローバルIPアドレスを保有しているものとします。ノードはHTTPサーバ機能を持っているので仮にすべてのノードが80番ポートでHTTPを待ち受けるとします。
つまり、P2Pに関するリンクを80番で待ち受けるものとします。

ノードA、ノードBが存在した場合のリンクの形成を考えてみます。

ノードAはノードBに対してあて先80番ポートで接続します。ノードBは80番ポートでノードAのリンクを待ち受けます。

逆にノードBはノードAに対してあて先80番ポートで接続します。ノードAは80番ポートでノードBのリンクを待ち受けます。このようにすることでHTTPのセッションは2つできるが、2つまとめてみると「双方向」のリンクが構築できます。

(本来TCPコネクション1本でも双方向リンクを構築できるが、それは本質的ではないので、ここでは説明しません。)

P2Pサーバ機能は、リンクの接続を受けることと要求の返答をするだけではありません。各種要求を必要に応じて他のノードに転送する役割を持ちます。構造化オーバーレイであれば転送経路はひとつのリンクだし、非構造化オーバーレイでは複数のリンクを各種要求が転送するかもしれません。ここが通常のWEBサーバと違うところです。P2PサーバはWEBサーバというよりもSIPサーバの機能に近いかもしれません。

ではHTTPを使ってどう要求を行う、あるいは要求を返答するかということですが、これはSOAPやRESTのような既存技術を使えばよいでしょう。

つまり、NATがない前提あるいはUPnPが使える前提であればHTTPだけでP2Pシステムが構築できることが考えられます。

話は元に戻って、先ほど「P2Pシステムのインターフェース共通化の提案」について話しましたが、そうなるとP2Pの共通インターフェースを記述する方法というのはSOAPかRESTの方がよいかもしれません。興味ある人で勉強会を実施してSOAPやRESTを使ってP2Pシステムのインターフェースを規定したり、実装してみませんか?

なお、今回の提案は、IETFのNAT越え技術に関するドラフトNICEにインスパイヤされて検討したものです。

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

2008.07.16

SBM研究会参加者にアンケートを取ります

SBM研究会参加者にはブロガーが多かったため、Blogによって多数の感想や意見を頂いています。ありがとうございます。
ブログに書くのはちょっと、という方は是非Mixiに感想を書いてください。

さて、SBM研究会参加者のSBM利用実態について調査をしようとしています。参加者はイノベーターが多いため、この層の利用実態が後のSBMユーザ動向の先行指数になるかもしれません。

SBM研究会参加者について、このようなアンケートを取りたいという方は、SBMのコメント欄かBlog、Twitterでご意見をお願い致します。なお、Blogでのコメントの場合、毎度のことですがSBMのタグで[SBM研究会]をご利用下さい。Twitterの場合も同様その発言部分をSBMのタグ[SBM研究会]でクリップしてください。

既に意見を頂戴しているものとして、
・1日あたりのクリップ数
・SBMの使い方
があります。

なお、アンケートの方法ですが、Mixiアンケートを使いたいと考えています。
その理由として

□事務局の集計稼動を大幅に減らす
□参加者のほとんどがMixiユーザ
□1人1回しかアンケートに回答できないので、公平な調査が可能
□Mixiアンケートに対するブロガーの意見を頂戴したい

が挙げられます。
もちろんMixiがオープンでない、という意見はわかります。そのため、結果については分析したあと、このBlogにて公表したいと考えています。

そうそう、私のTwitterはhttp://twitter.com/toremoro21
です。あまり発言しませんが、勉強会動向等Blogに発表する情報もあるとは思いますのでご興味がある方は是非フォローを。

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

2008.07.14

SBM研究会事務局が答える10個のFAQ

7/12(土)にSBM研究会が無事開催されました。参加者の皆様お疲れ様でした!

午後4時時点で、参加者数は90名程度(講師含む)に達したので、キャンセル率はかなり低かったと思います。

さて、事務局+個人として今回のイベントを振り返りたいと思います。ひとつのエントリーでは収まりきれないと思うので、複数回に分けてエントリーします。まずはFAQ関連について。

□ひとつの「お約束」
今回SBM研究会を出席して頂いた人にひとつ「テーマ」を提示しました。それはSBM研究会の感想をBlogで書いて頂き、[SBM研究会]というタグでSBMでブックマークすることです。
このようにすることで、SBM研究会の感想を一度に読み比べできることを狙っていたのですが、色々な方のBlogを見ると効果はあったようです。

はてブ
http://b.hatena.ne.jp/t/SBM%E7%A0%94%E7%A9%B6%E4%BC%9A?sort=eid
livedoorクリップ
http://clip.livedoor.com/tag/SBM%e7%a0%94%e7%a9%b6%e4%bc%9a
Buzzurl
http://buzzurl.jp/tag/SBM%E7%A0%94%E7%A9%B6%E4%BC%9A

この[SBM研究会]というタグを使ったことによる「効果」については後日考察します。

さて、以下事務局が答える10個のFAQです。

Q1:どうしてMixiからの応募なのですか?
A1:一番の理由は参加者の取りまとめの簡素化です。Mixiモバイルを使えば携帯で参加者と参加数と簡単に把握できるだけでなく、コメントや一斉周知などもできます。ちなみに参加者の取りまとめは私一人だけでも全然問題なくできました。

その他のMixiを使う理由は
イベント・勉強会参加者をMixi経由で募るワケ

をご覧下さい。なお近々出版される某情報系学会の月刊誌(おそらく8月号)にもMixiでのイベント取りまとめのメリット・デメリットについて執筆しました。

なお、Mixiに抵抗がいる人がいるので、メールによる受付もしていました。ただし、実際のところMixiがキャンセル待ちを含めて延べ120人程度の参加表明があったにもかかわらず、メールによる受付は5人程度でした。

Q2:なぜBlogだけでなくMixiでの感想もOKとしているの?

A2:参加者全員がブロガーあるいはコアなブロガーではないからです。もっとカジュアルに議論をするにはBlogよりもMixiの方が良いかもしれません。ということでMixiという選択も残しました。もちろんBlogに書いてもらった方が情報が多くの人に見てもらえるので嬉しいです。

Q3:なぜ今の時期にSBM研究会を行ったの?

A3:講師の目処が経ったのと、私の仕事での稼動が空きそうな時期だったからです。(といってもJANOGの発表が直前にあったりして実際は稼動がパンパンだったのだけども。)

開会の挨拶でも申し上げましたが、企画は2年前からありました。ただP2P勉強会やVoIP Conferenceなど(私の中では)優先度が高い勉強会をこなしていたので、なかなか開催することができませんでした。逆にこの手の勉強会が今までなかった(あるいは私が知らないだけ?)のが不思議です。

Q4:講師陣は公募?

A4:今回の講師陣はすべて私の知り合いです。ただし公募はBlogやMixiで掛けています。パネラーのお二人は公募によって参加表明して頂きました。

確かにP2PやVoIP繋がりの方が多いので偏りはあると思います。ただ、今回SBM研究会で色々な方とご縁になったことから次回は少し講師陣の方向が変わることになるでしょう。

Q5:分野が広すぎるようだけども?

A5:逆にそれを狙っています。テーマを絞るのもいいのですが、今まで興味を持ってなかった分野や知らない分野について知ってもらうことも必要だと思います。P2P勉強会やVoIP Conferenceでも分野を絞る v.s. 絞らないの話が必ずアンケートに掛かれますが、参加者層を限定しないのであれば、絞らない方が良いと思います。参加者がバラエティに富むという副次的効果もあります。

Q6:はてブばっかりフォーカスされているのでは?

A6:あ~、そうですね。私もそれは気になりました。講師陣がはてブを使っている人が多いのでそうなったのかもしれません。

ということで次回は「はてな」「livedoor」「Buzzurl」らによる研究会を行いたいです。「はてな」は某CTO、「livedoor」はlivedoorクリップの開発陣、「Buzzurl」はCEOが研究会に来ていたから講師調整はもうばっちり?

Q7:次回の開催場所や開催月は?

A7:場所は未定ですが、東工大ならW241や100年記念館みたいによりキャパが大きいところでやりたいです。京都という話もありますが。。。

開催月もまだ決めていません。皆様の要望が高ければ早めに開催できるように調整します。

Q8:次回研究会で事務局が仕掛けることは?

A8:当日参加者がTwitterでSBM研究会の状況を報告していたので、リアルイベントとバーチャルコミュニティが同時に進行するというとてもユニークな体験をされた方がいます。次回はできるだけ参加者にTwitterに参加してもらうことを考えています。可能であればライブ配信も。

Q9:実は何かサプライズを考えている?

A9:某情報系学会誌に特集号が組まれるかもしれません。

Q10:講師をやりたいのですが?

A10:是非連絡を。MixiのSBM研究会コミュニティで参加表明を。

===
あと懇親会から引き出した嬉しい情報を。
BuzzurlでSBMに関するログ等の情報を研究者の皆様に開示することを検討しているそうです。またインターンも絶賛募集中とのことです。興味のある方はBuzzurlまでご連絡を。



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

2008.07.10

[SBM研究会]プレゼン資料公開+最新スケジュール

SBM研究会のプレゼン資料を順次公開します。
プレゼン資料は以下のURLからご覧下さい。
http://homepage3.nifty.com/toremoro/study/SBM.html

なお、当日紙での資料配布はしませんので、各自ダウンロードかプリントアウトをお願いします。

また講演概要が少し変更になったのでお知らせいます。具体的にコモンズ・マーカーの開始に伴い、星氏の講演に修正が入っています。
☆SBM研究会概要

□開催日:2008年7月12日(土)
□場所:東工大 大岡山キャンパス 西6号館3階W631講義室
http://www.titech.ac.jp/access-and-campusmap/j/o-okayamaO-j.html
□参加費:無料(名刺と名刺を入れるための首掛けストラップをお持ちください)

□スケジュール

9:00~ 会場準備(事務局+ボランティア)
9:30~ 開場・受付開始

10:00~ 
開会の挨拶(西谷 智広 SBM研究会事務局長)

10:10~10:50
☆学びing株式会社 企画営業部 課長 メディアプランナー
スラッシュドット 編集者 横田真俊

「ソーシャルメディアとマーケティング」

Digg やはてなブックマークなどのソーシャルメディアは、一般的なメディアとして認知されはじめ、ソーシャルメディアを活用したマーケティングの事例もいくつか 登場しております。本講演では、ソーシャルメディアを使ったマーケティング事例を紹介し、今後のソーシャルメディアの利用方法について説明いたします。

11:00~11:50
☆東京工業大学 大学院理工学研究科 集積システム専攻 助教 博士(工学) 宮田 高道
☆東京工業大学 大学院理工学研究科 集積システム専攻 博士課程 佐々木 祥

「SBMデータを用いたwebコンテンツ推薦」

SBM のデータを利用したwebコンテンツ推薦に関する既存の手法は,そのほとんどがコンテンツに付与されたタグの名称を重要な情報とみなしている.これに対し 提案手法では,ユーザの嗜好はタグの名称ではなく,タグによって関連付けられたwebコンテンツの集合として表出するという考えに基づき,あえてタグの名 称を一切考慮せず,webコンテンツ集合どうしの類似度を仮説検定を用いて計算する高精度なwebコンテンツ推薦システムを実現した.

12:50~13:40
☆コモンズ・メディア代表 星暁雄

「Webの世界に「気付き」を集積するコモンズ・マーカー」

Webをもっと創造的にし、人々の知的共同作業を支援する、という思いから作った「コモンズ・マーカー」に関してご説明します。コモンズ・マーカーは、任 意のWebサイト上にマークとコメントを残し効率よく閲覧できるアノテーション機能と、俊敏にWeblogを記録できるミニブログ&ソーシャルブックマー ク機能を備えています。私たちは、「気付き」というメタデータを、ネットの世界にオーバレイする形で集積してきたいと考えています。

13:50~14:40
☆フランステレコム株式会社 (France Telecom R&D Tokyo)
早稲田大学大学院 理工学研究科 情報・ネットワーク専攻 博士後期課程
井口 誠

「お前のモノ(ブックマーク)は俺のモノ、俺のモノ(ブックマーク)も俺のモノ」

SBM サービスの普及により、多くのユーザ間でブックマークを共有することが容易になった。ブックマークを共有することのメリットは大きく、たとえば似た嗜好を 持つユーザ間でブックマークを共有することによるWebコンテンツ推薦サービスなどが数多くの研究者・開発者によって提案されている。

一 方で、ブックマークは極めてプライベートな情報であり、これを不特定多数に晒すことに抵抗を感じるユーザも多数存在すると思われる。そこで、本発表では、 このようなユーザが、己のプライバシーを守りつつ、SBMのメリットを享受できるような仕組みを、匿名P2Pネットワークを用いて実現する手法について解 説する。

14:50~15:40
☆独立行政法人 産業技術総合研究所 小島 一浩

「ソーシャルグラフってどうよ?」

SNS や SBM上で類似した嗜好を持つユーザ同士による推薦や,友達が興味を持った対象を推薦するなど,友人関係を使ったマーケティングが取りはやされている.こ のような友人関係を使ったマーケティングはソーシャル・グラフ広告と呼ばれる.現在のソーシャル・グラフ広告の可能性は未知数であるが,ソーシャル・グラ フ広告の元の考えとなるネットワーク理論について紹介し,今後のソーシャル・グラフ広告の方向性について考える.

15:50~16:40
☆筑波大学大学院システム情報工学研究科
コンピュータサイエンス専攻 博士前期課程 神林 亮

「私がチャレンジしたSBMデータマイニング」

ふ とした興味から作成したSBMのデータマイニングによるサービス(Kikker,はてブおせっかい,はてブまわりのひと, Kookle)について講演します。データマイニングなど少しもやったことのなかった自分自身がほぼ独学でサービス構築を行った経緯についてお話すること で、簡単なデータマイニングなら誰でもできるということをお伝えしたいと考えています。
また経験談の他に、SBMの技術関連で考えていたトピックなどについても講演する予定です。

16:50~17:40
パネルディスカッション
・モデレーター 西谷 智広(SBM研究会事務局長)
・パネラー
宇佐美進典(株式会社ECナビ 代表取締役CEO)
吉川 日出行(みずほ情報総研コンサルティング部シニアマネジャー)
宮田 高道/
佐々木 祥(東工大 大学院理工学研究科 集積システム専攻)
横田真俊(学びing株式会社 企画営業部 課長)

☆テーマ
「SBMの課題とこれからSBMが進むべき道」

ソー シャルブックマークが世間が知られるようになるにつれ、メインユーザがイノベーターからアーリアダプターにシフトしてきました。それに伴いユーザの使い方 が多様化し、タグスパムなどの課題が顕在化してきました。またソーシャルブックマークをビジネス向けに使う動きも見られます。

本パネルディスカッションではSBMの現状の課題を整理し、今後のSBMの方向性について議論します。

18:00~懇親会

□場所:魚馳走 庄や 大岡山店
http://r.gnavi.co.jp/a208500/
□予算:出来高次第(4000円~5000円程度)



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

2008.07.05

キャリアグレードNATのインターネットドラフトがリリースされました

先日お伝えしたように7/10(木)のJANOG22において、IPv4アドレス枯渇対策の講演をします。
http://www.janog.gr.jp/meeting/janog22/program/day1/day1-5.html

(既にNAT概要に関わる事前資料が公開されています。NATやNAT越えに興味のある方は是非ご覧ください。)

IPv6移行への暫定的処置においてISPがNATを設置する方式を検討しているのですが、そのNATに対する要求仕様案をインターネットドラフトとしてまとめました。

"Carrier Grade Network Address Translator (NAT) Behavioral Requirements for Unicast UDP, TCP and ICMP"
http://www.ietf.org/internet-drafts/draft-nishitani-cgn-00.txt



このインターネットドラフトを書く上で社内外の多くの人に多大なご協力を頂きました。この場を借りて御礼申し上げます。またインターネットドラフトを書くことは初めての機会でしたので、うまく表現できなかったところもあるかと思います。仕様に対する疑問点や英文の表現の修正案等ありましたらお気軽に連絡をお願いします。

さてISPがNATをおく方式についてはJANOG-MLやBlogを含めて多くの場所で議論されていますが、NATに対する情報はあまり今まで公開されていませんでした。今回のインターネットドラフトを参考情報としてご活用ください。なお、このインターネットドラフト要求条件に準拠したNATを「キャリアグレードNAT」と呼ぶことを考えています。

キャリアグレードNATの要求条件やサービス影響についてはJANOG22にてプレゼンしますので、参加される方はお楽しみに。結論から言うと、キャリアグレードNATを使うことでIPv4端末は既存サービスを”ある程度”使えますが、各種サービスにどうしても影響が出てしまいます。ということでIPv6への速やかな移行がやはり必要です。

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

2008.07.01

P2Pシステムのインターフェース規定共通化の提案

P2Pシステムについては各アプリケーションが最適に動くように実装されており、インターフェースやAPIが共通化、標準化されていないのが現状だ。

ただし構造化オーバーレイのAPIについては抽象化の検討を行った著名な論文がある。
Towards a Common API for Structured Peer-to-Peer Overlays

構造化オーバレイを研究する人には避けては通れない論文で、各種構造化オーバーレイをどのようなAPIで規定すると動作できるかを検討している。Overlay Weaverの設計に大きな影響を与えている。

ネットワークインターフェースというと、共通化しようとする試みや抽象化して検討するという研究を少なくとも私は知らない。ここで言うネットワークインターフェースとは構造化オーバーレイ(あるいは非構造化オーバーレイも含めることができるかもしれない。)のピア間で流通するコマンド、データ構造を規定することである。

制御信号の帯域はデータ転送用の帯域に比べて無視できるほど少ないので、インターフェースの規定には可読性の高いXMLが望ましいだろう。そうなると、分散システムでよく使われているSOAPや、あるいはRESTのようなものがうまく使えるかもしれない。

問題は構造化オーバーレイの制御信号について、どのようにすれば分類・網羅できるかということである。これは先ほど紹介したAPIの抽象化の検討が大きな参考になると思う。

まだ数分考えただけだが、以下のようなことがインターフェースとして考えられる。

・ピア操作系
-ピアの参加
-ピアの離脱

・(オーバーレイを維持するための)リンク操作系
-リンクの確認
-リンクの形成
-リンクの切断

・(オーバーレイ内に格納している)データ操作系
-データの格納(put)
-データの入手(get)
-データの削除(remove)

・ピア間で直接通信している場合のデータ操作系
-リンク確立
-データ送信/受信
-データ送受信終了
-リンク切断

・検索方法
-recursive
-iterative

・NAT越え系
-リレーノード検索
-ネットワーク(NAT)情報交換(ICEライク)

・スーパーノード系
-スーパーノード検索

・認証系
-認証

もう少し考えて見ます。
インターフェースの規定を決めることで、汎用的なシステムができ且つ開発期間が短縮できると思います。

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

« 2008年6月 | トップページ | 2008年8月 »