第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 Table に包んで流す。

自分の持ってる検索対象のハッシュで検索語のハッシュにマッチするものがあれば、検索元に、結果を返す。
むかしは、QRTが流れてきたルートを逆にたどるように戻って行ったけれど、その仕組みはその後更新されて、
今は、UDPを使って検索結果を持っているnodeから検索元nodeに対して直接送信される。
まじ！そうだったんだ。
とりあえずここでNAT越えしてそうだねー

そのため、検索Queryには、検索元のIPとポート番号が含まれている。
Gnutellaのtrafficの削減、Gnutellaネットワークのスケールにかなり役立ったそう。

検索結果のファイルをダウンロードすることになれば、ファイル転送にnegotiationが起こる。ファイルの持ち主がFirewallの下に無ければ、ファイル受信側から直接つなぐ。
（なんかGnutella関係の文書ではFirewallとNATがいっしょくたにFirewallって言葉にまとめられて説明されている気がするなぁ。）

ファイルの持ち主がFirewall下にあったら、受信側はファイルの持ち主に push request を送信する。Gnutella初期には、push request もGnutellaネットワークを経由してルーティングされたが、Gnutellaネットワークは不安定なので、今では push proxies が導入されている。主に ultra peer の場合が多く、その存在は検索結果に含まれて検索元に返される。

ファイル受信側は、push proxy にHTTP Requestを投げ、push proxy はファイルの持ち主に push request を投げる。push proxyを転送することでファイル転送が行われる。

もっと調べたいキーワード
RUDP: Reliable UDP protocol used for NAT-to-NAT transfers; sometimes called Firewall-to-Firewall
これとは別物のようにNat Traversalが書いてあるから謎だなぁ

RUDPはLimeWireのコードの中にもたくさんgrepしたら出てきたのでちょっと読んでみよう。