なんとなく実験 with SIProp開発記

「A P2P Approach to SIP Registration 〜SIPレジストへの P2P アプローチ〜」
というものが、2005/01/20にドラフトとして公開されていました。

そこで、ほぼ、ゼロに近い英語力((^-^;A)を総動員して、読んでみましたので
その辺の所感をば、少々。


●4. Peer-to-Peer Background
DHT-P2P の基本について書かれているようなので、P2P に興味がある方は、
「入門」として読んでみるとよいかと思います。

あまり、取り立てて面白そうなことは書いてなさそうです。

あと、全体を通して、Chord が、題材に取り上げられています。
私も、Chord は、よく知らないので、そのうち勉強してみようと思います。


●5. P2P SIP Overview
DHTを利用したP2Pを動かしたらどんな動作をするか？というものの
おおざっぱな解説ですね。まぁ、Overview ってタイトルですし。(^-^;A

SIP 的には、SIPProxyサーバ、ロケーションサーバ、レジストラ を、介した
RFC3261の16.12.1.1 Basic SIP Trapezoid を、どう回避して、UA間で通信
させるのか？ということになります。

SIP的なミソと思われるのは、ここ！

If the receiving node is not responsible for
the portion of the hash space corresponding
to that resource-ID, it will return a 302 -
Redirect response, and also report the node
nearest in the hash space that it is aware of.

問い合わせが来て、自分の管理下にないノードであれば、

「302 - Redirect response」

を返すことにより、他へ転送させようと言うわけです。
ウ〜ン、SIPの特性をうまく使った良い方法なんじゃないでしょうか。


●6. Architecture
基本アーキテクチャは、Chord ベースのようなので、こちらの知識が必要
かもとか思いましたが、どうやら、Chord のアーキテクチャ解説をしている
だけな様です。

ここを読むだけでも、Chord をある程度理解できそうな気がします。
というか、そんな気になりました。(^-^;A


●7. Headers and Parameters
●8. DHT Operations
●9. User-level operations
●10. Examples
このあたりが、具体的な実装に関わる話です。

事実上、Chord を SIP に併せて実装したらどうなる？ということが、延々と
書かれております。

まとめてみると、こんな感じでしょうか？
SIP(RFC3261など)に準拠した形で、P2P機能を持たせています。
こう考えると、やはり、SIPの拡張性はすごいですね。

・REGISTER メソッドによる、参加宣言。
・INVITE メソッドによる、セッションの確立。
・SUBSCRIBE / NOTIFY メソッドによる、プレゼンス通知。

・3xx応答リダイレクトによる、転送先（ルーティング）の指示。
・4xx応答による、不在通知。

・セッションタイマ（Expiresヘッダ）による、生存チェック。

・Require ヘッダ、Supported ヘッダによる、P2Pモード通知。

・下記ヘッダによる、ロケーション・ノード情報の伝達。
　Request-URIヘッダ
　Toヘッダ
　Fromヘッダ
　Contactヘッダ


●11. Security Considerations
●12. Open Issues
セキュリティーに関するお話。

あっ、あんまり書いてない。。。
詐称に関するモノだけ、書かれていますが、あまり目新しさはないかな。

事実上、NATもがんばって越えてねって書いてあるだけか。。。


●結論
ほとんど P2P な人向けの資料。どちらかというと初心者向き。
でも、SIP の可能性を感じさせてくれる資料でもあります。

P2P に、興味がある方は、是非とも、読んでみることをお奨めします。


●おまけ
んで、議論の方は、こちらで進んでいる模様。
この辺は、また、苦労して読んでみます。
ここに、Chord の資料もあります。

あと、ほかに、こんなのもあるようです。
こちらは、SIPをP2Pプロトコルとして使うには、どんな方法論があるかという
読み物的なモノのようです。
http://www.ietf.org/internet-drafts/draft-johnston-sipping-p2p-ipcom-01.txt
http://www.ietf.org/internet-drafts/draft-matthews-sipping-p2p-industrial-strength-00.txt

こちらのエントリーでご紹介したちえらぼに行って参りました。

「ユビキタス・コーディネーター」こと「田中ヨヘイ」さんに会ってきました。
(上記のエントリーで、書かせて頂いた情報リークの張本人様です。(^-^;A
って、書いて怒られないかな？)

んで、なんと、田中さん、このblogを知っておられました。こんな辺境の地にある
blogを見てくださっていたとは、、、ちょっと、おどろきです。


さて、肝心の展示アイテム「ショッピングサポーター」についてですが、
ちょっと、驚いてしまいました。

これ、以前のエントリーに書かせて頂いた「エージェント」に似ているんですよ。

どんなモノかというと、RFIDに書き込まれた個人情報と今居る場所情報を基にして
その状況に応じた情報をPushするというようなシステムのようなのです。

まだ、インテリジェンスと言うには少々厳しいですが、それなりに情報を分析
解析し、個人にあった情報を提供するという意味では似ていると思っております。

そして、さらに、ネタを持っていらっしゃるようで、情報処理学会論文誌の
第46巻 第2号に、

「ユビキタスコンピューティング環境に適したサービス提供アーキテクチャに
　おけるサービス合成方式とその実装」

という論文を出していたり、他にも自らの名前を冠した「YOHEIX」なる P2P File
Sharing の基盤もあるとか。

これらでは、さらに、適用範囲を広げて、WebサービスやSOAのようなものと
連携させて、より広範囲に適用できるようにしているのです。

この辺、私の想像しているモノに近いです。
さらに、技術革新が進めば、セマンティックWebなどの利用して、外部から
意味のある情報を集めることが出来るようになるので、そうなれば、もっと
精度が上げられると期待しています。

という感じで、大変刺激を受けて参りました。
明日は、アレゲなイベントが14時からあると言うことですので、間に合うよう
なら参加したいなと思っております。


ちなみに、次回のちえらぼは、○芝さんのHDRに負けないようなコードネームで
肩書きを決めるとヨヘイさんは、申しておりました。ぺこ <(＿ ＿)>

ん？なんのことかわからないですって？
まぁ、↓とか。。。(^-^;A
http://www.itmedia.co.jp/lifestyle/articles/0503/14/news014.html

エッセンシャルSIP

ソフトフロント社執筆のSIP本の新刊です。
「あっ、やられた！」という、感じです。

なぜなら、プロローグが、

「SIP=IP電話ではない」

と、きました。
さすが、わかってらっしゃると叫んでしまいましたよ。（ｗ
(まぁ、私になぞに言われたくはないかもしれませんが。)

ということで、雑感を少々。


●第一部
SIPをちょっと知っているというのでしたら、もう、見飽きた内容でしょう。
VoIPに関するシーケンスなどの解説です。


●第二部
ここからが、「本命」の内容となります。

SIMPLE の具体的な内容が書かれています。
簡単に言えば、IMに関するSIPの使用法ということです。

VoIP では、滅多にお目にかかれない、SUBSCRIBE,NOTIFY,MESSAGE,PUBLISHあたりが
でてきます。

私の知る限りでは、この辺について詳細に解説している書籍はなかったと思います。
VoIP をメインでやっているSIP屋さんには、ぜひぜひ、読んで頂きたいところです。

SIP に対して、新しい視野が拓けてくること請け合いです！

ちょっと、飛躍はしてしまいますが、SIP の P2Pプロトコルとしての可能性も感じて
もらえるのではないでしょうか？


●第三部
SIPより下位のレイヤーのお話ですが、SIPを使用するためにどのような必須技術が
あるかのお話です。

個人的に不思議な点として、m2m-x が、数行しか書かれていないのですが、、、
なんでなんでしょう？

・第10章
必見です。
SIPに関する情報源の一覧が載っています。

興味がありそうなところのMLに片っ端から登録してしまいましょう！


●第四部
「SIP教科書」でおなじみのシーケンス解説です。

フォークと3PCCが、新たに追加されています。

「初代SIP教科書」「改訂版SIP教科書」と合わせれば、VoIPに必要なシーケンスの
ほぼ、全域がカバーされます。

・第12章
私的には、涙抜きでは読めないところです。（ﾉД｀）ｼｸｼｸ
詳しくは、書けませんが、まぁ、避けては通れない「最初の一歩」ですよね。


●まとめ
とりあえず、「SIP屋さんは買え」という、必携の書ですね。

Palmの生みの親、人工知能分野の新会社設立へ--PCフォーラムで発表

という記事が出ておりました。
AIですよ、AI。

実は、この辺で、思うところがあるので、書いてみたいと思います。


●現在-未来
現在、ネットの世界は「ユビキタスの時代」と言われていて、次に来るのが
「セマンティックの時代」なんて言われていたりします。
そして、私的には、その先に「エージェントの時代」が、来るのではない
かと、考えております。


●エージェントとは？
「エージェント」が、何を指しているかというと、AIを持った下記のような
ソフトをイメージしています。（UI的にというのではなく、動作的にです。）

デスクトップ・エージェント(マスコット?) 「春菜」
一言で言えば、RSSリーダーのUI部分を人に見立てたモノ
「偽春菜」「何か」「伺か」のほうが、有名ですかね？

これに、AIが搭載されることにより、例えば、

・株をやっている
・個人情報保護法の施行が決定する

といった情報を得た場合、これらの情報を考慮し、

・セキュリティー関連の株を検索して、有望株の
　購入を勧める

みたいな感じで、動作するモノを想定しています。


●思考パターン
こんなことを思考した流れとしては、下記の流れを辿っています。

「ユビキタス」で、いつでもどこでも繋がるようになる
「セマンティック」で、全ての情報が意味を持つようになる
「エージェント」で、情報を解析して必要なモノだけを選別
できるようになる。

これを、P2Pアプリっぽいものと組み合わせたら、面白そうじゃないですかね？
この辺も、いろいろと妄想していたりしますが。。。

まっ、ここまで来るには、障壁が恐ろしくありますので、あと何十年かかる
ことやら。。。
早くバンダイさんが、ドラえもん作ってくれないかなぁ。（笑

うぬぬ、yusukeさんのエントリーに、取り上げられてしまった。。。
これは、我に、反応しろと言っているに違いない！(^-^;A

ということで、軽く反応してみます。

まず、yusukeさんもおっしゃっているように、これ自体に目新しさや驚きは全くと
言っていいほど無いです。
yusukeさんのエントリーにも書いてあるように、元々蜜月状態であったからです。

次期OS Longhornにどれぐらいの機能が入るかは
不明瞭だが、将来のパスの中には、
MS Office全製品のP2P対応が入っているのでは
ないだろか。

こちらのエントリーに書かせて頂いた「Istanbul・次期Windowsメッセンジャー」ですが、
こちらのサーバとして、Microsoft Office Live Communications Server 2005と、
言うモノがあります。

見ての通り、Officeの名前を冠する「Microsoft Office System」の一製品だったりします。

そして、これらのAPIが、Longhorn に標準で載ってきます。

さらに、MS-OneNote2003 には、MSNメッセンジャーのホワイトボードみたいな
編集している画面を共有するような機能が載っています。

これらのことより、yusukeさんの予想通り、将来のパスにP2P技術は、組み込まれて
いると言って良いでしょう。

クライアントがWebサービスとP2Pを手に入れた後、
企業アプリケーションはどう変わるだろうか。
かなり楽しみなだ。

まさに！おっしゃるとおり！
私も、絶対に何かしら革新的なキラーアプリがあると見ております。

いろいろネタ探しはしているんですが、思いつかないんですよねぇ。凡人な私には。（ﾉД｀）ｼｸｼｸ
誰か、ネタくれ〜〜〜。（ｗ
(あっ、また、他力本願で落ちてしまった。(^-^;A)

第2回P2P勉強会 で、お知り合いになった方より、話は聞いていたのですが、
「出しちゃダメ」と口止めされていたので、放置しておりましたが、このたび
正式に公開されたようですので、告知を兼ねて、ご紹介です。

ちえらぼ

内容としては、NTT内で「若手が」研究的にやっているモノの発表の場っと
いうところです。
この「若手」というところが、ミソのようでして、ご覧のようなサイトと
なっております。（ｗ
(こんな説明でいいのかな？怒られたりして。(^-^;A)

ちなみに、私の方は、3/25(金)のほうで、参加しようかなと画策しており
ます。

さきほど、初Bluetoothデバイスとして、対Skype用にヘッドセットを買ってきました。

モノは、corega製の

「無線 USBアダプタ CG-BTUSB01」(以下、レシーバ)
「ワイヤレスヘッドセット CG-BTHS01」(以下、ヘッドセット)

です。

早速、インストールしてみたのですが、はまりまくりました。（ﾉД｀）ｼｸｼｸ
なので、その顛末を書いてみようと思います。
誰かの役に立つかもしれませんので。(^-^;A

●電源と認識の罠
最初は、レシーバをWindows君に認識させてあげないとなりませんので、USBに
接続してみました。
なんと、WindowsXP SP2では、デフォルトドライバで、一発認識！すばらしい。

つづいて、

「ペアリング設定」

というモノをしないとならないので、それを行います。
これは、このレシーバとデバイスの認証儀式で、デバイスの初回認識時にやらねば
ならないようです。

早速、ヘッドセットの電源をONにします。
電源を入れるには、「MODEボタンを7秒の長押し」と書いてあったので、実行。
LEDが、青く点滅を始めたので、電源は入ったようです。

そして、Bluetoothデバイスコントローラを立ち上げ、認識ボタンをクリック！
・・・認識されず。＿|￣|○　ガックシ・・・

何度やっても、ダメです。（ﾉД｀）ｼｸｼｸ


・別モード発見
説明書を読むこと3回目、

「ペアリング設定時は、MODEボタン10秒の長押しで
　特別モードにする」

という記述を発見。＿|￣|○　ガックシ・・・

早速、10秒長押ししてみると、見事認識しました。ヽ（´▽｀）ノ

●デフォルトドライバの罠
認識が正常に出来たので、早速、Skypeを立ち上げて、サウンドデバイスを
ヘッドセットに切り替える・・・ことができず。（ﾉД｀）ｼｸｼｸ

どうやっても、ヘッドセットに切り替えることが出来ず。＿|￣|○　ガックシ・・・

いろいろと調査を開始・・・・。

どうやら、

「サービスとBluetoothデバイスを結びつけを行う
　必要がある」

ということのようです。
サービスとは、OSに対して、Bluetoothデバイスをキーボードやスキャナとして
みせるためのドライバみたいなものらしいです。
キーボードやマウス、LANなど、いろいろと定義されているようです。

そこで、サービスのインストールをしようとしてみるが、見つからず。。。
どうやるのか、全然わからない。


・corega謹製ドライバの登場
よって、

「XP には、サービスが付いていないに違いない」

と判断して、corega謹製ドライバをインストールしてみました。

corega謹製ドライバ君、サービスもインストールしてくれました！

そして、再度、ヘッドセットを認識させたら、ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!
成功です。ちゃんと、サウンドデバイスとして使用可能となりました。

●保留の罠
早速、音が聞こえるか実験開始・・・全然、聞こえない。＿|￣|○　ガックシ・・・
ピポーッって音が、定期的に聞こえてくるだけです。（ﾉД｀）ｼｸｼｸ

う〜ん、なぜだ。。。

ミュージックプレーヤなどでも実験してみるが、うまくいかないです。
何も、音が流れてきません。


・MODEボタン再び
そこで、ふと、「ピポーッ」音があまりに定期的なので、「保留音かも？」と
いう考えが頭をよぎりました。

ということは、もう一回MODEボタンを押したら解除できるかもしれないと
思い、おそるおそるMODEボタンを押すと・・・音が聞こえたよ、ママン！！！

どうやら、「ピポーッ」音は、保留音で、

「電源ON＝保留状態での起動」

ということのようです。これには、してやられました。


以上、3時間くらいの戦いでした。。。長かったですが、無事、動作させることが
出来ました。。。
Bluetooth使うときは、お気をつけください。＜って、こんなのはおまいだけだって。

事務局の方のSTMに関する説明とNOC(ネットワークの責任者チーム？)の方に
よる、実際に参加されたときの実体験談というような構成でした。

NOCの方は、みなさん、経験豊富な猛者という感じで、ぜひとも、濃ゆいお話を
させて頂ければなぁと言うところ感じで、ぜひとも、STMとして参加する決意を
新たに固めた次第であります。


今回から追加されたというHotstage(試験構築)、ぜひとも、参加したかった
なぁ。
ちと、スケジュールの都合上、どうにもならなそうだったので、今回は、
本戦からの参加です〜。


STM参加者は、全部で10人ちょっとで、学生さんっぽい人が多い感じでした。
(会場が、SFCだったというのも影響していると思います。)

また、一応、合否があるようなのですが、募兵会が全3回、募集MAX人数が42名と
いうことを考えると、落選する理由は、下記くらいしか思いつかない様な気も
しますが。。。
まぁ、こんな事書いておいて落選したら目も当てられないですが。(^-^;A

・参加可能日が少ない
・勤め先の影響
・他の会場がよほど人数が多い

結果は、4/16以降にメールで通知されると言うことですので、気長に、
待っていることとします。
合格したら、6月の第一週は、連絡とれませんので、あしからず。

Java Computing 2005 Spring に、行ってきました。

今回のお目当ては、

「EJB の仕様策定リーダーである Linda DeMichielの基調演説」

で、聞いてきましたので、その感想をば、少々。

ええと、その〜、、、

「寝てました。」ぺこ <(＿ ＿)>

いや、だって、、、いままでのEJBの歴史とEJB3.0についてなん
ですモン。
もう少し、先の話とか聞きたかったんですが。

それゆえに、途中で、気絶してしまいましたよ。(^-^;A

先日から、知り合いの関係で検索エンジンについて調査しているの
ですが、何か良い情報をお持ちの方いませんか？
何か、良い情報をお持ちでしたら、こそっと教えてください。

今は、下記のモノを調査中。。。

・LUCENE
Jakartaプロジェクトのテキスト検索エンジン

・SEN
Java用の形態素解析

・Nutch
Jakartaのインキュベーター中の検索エンジン

・Grub
Grid的なWebクローラー


おまけ
・ぐぐるさんのデータセンター

う〜ん、すごい。全て、自作ですか。。。さすが。

Google File Systemと呼ばれる自前のファイルシステムも開発した。
これは、64Mバイトという巨大なデータブロック・・・

64Mですか！一ブロックが。。。すてきなファイルシステムです。

Linux Kernel 2.6.11 リリース

しかし、相変わらずchangeLog 見にくいですねぇ。。。
せめて、ジャンル別とか表示できないかなぁ。

ということで、個人的に気になったモノを抜き出してみました。
かなり、偏見と無能に満ちたモノとなっています。(^-^;A


●IPv6
IPv6まんせ〜！ ということで。

実装ミスっぽ。
・[IPV6] Don't update FAILED entries on receipt of NAs.

As NAs do not create new entries (RFC2461 7.2.5),
NA should not change state of FAILED entries.

●TUN/TAP系
自宅のIPv6環境にて使用中のTUNドライバ関連。

今回の目玉かな？ queuingが改良されてるっぽいっす。
・TUN/TAP driver packet queuing fixes and improvements

Patch from Harald Roelle

Fixes for the following issues
- "Kicking" packet behavior in case of kernel packet scheduler (! TUN_ONE_QUEUE):
When the netif queue is stopped because of an overrun of the driver's queue,
no new packets are delivered to the driver until a new packet arrives, not even
when in the meantime there's again space in the driver's queue (gained by a
reading user process). In short, whenever netif queue was stopped, one needs an
additional packet to "kick" packet delivery to the driver.
The reason for this is, that the netif queue is started but not woken up, i.e.
the rest of the kernel is not signaled to resume packet delivery.

- Adjustment of tx queue length by ifconfig has only effect when TUN_ONE_QUEUE
is set. Otherwise always constant TUN_READQ_SIZE queue length is used.

- TX queue default length setting is not consistent:
o TAP dev + TUN_ONE_QUEUE: 1000 (by ether_setup())
o all other cases: 10

- Default tx queue length is too short in many cases.
IMHO it should be at least twice as long as the number of fragments needed
for a maximum sized IP packet at a "typical" MTU size.
This would ensure that at least one complete IP packet can be delivered
to the attached user space process, even if the packet's fragments
are "misaligned" in the buffer and the user process is not scheduled
in time to read the queue.

Additional modifications:

- To signal that stopping of the queue has occurred, the tx fifo overrun
counter is increased.

- Implemented ethtool api. Primarily added to have a standard method requesting
the driver version.

Signed-off-by: Max Krasnyansky

Use random_ether_addr() to generate TAP MAC address.


まぁ、まんまですが、私的に影響ありそうなので。
・[PATCH] Multicast filtering for tun.c

From: Shaun Jackman

This patch adds multicast filtering to the TUN network driver, for
packets being sent from the network device to the character device.

* drivers/net/tun.c: Add multicast filtering for packets travelling from
the network device to the character device.

* include/linux/if_tun.h (tun_struct): Add interface flags, a hardware
device addres, and a multicast filter.


「Please test if this helps in your case」って、そんな。(^-^;A
・[TUN/TAP]: Add missing trans_start and last_rx setting.

But as stated in bonding.txt, the ARP monitor requires the underlying
driver to update dev->trans_start and dev->last_rx.

The patch below adds the required functionality to the TUN/TAP driver.
Please test if this helps in your case.



●TCP/UDP系
●UML系
●netfilter系
●SELinux系
う〜ん、ざっと見た限りでは、面白そうなのなし。


●ねた！！！
「crazy Mac OS-X TCP implementations」って。(^-^;A
・[TCP]: Set PSH bit on all outgoing TSO frames.

Helps with crazy Mac OS-X TCP implementations which delay the
recvmsg() wakeup of the user until push is seen.

Based upon ideas from Alexey Kuznetsov, and a preliminary
patch by Stephen Hemminger.

今回は、アップデートは見送りかなぁ。
安定したって書いてあるけど、微妙だし。。。

こちらで、Windows用のrootkitチェックツールが紹介されていましたので、
さっそく、遊んでみました。

SysinternalsがWindows版rootkitを検出する無償ツールを公開

ひとまず、紹介文を読み限りでは、まだ、検知漏れがあるなど、発展途上に
あるツールのようですが、リモートからのチェックも可能なようですので、
今後のバージョンアップには期待できるのではないかと思います。


●機能
現在の機能的には、このようなモノがあるようです。
内容としては、APIを通して書き込まれたデータと実際に書き込まれたデータの
チェック機能と隠し領域のチェック機能と言うところでしょうか?
まだまだ、足りないという感じですね。　kernel空間のチェックとか。

・Hidden from Windows API.
・Access is Denied.
・Windows API length not consistent with raw hive data.
・Key name contains embedded nulls.
・Data mismatch between Windows API and raw hive data.

●実験
そして、早速実験してみました。

う〜ん、走らせて終わりっすね。

なぜなら、rootkit 持ってないから、何も検知されないため。（ﾉД｀）ｼｸｼｸ
残念！

プレスセッションで6番目の「T」が追加

IntelCPUに、新たなテクノロジーが発表になったとのこと。

「Intel I/O Acceleration Technology」と呼ばれる
新たな「T」が発表された。
これは、今日まで転送方法が変更されていないTCP/IP
の転送を改善する技術である。
これまでよりアプリケーション性能が30％向上する
という。

まじっすか？これ？30%UPって、すごいね。
まだ、詳細は発表されてないようですが、実装とかはどうなるんでしょ？
楽しみな技術ですね。


さて、もう少し、考察してみましょう。

Vanderpool Technology(VT)・・・仮想化支援
LaGrande Technology(LT)・・・セキュリティー支援
Active Management Technology(AMT)・・・障害復旧支援

と言ったテクノロジーも付加されると言うことですので、これらをまとめると
やはり、Xenのようなものに必要な機能なんですよね。

VTは、言わずもがなですね。
LTは、他人とPCリソースをシェアしようとする場合、他人にデータを見られない
ようにするために必要です。
(LTは、WindowsのNGSCBと連携するやつですね。本来は。)
AMTは、リモートからの復旧ができる、これってリモートでサーバを管理するには
結構重要なんです。

そして、当然、これらがXenのようなモノを介す場合、ネットワークを経由します。
そのときに、「Intel I/O Acceleration Technology」が役に立つわけです。


こう考えると、Intelは、こちらの方向を見ているのかなと言う気がします。
(まぁ、Intelは、Xenに出資してますし。)