maaash.jp

what I create

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

[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]: sendstun
[J]Conn[0:private-1:local:114.emobile:1116->private-1:local:61.stun_global:2580|CRw|udp]: sendstun
[J]Conn[0:private-1:stun:114.emobile:1118->private-1:local:192.168.88.1:2582|C-w|udp]: sendstun
[J]Conn[0:private-1:local:114.emobile:1116->private-1:local:61.stun_global:2580|CRw|udp]: got valid STUN response
[J]Conn[0:private-1:local:114.emobile:1116->private-1:local:61.stun_global:2580|CRW|udp]: [w]CRW[/code]
IPの下３桁はemobileとかstun_globalとかに置換してあります。
hamachiもいたりして、失敗してる。

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

[cpp] const char CONNECT_STATE_ABBREV[2] = {
‘-’, // not connected (false)
‘C’, // connected (true)
};
const char READ_STATE_ABBREV[2] = {
‘R’, // STATE_READABLE
‘-’, // STATE_READ_TIMEOUT
};
const char WRITE_STATE_ABBREV[3] = {
‘W’, // STATE_WRITABLE
‘w’, // STATE_WRITE_CONNECT
‘-’, // STATE_WRITE_TIMEOUT
};[/cpp]

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

Comments