WebRTCを詳しく調べて、UDPじゃなくTCPで動かないかなと逡巡してみる。 [プログラミング]
なんかUDPでしか使えないみたいなので、WebRTCを深く調べて部分的にでも使ってやろう作戦。というか、何となくありもので作れそうな気がしてきたから、一応行けるところまでここに書く。
UDPなDataChannel APIでデータを壊さないようにするには、
http://blog.wnotes.net/blog/article/beginning-webrtc-datachannel
のようにかなり工夫が必要みたい。WebRTCの枠組みではそうするしかないだろう。
いきなりpeer-to-peerじゃなくて、初めのIPとかを教え合うサーバについて見ておきたい。
・STUNサーバ
http://www.3cx.jp/voip-sip/stun-server/
元々VoIPのサーバだったらしい。WebRTCはそれの流用みたいなもんかな。VoIPの方が幾分古いし。RFC3489のようだが英語なのでしんどいので読まない。
https://www.ietf.org/rfc/rfc3489.txt
あ、日本語だ。
http://blog.fff.io/2013/08/rfc3489.html
Simple Traversal of User Datagram Protocol [UDP] through Network Address Translators [NATs]
って長いよ。Simple Traversal of Udp through NatsでSTUN。
結局、グローバルアドレスとポート番号をNAT越えして教え合うわけだ。
でもそれだけじゃ足りない。NATが通じない時もあるそうなので、その時はちょっと処理が重いTURNサーバが必要になるらしい。細かくはわからんがクライアントのNATがSTUNサーバと別なIPのピアクライアントの通信を遮断してしまう事もあるらしい。まぁSTUNでやっている事を理解できないとか考慮してない場合はそういう事にもなりかねないわな。TURNサーバもOSSであるようだ。
http://tjun.org/2013/12/webrtc_p2p/
なんか両立しているものがあるらしいので
https://code.google.com/p/rfc5766-turn-server/
これでいいんじゃないかと思ったり。動いてメンテもされていればそれが一番いいんだが、いまいちそこのところのメジャーになっているソフトが分からない。STUN + TURNでICE(Interactive Connectivity Establishment)というらしい。
どこかの借りることもできるらしいけど、一応自前でサーバを立ててみたい。全部ひとまとめで自分でやってみたいところがある。まぁOSSのサーバ立てるだけで、コーディングは必要最低限しかしないつもり。サーバ立てるにしても、Dynamic DNSなサーバでどこまでできるかどうかは怪しいものだけれど。
読んでいたらSCTPというプロトコルがあって、それで十分ファイル送信の安全性が確保できるのであればそれを使おう。でも所詮はUDPレベルなんだろうな。
http://www.html5rocks.com/ja/tutorials/webrtc/datachannels/
おいおい結構使えそうじゃないですか。使いようによってはそれなりに信頼性のあるデカいファイルも遅れるかもしれない。ともあれあんまりメジャーなプロトコルじゃないので、どういう扱いを受けているのかをもっとよく知っておかないといけないとは思う。自分がやろうとしているファイルの交換に用いるなら、十分使えそうなことはわかった。でもちょっと面倒そう。ソケットと絡めてどう実装しているのかもちょっときになる。まぁ実際使ってみてちょっと勉強しないとダメだな。
次からはICEなインスコに入る予定。試行錯誤するからいろいろ手続きをすっ飛ばす可能性ありです。いろいろあってこれが定番ってのもなさそうだから、動くものを見つければそれで良いことにする。
UDPなDataChannel APIでデータを壊さないようにするには、
http://blog.wnotes.net/blog/article/beginning-webrtc-datachannel
のようにかなり工夫が必要みたい。WebRTCの枠組みではそうするしかないだろう。
いきなりpeer-to-peerじゃなくて、初めのIPとかを教え合うサーバについて見ておきたい。
・STUNサーバ
http://www.3cx.jp/voip-sip/stun-server/
元々VoIPのサーバだったらしい。WebRTCはそれの流用みたいなもんかな。VoIPの方が幾分古いし。RFC3489のようだが英語なのでしんどいので読まない。
https://www.ietf.org/rfc/rfc3489.txt
あ、日本語だ。
http://blog.fff.io/2013/08/rfc3489.html
Simple Traversal of User Datagram Protocol [UDP] through Network Address Translators [NATs]
って長いよ。Simple Traversal of Udp through NatsでSTUN。
結局、グローバルアドレスとポート番号をNAT越えして教え合うわけだ。
でもそれだけじゃ足りない。NATが通じない時もあるそうなので、その時はちょっと処理が重いTURNサーバが必要になるらしい。細かくはわからんがクライアントのNATがSTUNサーバと別なIPのピアクライアントの通信を遮断してしまう事もあるらしい。まぁSTUNでやっている事を理解できないとか考慮してない場合はそういう事にもなりかねないわな。TURNサーバもOSSであるようだ。
http://tjun.org/2013/12/webrtc_p2p/
なんか両立しているものがあるらしいので
https://code.google.com/p/rfc5766-turn-server/
これでいいんじゃないかと思ったり。動いてメンテもされていればそれが一番いいんだが、いまいちそこのところのメジャーになっているソフトが分からない。STUN + TURNでICE(Interactive Connectivity Establishment)というらしい。
どこかの借りることもできるらしいけど、一応自前でサーバを立ててみたい。全部ひとまとめで自分でやってみたいところがある。まぁOSSのサーバ立てるだけで、コーディングは必要最低限しかしないつもり。サーバ立てるにしても、Dynamic DNSなサーバでどこまでできるかどうかは怪しいものだけれど。
読んでいたらSCTPというプロトコルがあって、それで十分ファイル送信の安全性が確保できるのであればそれを使おう。でも所詮はUDPレベルなんだろうな。
http://www.html5rocks.com/ja/tutorials/webrtc/datachannels/
おいおい結構使えそうじゃないですか。使いようによってはそれなりに信頼性のあるデカいファイルも遅れるかもしれない。ともあれあんまりメジャーなプロトコルじゃないので、どういう扱いを受けているのかをもっとよく知っておかないといけないとは思う。自分がやろうとしているファイルの交換に用いるなら、十分使えそうなことはわかった。でもちょっと面倒そう。ソケットと絡めてどう実装しているのかもちょっときになる。まぁ実際使ってみてちょっと勉強しないとダメだな。
次からはICEなインスコに入る予定。試行錯誤するからいろいろ手続きをすっ飛ばす可能性ありです。いろいろあってこれが定番ってのもなさそうだから、動くものを見つければそれで良いことにする。
タグ：WebRTC
WebRTCの途中経過の記事に気持ち悪いTweetがあった。指摘すればいいのにおおっぴらにコソコソやってるのが今のWeb風なんだろうな。まぁ自分から情報を出さない人間になるよりかはいいや。試行錯誤していくのが自分の手法なので。
というか、IT系は根暗な人間も固まりがちなので、陰湿なことも平気でするんだよね。一般の社会でもそうだけど、自分のところで仕事を囲って連携を取れない奴も多い。それと大して変わらん。
by miff (2015-12-25 05:38)