WebRTCでのサービス方法

WebRTCについては、インターネットとHabré（ こことここ ）の両方にすでに非常に多くの記事がありますが、それらを繰り返すことはあまり意味がないので、ここでlive.pics.ioの開発中に得た個人的な経験と印象を与えます。

アイデア

Live.pics.ioを使用すると、音声で画像を共有して話し合うためのプライベートセッションを作成できます。 写真からデザインレイアウトやプレゼンテーションまで、あらゆる画像を使用できます。 pics.ioの開発中に、ブラウザーでさまざまな生のフォーマットを操作する方法を非常によく学んだので、変換の手間をかけずに、撮影後すぐに写真をアップロードできます（キヤノンとニコンの所有者は喜んで、残りのカメラはまだDNGに変換する必要があります）。

webRTCについて非常に短い

実際、WebRTCの使用は、ソケットの使用とほとんど同じです。 しかし、少し異なります（少し）。 画像と音声を送信する必要があります。 ピア間の接続にはRTCPeerConnection、オーディオのブロードキャストにはMediaStream、画像の送信にはRTCDataChannelを使用します。 それでも、これらすべてが機能するためには、ピアを接続して制御命令を送信するための小さなサーバーサイドが必要になります。 しかし、それについては後で。

外骨格とバックボーン

たまたま、 Backboneでメインプロジェクト（pics.io）が開発されています。 私たちは長い間、 ExでたExoskeletonを試してみたいと思っていました。 今回のケースでは、Exoskeletonはそれほど必要ではありませんが、新しいものをいじって本番環境にリリースしたかっただけです。 私にとっては、失敗しませんでした。 また、彼の発案を非常に積極的にサポートしている著者@PaulMillerに敬意を表する必要があります。 一般に、Exoskeletonが保存するjQueryは嫌いではありませんが、最新のブラウザーでは純粋なJSで記述できると確信しました。 ExoskeletonがLodashの道をたどり 、パン職人の心をつかむことを心から願っています。

PeerJSを介したWebRTC

既成のテスト済みソリューションを使用するためにWebRTCパーツを展開する方が、より正確で高速になると判断しました。 WebRTCサービスをラップするいくつかのオープンソースプロジェクトを研究した後、選択はPeerJSに落ちました：一部はGitHubの星の数が多く、一部はDart / WebRTCでスピーカーライブラリを作成する際に@Lvivskyが食べたアドバイスによるものです。



PeerJSはWebRTCのラッパーであり、そのガットから抽象化することができます。 最終的に、RTCDataChannelを介して送信されるファイルを最大6Mbに制限することにつまずいたとき、ソースコードを掘り下げる必要がありました。 一般的に、図書館は楽しい印象しか残さず、プロジェクトのメンテナーはすぐに助けてくれました。

PeerJSの第一印象は素晴らしかった。サーバー側に1行、クライアントの優れたインターフェース、メディアコール（オーディオ/ビデオ）およびDataConnectionsのサポート。 そして何よりも、PeerJSは、Chrome 31のDataConnectionsを介して送信されるデータ量の制限を克服するのに役立ちます。これは、1100バイトを超える転送をまだ学習していません。 しかし、すべてが猫の謝肉祭ではないので、RTCDataChannelは完全に情報のないVorc Uncaught SyntaxError: An invalid or illegal string was specified



SyntaxErrorでクラッシュしUncaught SyntaxError: An invalid or illegal string was specified



。 数リットルのコーヒーを飲み、PeerJSの貢献者と話をした後、Chromeはデータ転送速度を60kb / sに制限していることが判明しました。 さらに、転送されたファイルの最大サイズは約6.3Mであることが判明しました。 自治体では、これは生ファイルから抽出されたjpegを送信するのに十分です。

NAT、NAT、NAT

リリースの前夜、私たちはそれを台無しにするしかありませんでした。 ローカルネットワーク上の接続は完全に機能しましたが（MediaStreamとDataChannelの両方）、オフィスの外から誰かが接続すると、私たちの熱意が消え、原因不明の問題が不安定になり始めました。 その音、その後、データはゲストに届きませんでした。

これに影響を与える可能性のあるいくつかのポイントを強調しました。

• DataChannel-すべてのピア間のコネクタ
• 再現が難しい些細なバグ
• NAT閉塞

DataChannelの代わりに、既存のピアを接続するシグナリングサーバーをWebSocketに追加しましたが、これは問題を解決しませんでした。

バグの検索も失敗しました。 それらの多くが見つかりましたが、これも助けにはなりませんでした。



「それでも、NAT」-私たちは決定し、結局のところ正しいです。 奇妙なことですが、この問題の解決策はドキュメントに詳しく説明されていません。 最初、ほとんどのライブラリはデフォルトのサーバーを使用します。

 [{url:'stun:stun.l.google.com:19302'}, {url:'turn:homeo@turn.bistri.com:80', credential: 'homeo'}]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、残念なことに、私たちはこれを十分に持たず、追加のサーバーを探してサーフしなければなりませんでした。 その結果、ICEServerの巨大な設定ができました

 [{url:'stun:stun01.sipphone.com'}, {url:'stun:stun.ekiga.net'}, {url:'stun:stun.fwdnet.net'}, {url:'stun:stun.ideasip.com'}, {url:'stun:stun.iptel.org'}, {url:'stun:stun.rixtelecom.se'}, {url:'stun:stun.schlund.de'}, {url:'stun:stun.l.google.com:19302'}, {url:'stun:stun1.l.google.com:19302'}, {url:'stun:stun2.l.google.com:19302'}, {url:'stun:stun3.l.google.com:19302'}, {url:'stun:stun4.l.google.com:19302'}, {url:'stun:stunserver.org'}, {url:'stun:stun.softjoys.com'}, {url:'stun:stun.voiparound.com'}, {url:'stun:stun.voipbuster.com'}, {url:'stun:stun.voipstunt.com'}, {url:'stun:stun.voxgratia.org'}, {url:'stun:stun.xten.com'}, { url: 'turn:numb.viagenie.ca', credential: 'muazkh', username: 'webrtc@live.com' }, { url: 'turn:192.158.29.39:3478?transport=udp', credential: 'JZEOEt2V3Qb0y27GRntt2u2PAYA=', username: '28224511:1379330808' }, { url: 'turn:192.158.29.39:3478?transport=tcp', credential: 'JZEOEt2V3Qb0y27GRntt2u2PAYA=', username: '28224511:1379330808' }]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、安全にNATの壁を突破し、他のサブネット、都市、国からの人々の声を聞きました。

技術と実装の問題

ブラウザー間の互換性。

現時点では、WebRTCの実装には異なるブラウザ間の動作に問題がありますが、FirefoxとChromeはこの方向に積極的に移行しています。 いくつかのバージョンでは、ウェブはすでにこのサポートを受けています。

パンチングNAT。

STUNとTURNはおそらく主な問題であり、何らかの理由でほとんど書かれていません。 絶えずテストしている間、同じネットワーク内で誰もが完全にデータを聞いて受信しましたが、ルーターに座っていた人々は絶えず問題を経験していることに気付きました。 ネットワークプロトコルと密接に連携せず、なぜこれが必要なのかを完全に理解していなかったため、私たちはこれに多大な神経を使いました。 これで、プライベートネットワーク、クラスA、B、Cから、クラスパブリック出口のネットワークの人々はNATを介してのみ知っています。 このテクノロジーは、NATの背後にある2つのホストが互いに通信できないという点で便利ではありません。 したがって、彼らはこれらの技術を思いついた。

ノンストップコーディング。

非常にクールな娯楽、多くの新しい感情とスキル、そして完成品が生産されているという満足感。 しかし、あなたは翌日に搾り出される危険を冒します。

結論

• PeerJSのデータ転送速度は60kb / sに制限されています
• 最大送信ファイルサイズ〜6MB
• NAT + STUN + TURNでポイントを強調する必要があります
• jQuery開発者の仕事はあまり人気がない
• URIのスキームを指定することを忘れないでください
• 遅かれ早かれWebRTCが世界を引き継ぐ
• WebRTC開発者は声が嫌い
• 私たちは新しいもの、生のもの、壊れたものすべてが大好き
• 週に一度の連続的なペダリングはひどく疲れる

お気に入りのリンク

www.html5rocks.com/en/tutorials/webrtc/basics

www.youtube.com/watch?v=p2HzZkd2A40

www.youtube.com/watch?v=E8C8ouiXHHk

www.webrtc-experiment.com

www.webrtc.org

speakerdeck.com/feross/webrtc-data-black-magic