Peerjs: DataChannelが予期せず、理由もなく閉じます

ファイルの読み取りが速すぎて、WebRTCデータチャネルバッファーがいっぱいになりました。これには16メガバイトの制限があります。

http://viblast.com/blog/2015/2/25/webrtc-bufferedamount/

大量のメッセージをまとめて送信すると、一度に送信できない可能性があります。 それらは入力バッファに入れられます。 しかし、バッファは無限に大きくなることはできません。 通常、事前に決定された制限があります。 制限を超えると、Chrome> = 37でデータチャネルが閉じられ、すべてのメッセージが破棄され、例外がスローされます。 ただし、Chrome <= 36では、例外のみがスローされます。 したがって、これはChrome 37で行われたAPIを破る変更です。開発者が古いブラウザを扱っている場合は、この変更に注意する必要があります。

なんてこった... peerJSでもまったく同じ問題が発生し、答えが見つかりませんでした（バッファに関連するものだと思いました）。最後にアイデアをありがとうございます。私の問題を解決します。 興味深いことに、peerJSにはバッファリングの内部メカニズムがあります。これは、私が理解しているように、この問題に対して正しく作成されていますが、実装されているのは、送信できないことによる例外のキャッチに依存しているようです。システムは冗長になりました。 私はそれについてここで問題を作ります、すぐに（もし）私はこれが理由であると確信するでしょう。

編集：うんは合法に見えます、bufferedAmountは約16mbになり、すべてが失敗します。

はい、これは明らかにするのが面倒なバグでした。 何が起こっているのかをようやく理解するのに何日もかかりました。 PeerJSは、データチャネルバッファがオーバーフローしたときに適切に処理するように更新する必要があり、Chromeは接続を切断します。

ちなみに、誰かがこれに遭遇した場合、私は問題を開き、そこにそのhttps://github.com/peers/peerjs/issues/291を修正するためにpeer.jsソースに小さな編集を投稿しました

@ UnsungHero97

大量のメッセージをまとめて送信すると、一度に送信できない可能性があります。 それらは入力バッファに入れられます。 しかし、バッファは無限に大きくなることはできません。 通常、事前に決定された制限があります。 制限を超えると、Chrome> = 37でデータチャネルが閉じられ、すべてのメッセージが破棄され、例外がスローされます。 ただし、Chrome <= 36では、例外のみがスローされます。 したがって、これはChrome 37で行われたAPIを破る変更です。開発者が古いブラウザを扱っている場合は、この変更に注意する必要があります。

小さな修正：将来の参照用に、16MBではなく16KB。 私は同じ問題に直面しました。 Firefoxの制限はほぼ同じ16kiB（https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Using_data_channels#Understanding_message_size_limits）です。