Libjingle
Mikio Yoshida
最近、Libjingle について（ごく浅く）見てみたので、メールします。
http://code.google.com/apis/talk/about.html
Libjingle は、Google Talk を構成するライブラリで、公開されたのは昨年の
クリスマスの頃でしょうか。
＃その後、あまり反響が出ていないのはなぜだろう？
C++ で書かれたライブラリで、NAT越え機能が実装された p2p モジュールを含
んでいるので、実用的な P2Pアプリを作る人にはうれしい内容だと思います。
NAT越えのプロトコルには、ICE (Interactive Connectivity Establishment)
http://ietfreport.isoc.org/all-ids/draft-ietf-mmusic-ice-06.txt
を使っています。STUN と TURN を統合的に扱う規格で、性能を考慮においた
ネゴシエーションをしつこくするところが特徴です。
Libjingle は（ICEも）、UDP だけを使いますが、TCPを使いたい人向けに、
PseudoTcp というクラスが用意されていたりもします。
これは、p2p モジュールよりは上のレイヤになりますが、
Jingle や XMPP というのは、元は Jabber から来ていますね。
Jabber はご存知の方も多いと思いますが、インスタントメッセージングのオ
ープン規格化を狙ったプロジェクトです。skype の登場ですっかりなりを潜め
た感がありますが、後発の google にとっては乗っかりやすかったんでしょう
ね。Google Talk によって、Jabberが生み出した規格が盛り返しを見せるので
はないかと期待します。
私自身は、Libjingle の p2pモジュールに興味がありますが、
Google Talk は、Libjingle の公開によって、プログラマにとって全然遊べな
かった skypeの代わりをしてくれるオープンな道具になったような感じがしま
す。
---
吉田 幹 y...@bbr.jp
Daishi Kato
最近は熱がさめてしまいました。
skype a2aはダメですか?
At Thu, 02 Nov 2006 16:16:38 +0900,
Mikio Yoshida
skype API はskype の拡張しかできないと思ってました。
Libjingle の場合、もっとオープンな世界で遊べるというのが印象ですが、
＃でも、あまりはやっていない ?!
加藤さんはどこで熱がさめたのですか？
In message, Daishi Kato <dai...@cb.jp.nec.com>-san wrote on
Thu, 02 Nov 2006 16:36:53 +0900...
---
吉田 幹 y...@bbr.jp
Kazuyuki Shudo
> 特に、SIP, VoIP に興味のあるみなさま
SIP 単体にそれほど興味はなかったのですが、
ICE, NUTSS など、NAT 越えの主要技術に SIP を前提とするものが多い気がして、
そういう意味で気になってます。
NUTSS: NAT, (SIP の) URIs, Tunnels, SIP, STUN を基本とした
インターネットアーキテクチャ
http://nutss.net/
> 最近、Libjingle について（ごく浅く）見てみたので、メールします。
> http://code.google.com/apis/talk/about.html
10月末あたりに、p2p-hackers ML で名前が出てたのを覚えてます。
最初にリリースされた際は、記事を流し読みしてました：
ITmedia エンタープライズ: Google TalkのAPIとソースコードのリリース
http://www.itmedia.co.jp/enterprise/articles/0601/18/news003.html
ありえるえりあ (井上さん): ジングルベル from Google (libjingle)
http://dev.ariel-networks.com/blog/index.php?itemid=711
> C++ で書かれたライブラリで、NAT越え機能が実装された p2p モジュールを含
> んでいるので、実用的な P2Pアプリを作る人にはうれしい内容だと思います。
Java で書かれていれば、Overlay Weaver (OW) で使うんですが...
でも、(JNI で) wrapper を用意してでも使う価値があるかもしれません。
その場合、OW のメッセージングサービスの
UDP 実装や TCP 実装と同様に、
ow.messaging.libjingle というパッケージを用意することになります。
UDP 実装は 1025 行、TCP 実装は 698 行と小さいので、
libjingle 実装もそれほど大変でもなさそうです。
% cd ~/workspace/overlayweaver/src/ow/messaging/udp/
% wc *.java
71 234 1930 SocketPool.java
453 1235 12311 UDPMessageReceiver.java
206 578 5477 UDPMessageSender.java
76 236 2190 UDPMessagingAddress.java
77 332 2847 UDPMessagingConfiguration.java
34 153 1157 UDPMessagingMessageFactory.java
108 333 3361 UDPMessagingProvider.java
1025 3101 29273 total
% cd ~/workspace/overlayweaver/src/ow/messaging/tcp/
% wc *.java
108 367 2945 ConnectionPool.java
246 708 6881 TCPMessageReceiver.java
136 377 3791 TCPMessageSender.java
76 236 2190 TCPMessagingAddress.java
32 153 1160 TCPMessagingConfiguration.java
100 318 3091 TCPMessagingProvider.java
698 2159 20058 total
> NAT越えのプロトコルには、ICE (Interactive Connectivity Establishment)
> http://ietfreport.isoc.org/all-ids/draft-ietf-mmusic-ice-06.txt
> を使っています。STUN と TURN を統合的に扱う規格で、性能を考慮においた
> ネゴシエーションをしつこくするところが特徴です。
ICE, STUN, TURN について、この間、短い説明を書きました：
技術フェチ日記 2006/8/5 分
http://www.shudo.net/diary/2006aug.html#20060805
ICE:
SIP でのセッション確立の際に、SIP ユーザエージェントが自らのトラン
スポートアドレスとして複数の様々なアドレスを相手に渡す。これによっ
て、品質のよい接続方法の選択や NAT 越えが可能となる。様々なアドレ
スとは例えば、STUN で得られる NAT 外側のアドレス/ポートや、TURN サー
バの public アドレス、IPv4/v6 アドレス等。
首藤一幸
Daishi Kato
Mikio Yoshida wrote:
> skype API はskype の拡張しかできないと思ってました。
ま、そうですけど。
> 加藤さんはどこで熱がさめたのですか？
いろいろありますが、例えば
大容量ファイル転送アプリを作りたかったが、
FolderShareとかAllPeersがよく知られるようになったと感じたから。
Mikio Yoshida
In message, Kazuyuki Shudo <20...@shudo.net>-san wrote on
Thu, 02 Nov 2006 18:30:24 +0900 (JST)...
> 吉田さん、皆様、首藤です。
>
> > 特に、SIP, VoIP に興味のあるみなさま
>
> SIP 単体にそれほど興味はなかったのですが、
> ICE, NUTSS など、NAT 越えの主要技術に SIP を前提とするものが多い気がして、
> そういう意味で気になってます。
>
> NUTSS: NAT, (SIP の) URIs, Tunnels, SIP, STUN を基本とした
> インターネットアーキテクチャ
> http://nutss.net/
skype, SIP に興味がある人が多いのじゃないかと思って、こういう書き出し
にしましたが、SIP と P2Pアーキテクチャの関係は強いと思っています。
SIP との関係はないですが、こんなのもあります。
STUNT (Simple Traversal of UDP Through NATs and TCP too)
http://nutss.gforge.cis.cornell.edu/stunt.php
こちらは C# で提供されてますね。
TCP については、P2Pアーキテクチャで扱うのはしんどそうです。
> > 最近、Libjingle について（ごく浅く）見てみたので、メールします。
> > http://code.google.com/apis/talk/about.html
>
> 10月末あたりに、p2p-hackers ML で名前が出てたのを覚えてます。
私もチェックしました。
ICE すごいなあ、と思ってたんですが、
・やっぱり、symmetric は対応できないじゃん
・ネゴシエーションしすぎ、セッション確立に 1600ms もかかる
という意見が気になりました。
実は、Libjingle についても、p2p モジュールが jingle 依存になっている部
分があるみたいでこちらも気になっています。
> 最初にリリースされた際は、記事を流し読みしてました：
>
> ITmedia エンタープライズ: Google TalkのAPIとソースコードのリリース
> http://www.itmedia.co.jp/enterprise/articles/0601/18/news003.html
>
> ありえるえりあ (井上さん): ジングルベル from Google (libjingle)
> http://dev.ariel-networks.com/blog/index.php?itemid=711
はい、見ました。ご紹介ありがとうございます。
> > C++ で書かれたライブラリで、NAT越え機能が実装された p2p モジュールを含
> > んでいるので、実用的な P2Pアプリを作る人にはうれしい内容だと思います。
>
> Java で書かれていれば、Overlay Weaver (OW) で使うんですが...
実は、私、似たようなものを作り始めてます。
だいたいの設計をしてから、Libjingle をチェックしていたという次第です。
org.piax.p2ptran というパッケージ名で、piaxより先にオープンソースとし
て切り出す予定です。もちろん汎用部品としてです。
今、このせいで頭はかなりウニが入っています。
＃乞うご期待＆過度には期待しないで。。
あっ、本当ですね。見落としてました。(^^♪
---
吉田 幹 y...@bbr.jp
Mikio Yoshida
>
> STUNT (Simple Traversal of UDP Through NATs and TCP too)
> http://nutss.gforge.cis.cornell.edu/stunt.php
>
> こちらは C# で提供されてますね。
> TCP については、P2Pアーキテクチャで扱うのはしんどそうです。
ごめんなさい。C, C++, Javaのコードもありました。
---
吉田 幹 y...@bbr.jp
Mikio Yoshida
Thu, 02 Nov 2006 19:11:22 +0900...
> > > C++ で書かれたライブラリで、NAT越え機能が実装された p2p モジュールを含
> > > んでいるので、実用的な P2Pアプリを作る人にはうれしい内容だと思います。
> >
> > Java で書かれていれば、Overlay Weaver (OW) で使うんですが...
>
> 実は、私、似たようなものを作り始めてます。
> だいたいの設計をしてから、Libjingle をチェックしていたという次第です。
> org.piax.p2ptran というパッケージ名で、piaxより先にオープンソースとし
> て切り出す予定です。もちろん汎用部品としてです。
あっ、これ、あくまでも補足情報です。
Libjingle 対応も検討してくださいね。やめてこっちを使ってという意味では
ありませんので、、
（自分も興味ありますし）
補足ついでに Libjingle との違いも紹介します。
・TCP, UDP の両方を扱う。
・NAT越えは、full cone, restrected cone, port restrected cone まで。
越えれないやつは、relay を使う。
ICE は使わない。
そのため、複数候補があるときの選択基準を入れれる機能を持たせる。
・P2P間で、TLSセッションも張れる。（ハンドシュークは TCP前提）
・コネクション、セッションプーリングもやる。
・まとめると、上位レイヤには、
unreliable, reliable, secure という属性を持つ仮想的なP2Pトランスポー
トを提供することになります。
インタフェースとしては、
java.nio.channels.ByteChannel のようなものを想像してください。
・おまけとして、1対多の通信もサポートします。
mutlicast, anycast と multisink（今作った用語）もできるようにという
意図です。（これは、PIAXで必要なんで）
と盛りだくさんですが、実装の都合で機能を落とすかもしれません。(^^;;
---
吉田 幹 y...@bbr.jp
Noritsuna Imamura
SIP屋の今村です。
> 特に、SIP, VoIP に興味のあるみなさま
おっと、ということであれば、是非、私もSIPの現場からの叫びを、
ちょっとだけ。(;^_^A アセアセ・・・
> Google Talk によって、Jabberが生み出した規格が盛り返しを見せるので
> はないかと期待します。
私も、来年くらいにJabberは、来るのではないかと思っていたりします。
Google Talk と
Skypeとの相互接続もやるとのことですので、これも
ひとつのブレイクのきっかけになりそうですね。
そして、一番期待しているところが、Asteriskの次期バーションですね。
次期バージョンで、Jabber／Jingle／GoogleTalkプロトコルが追加予定
ですので、このあたりがキモになって一気にブレイクしそうな気がしてます。
※Asteriskは、オープンソースのIP-PBXです。最近、急速に普及しており
SIP周りでのキーワードの一つです。
PBX版のLinux(オープン)とUNIX(プロプライエタリ)というような感じで、
対比されていたりします。
http://www.asterisk.org/
> skype, SIP に興味がある人が多いのじゃないかと思って、こういう書き出し
> にしましたが、SIP と P2Pアーキテクチャの関係は強いと思っています。
P2Pアーキテクチャ(Overlay
Network)が、Peerまでのルーティングをするものと
考えれば、SIPは、Peer間のサービス(機能)を提供するためのプロトコルといえ
ると思いますので、関係性は非常に強いと思います。
Kazuyuki Shudo
> そして、一番期待しているところが、Asteriskの次期バーションですね。
> 次期バージョンで、Jabber／Jingle／GoogleTalkプロトコルが追加予定
> ですので、このあたりがキモになって一気にブレイクしそうな気がしてます。
>
> ※Asteriskは、オープンソースのIP-PBXです。最近、急速に普及しており
> SIP周りでのキーワードの一つです。
Asterisk については、9月末発売の雑誌に記事がありました。
(立ち読みしました。)
ネットワークマガジン 2006年 11月号
http://nmag.jp/archives/2006/09/200611.html
Jabber, Jingle, GoogleTalk 対応についてはまったく知りませんでした。
Kazuyuki Shudo/首藤一幸 私をたばねないで あらせいとうの花のように
20...@shudo.net http://www.shudo.net/
Noritsuna Imamura
首藤さん、今村です。
> Jabber, Jingle, GoogleTalk 対応についてはまったく知りませんでした。
そうなんですよね。この辺、あまり取り上げられてないみたいでして。
日本のAsteriskまわりですと、PBX系の機能が一段落しつつある状況です。
そうすると、インターネット電話的には、次は、プレゼンス実装という流れが
一般的ですので、重要な追加機能だと思うのですが。。。
Kazuyuki Shudo
> > NUTSS: NAT, (SIP の) URIs, Tunnels, SIP, STUN を基本とした
> > インターネットアーキテクチャ
> > http://nutss.net/
> SIP との関係はないですが、こんなのもあります。
>
> STUNT (Simple Traversal of UDP Through NATs and TCP too)
> http://nutss.gforge.cis.cornell.edu/stunt.php
STUNT は、NUTSS を言い出した先生のグループが作ってるようです。
というか、ウェブページに書かれてる「Researchers」が完全に一致してます：
Saikat Guha, PhD Student
Paul Francis, Professor
FAQ リストには、こういうことが書かれてます：
・NAT の裏にいるノード間で TCP の接続を張る。
接続は、プログラムからは SocketChannel として見える。
・通常のソケットより、確立に時間がかかる。
・通信エンドポイントの識別子としては、IP アドレス + ポート番号ではなく、
メールアドレスのような URI を使う。
・動作には、rendezvous server (like a directory server) が必要。
また、STUNT サーバ (some STUNT servers) も必要。
最初に実装されたのが、Java 版だったようで、
FAQ リストは Java 版を前提に書かれています。
STUNT は「Simple Traversal of UDP Through NATs and TCP too」の略なのですが、
FAQ は TCP での NAT Traversal を前提に書かれていて、
UDP での通信が可能なのかどうかは不明です。