libjingleのNAT越えの様子
またlibjingleいじり。
callサンプルはGIPS Media Engineが手に入らないし多分ただで商用アプリに使えなさそうだし、LinphoneもVisualC++環境ではコンパイルできないので、さくっとは動かない！
pcp（ファイル転送）サンプルの動きを見る。
コマンドラインオプションで -d をつけてpcpサンプルを動かすと、UDPホールパンチングの様子がログに流れる。
libjingleはLOG4Jっぽくログレベルを設定したりできていい感じ。
少しログ出力をカスタマイズしながら眺める。
基本的には、流れはこんな感じ。
自分のマシンの全てのローカルIP＋STUNサーバから取得したグローバルIPと、
相手の同じ情報、の全ての組み合わせを、優先度つけながら試していく。
ローカルIP > STUNで得られたグローバルIP ( > リレーサーバのIP )
これがICEって仕組みかな？
Interactive Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal for Offer/Answer Protocols
PLAIN TEXT
CODE:
[J]Conn[0:private-1:local:114.emobile:1116->private-1:local:192.168.174.1:2584|C-w|udp]: sendstun
[J]Conn[0:private-1:local:114.emobile:1116->private-1:local:5.rem_hamachi:2586|C-w|udp]: sendstun
[J]Conn[0:private-1:local:5.loc_hamachi:1119->private-1:local:192.168.0.2:2580|C-w|udp]: sendstun
Error(port.cc:310): [J]Port[private-1:stun:Net[0:114.emobile]]: Received STUN response with bad username2
[J]Conn[0:private-1:local:5.loc_hamachi:1119->private-1:local:192.168.88.1:2582|C-w|udp]: sendstun
[J]Conn[0:private-1:local:5.loc_hamachi:1119->private-1:local:192.168.174.1:2584|C-w|udp]: sendstun
[J]Conn[0:private-1:local:5.loc_hamachi:1119->private-1:local:5.rem_loc_hamachi:2586|C-w|udp]: sendstun
[J]Conn[0:private-1:local:114.emobile:1116->private-1:stun:61.stun_global:2581|C-w|udp]: sendstun
[J]Conn[0:private-1:local:5.loc_hamachi:1119->private-1:stun:61.stun_global:2581|C-w|udp]: sendstun
[J]Conn[0:private-1:stun:114.emobile:1118->private-1:local:192.168.0.2:2580|C-w|udp]: sendstun
[J]Conn[0:private-1:stun:114.emobile:1118->private-1:local:61.stun_global:2580|CRw|udp]: [r]CRw
[J]Conn[0:private-1:local:5.loc_hamachi:1119->private-1:local:61.stun_global:2580|CRw|udp]: [r]CRw
[J]Conn[0:private-1:local:114.emobile:1116->private-1:local:61.stun_global:2580|CRw|udp]: [r]CRw
[J]Port[private-1:local:Net[0:114.emobile]]: got request, send response
[J]Conn[0:private-1:local:5.loc_hamachi:1119->private-1:local:61.stun_global:2580|CRw|udp]: [...]
第3回オーバレイネットワーク研究会とGnutella調査中
第3回オーバレイネットワーク研究会行ってきました。
http://wslash.com/?p=1928
http://mixi.jp/view_event.pl?id=34638897&comm_id=6936
ISP側からの話がおもしろかったなぁ、考えたことも無かったので。
P2Pは一見ネットワークに優しそうだけれど
物理的なネットワークトポロジーによってはそうでもないよ、ってのが自分的には新しかった。
Server to Client
A ----> B
A ----> C
A ----> D
P2Pで例えばこうやってdeliverしようとしたら、
A ----> B
B -> C
B -> D
という話で、
実は物理的な距離として↓こんなだったら、
A--CD-----------------B
P2Pの場合は
B->C,B->Dの分、Server to Clientの方が実は全体的には効率的だよね。って話。
きっとかなりはしょってるんだろうけれど感覚的に理解できました。
そのためのP4Pという構想。
プレゼン後に、クライアント同士がtracerouteうちあえばできるんじゃね？
というのもおもしろそうだった。
あと、IPアドレスとLocation情報の組み合わせってお金で買えるんだけど、
っていうのもなんかうまくやり方がありそうだなぁ。
帰りがけ、「GnutellaもNAT越え実装してるよ、コード参考になるかもしれないね」
ってお名前を失念したどなたかに教えていただいたので、
（NAT越えできてない先入観があったので今さらだけど）
Gnutellaも調べる
http://en.wikipedia.org/wiki/Gnutella
詳しい
peerは以下のいずれかに分類される
leaf node / ultra node
自分のデスクトップ（ADSLルーターの下にいる）はleaf nodeってLimeWireに言われる。
NATの下にいるからだろうね。
P2Pファイルシェアリングアプリ入れるの久々だなぁ、WinMX全盛時代以来だ。
leaf nodeは、3つ程度の ultra peer に接続する。
一方 ultra peer は 32以上の ultra peer に接続する。
検索は、検索したいnodeが検索語のハッシュを Query Routing Protocol で、 Query Routing [...]
UDPホールパンチング整理（わかったかも）
わかったのかも → コメント参照
symmetric NAT以外の話、つまりFull Cone NAT,Restricted Cone NAT,Port-Restricted Cone NATなら
UDPホールパンチングを使って外から中向けのセッションを張れるようだ。
Full Cone NATとは
NAT内からNAT外へ出る(UDP)パケットを送って、マッピングをつくったら、
NAT外のどのIP,ポートからでも、そのマッピングを利用してNAT内にパケットを送ることのできるNAT。
Restricted Cone NATとは
Full Cone NATに加えて、一度NAT内からパケットが送信されたIPからのみ、そのマッピングを利用できるNAT。
Port-Restricted Cone NATとは
Restricted Cone NATに加えて、一度NAT内からパケットが送信されたIPとポートからのみ、そのマッピングを利用できるNAT。
Symmetric NATとは
NAT内からNAT外へ出るパケットを送って、マッピングを作っても、
その同じ宛先からのみ、マッピングを利用できるNAT。
逆に言うと、
NAT内からNAT外へ出るパケットを送って、マッピングを作っても、
違うIPとポートの組み合わせからはそのマッピング（＝NATの外側のIPとポート）からはNAT内にパケットを送れないNAT。
こいつに対してはTURNを使う。
簡略化のためIPは省略、Full Cone NATもRestricted Cone NATもPort-Restricted Cone NATも同じだから
一番厳しいPort-Restricted Cone NATだと思って考える
図
A< -------->NAT1(port6000)< -------->STUNサーバ< -------->(port10000)NAT2< -------->B
1. まず、AとSTUNサーバ、BとSTUNサーバは別々につながってる。
AはNAT1の外側ポート6000番を通してSTUNサーバと、
BはNAT2の外側ポート10000番を通してSTUNサーバとつながってる
A< -------->NAT1(port6000)< -------->STUNサーバ< -------->(port10000)NAT2< -------->B
2. STUNサーバが外側ポートを教える
STUNサーバは、Aに対して、「BはNAT2のport10000番にいるよ」って言う
STUNサーバは、Bに対して、「AはNAT1のport6000番にいるよ」って言う
A< -------->NAT1(port6000)< -------->STUNサーバ< -------->(port10000)NAT2< -------->B
A--------->NAT1(port6002)-------------->--------------->x(port10000)NAT2 [...]
XMPPでP2Pの音声チャットセッションを確立する方法1
頭を整理するためのMemo
GoogleTalkで使われているというjingle
XEP-0166: Jingle
XMPP protocol extension for initiating and managing peer-to-peer media sessions between two XMPP entities in a way that is interoperable with existing Internet standards
既存のInternet標準と共存できる方法で、２つのXMPPentities間でP2Pメディアセッションを確立、管理するためのXMPPプロトコルの拡張。
In essence, Jingle enables two XMPP entities (e.g., romeo@montague.lit and juliet@capulet.lit) to set up, manage, and tear down a multimedia session. The negotiation takes place over XMPP, and the media transfer [...]
第十二回SIProp勉強会行ってきた
全員初めてなのになんとかなりましたね。
みなさま（お酒が入ったせいか）話やすい人たちでよかったです。
ありがとうございました！
今日せんえつながら発言したadobeのP2Pのことは
FlashPlayer10のP2Pに過去書きましたよ。
正直P2P界では今Adobeに一番注目してます。
セキュリティの話とかちんぷんかんぷんでしたが、
P2PSIPはあれだなぁ、ってみんな思ってるってことはわかりましたｗ
標準は泥臭いところから生まれる方が現実的なモノができやすいのでしょう。
ということで、セッション層はXMPP使うことにする。
まだ悩むのはlibjingleをがんばって使うか、C#で自分で実装しにいくか、、
トランスポート層はUDPかなぁ
TCPのNAT越えは
Characterization and Measurement of TCP Traversal through NATs and Firewalls
がちゃんとしたまとめっぽいけど、実現方法がきもいよなぁ、
今日もTCPがNAT超えられるの5割程度って言ってたしUDPでなんとかしよう
UDPのSTUNの仕組みがまだ理解できてないなぁ
フルコーンNAT → STUNサーバ にパケット送ってNATにマップを作らせることで
外部IP → フルコーンNAT内 方向が到達できる、ってのはわかったし実験できたんですが、
SymmetricじゃないNAT（IP制限のみかポート制限のみ）内から、SymmetricじゃないNAT内にメッセージを送る手順がわからない。
まずSTUN＝UDPホールパンチングだと思ってたけど、今日の話の流れを考えると違うっぽいな
もうちょい調べよう
その上はRTPでSPEEXを包めばいいかなぁ、
FlashPlayer10でSPEEX対応した時に、ローカルアプリからブラウザのFP10にSPEEXストリーム流せたらすごい