第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 […]

tabmixplusをFF3.0.1,2,3に

やっぱこれ必須だわ
まだ正式対応してなくていろいろ
http://de-lab.com/article/firefox30-addon/
とか見たけどリンク先はFF3まででFF3.0.1はNGだったので
http://tmp.garyr.net/dev-builds/tab_mix_plus-0.3.7pre.080920.xpi
これならいける！

クロスプラットフォームのローカルアプリ開発はC#（mono）か

「mac対応しないとか今時ねーよ」みたいなことをtypesterが言うので、調べた。
C#がいいかなぁ
What is Mono?
Mono provides the necessary software to develop and run .NET client and server applications on Linux, Solaris, Mac OS X, Windows, and Unix
今年の3月にでたMono 1.9で
# System.Media implemented.
というのもGJ
試す
debian lennyならaptパッケージがある
System.Windows.Forms使うなら
libmono-winforms2.0-cil もお忘れなく。
まずはc#でhelloworld
PLAIN TEXT
C#:

santrini% cat helloworld.cs

using System;

using System.Windows.Forms;

 

public class HelloWorld : Form

{

        static public void Main ()

        {

        [...]

XMPPでP2Pの音声チャットセッションを確立する方法4

XMPPでP2Pの音声チャットセッションを確立する方法3
の続き
libjingleでcallサンプル（P2Pの音声電話）を動かしてみて、
ログみてどういうxmpp stanza送りあってるのかなぁ、見てみる。
call.exe に -d オプションをつけて動かすとデバッグ情報がログに出てくる
libjingleではGIPSMediaEngineとlinphoneというのにデフォルト対応していますが
GIPSMediaEngine手に入らないし
linphoneはWindows上でうまくbuildできないので
とりあえず適当なpayload-typeを指定しています。
IPアドレスも適当にしています
XMPPのJIDはこんな感じ
caller：　o.masakazu@gmail.com/callB3B38FB3
callee：　o.masakazu@gmail.com/call7DA716D7
ところで悲しいことに、、
libjingle Developer Guide
libjingle was created at about the same time as the Jingle XMPP extension (XEP-0166). The libjingle team created their own protocol to handle session negotiation, and later worked with the XMPP Standards Foundation to standardize Jingle; thus, although the libjingle protocol and Jingle are very similar, they are not [...]

XMPPでP2Pの音声チャットセッションを確立する方法3

XMPPでP2Pの音声チャットセッションを確立する方法2
これの続き。
XEP-0176: Jingle ICE-UDP Transport Method
を読む。
This specification defines a Jingle transport method that results in sending media data using raw datagram sockets via the User Datagram Protocol (UDP). This transport method is negotiated via the Interactive Connectivity Establishment (ICE) methodology defined by the IETF and thus provides robust NAT traversal for media traffic.
これと並列なものとして、
XEP-0177: Jingle Raw UDP [...]

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の音声チャットセッションを確立する方法2

これの続き
XMPPでP2Pの音声チャットセッションを確立する方法1
jingleで使用するXMPP stanza(?)の中に、ってのがある
# stanzaってこういう使い方でいいのかな？
PLAIN TEXT
CODE:

<content creator="initiator" name="voice">

<description xmlns="urn:xmpp:tmp:jingle:apps:rtp" media="audio"></description></content>

 

<payload id="97" name="speex" clockrate="8000"></payload>

<payload id="18" name="G729"></payload>

<transport xmlns="urn:xmpp:tmp:jingle:transports:ice-udp"><candidate component="1">

foundation='1'

generation='0'

ip='192.0.2.3'

network='1'

port='45664'

priority='1678246398'

protocol='udp'

pwd='asd88fgpdd777uzjYhagZg'

type='srflx'

ufrag='8hhy'/&gt;

</candidate>     </transport>

の中身は
XEP-0166: Jingle
では扱ってない。
XEP-0166の中で、
Naturally, more complex scenarios are probable; such scenarios are described in other specifications, such as XEP-0167 for voice chat.
ってのがあるのでポインタの先に飛んでみる
XEP-0167: Jingle RTP Sessions
This specification defines a Jingle application type for negotiating one or more sessions that use [...]

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ストリーム流せたらすごい