libjingleのNAT越えの様子

Posted on 10月 5, 2008
Filed Under ice, libjingle, stun, 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:
  1. [J]Conn[0:private-1:local:114.emobile:1116->private-1:local:192.168.174.1:2584|C-w|udp]: sendstun
  2. [J]Conn[0:private-1:local:114.emobile:1116->private-1:local:5.rem_hamachi:2586|C-w|udp]: sendstun
  3. [J]Conn[0:private-1:local:5.loc_hamachi:1119->private-1:local:192.168.0.2:2580|C-w|udp]: sendstun
  4. Error(port.cc:310): [J]Port[private-1:stun:Net[0:114.emobile]]: Received STUN response with bad username2
  5. [J]Conn[0:private-1:local:5.loc_hamachi:1119->private-1:local:192.168.88.1:2582|C-w|udp]: sendstun
  6. [J]Conn[0:private-1:local:5.loc_hamachi:1119->private-1:local:192.168.174.1:2584|C-w|udp]: sendstun
  7. [J]Conn[0:private-1:local:5.loc_hamachi:1119->private-1:local:5.rem_loc_hamachi:2586|C-w|udp]: sendstun
  8. [J]Conn[0:private-1:local:114.emobile:1116->private-1:stun:61.stun_global:2581|C-w|udp]: sendstun
  9. [J]Conn[0:private-1:local:5.loc_hamachi:1119->private-1:stun:61.stun_global:2581|C-w|udp]: sendstun
  10. [J]Conn[0:private-1:stun:114.emobile:1118->private-1:local:192.168.0.2:2580|C-w|udp]: sendstun
  11. [J]Conn[0:private-1:stun:114.emobile:1118->private-1:local:61.stun_global:2580|CRw|udp]: [r]CRw
  12. [J]Conn[0:private-1:local:5.loc_hamachi:1119->private-1:local:61.stun_global:2580|CRw|udp]: [r]CRw
  13. [J]Conn[0:private-1:local:114.emobile:1116->private-1:local:61.stun_global:2580|CRw|udp]: [r]CRw
  14. [J]Port[private-1:local:Net[0:114.emobile]]: got request, send response
  15. [J]Conn[0:private-1:local:5.loc_hamachi:1119->private-1:local:61.stun_global:2580|CRw|udp]: sendstun
  16. [J]Conn[0:private-1:local:114.emobile:1116->private-1:local:61.stun_global:2580|CRw|udp]: sendstun
  17. [J]Conn[0:private-1:stun:114.emobile:1118->private-1:local:192.168.88.1:2582|C-w|udp]: sendstun
  18. [J]Conn[0:private-1:local:114.emobile:1116->private-1:local:61.stun_global:2580|CRw|udp]: got valid STUN response
  19. [J]Conn[0:private-1:local:114.emobile:1116->private-1:local:61.stun_global:2580|CRW|udp]: [w]CRW

IPの下３桁はemobileとかstun_globalとかに置換してあります。
hamachiもいたりして、失敗してる。

一行の最後の CRW とか C-w とかが、コネクションのステータス
初期化時に、C-ｗなのかな、そっから始まって、だめだったやつは時間おいてリトライとかやってるようだ。

PLAIN TEXT
C++:
  1. const char CONNECT_STATE_ABBREV[2] = {
  2.         '-', // not connected (false)
  3.         'C', // connected (true)
  4.     };
  5.     const char READ_STATE_ABBREV[2] = {
  6.         'R', // STATE_READABLE
  7.         '-', // STATE_READ_TIMEOUT
  8.     };
  9.     const char WRITE_STATE_ABBREV[3] = {
  10.         'W', // STATE_WRITABLE
  11.         'w', // STATE_WRITE_CONNECT
  12.         '-', // STATE_WRITE_TIMEOUT
  13.     };

CRW（読み書き成功）になると、そのコネクションを使って、ファイル交換の場合は PseudoTCP とかってクラスとかでUDPに信頼性と順序を加えるためにラップして、httpリクエストをファイル受信側から行う(?)。
信頼性は当面必要ないのでここはスルー。

Comments

Leave a Reply