まず第一に、javascriptでのイベントのタイミングに関する知識が乏しいので、私が質問していることが明白であると思われる場合は、謝罪を受け入れてください（質問であなたを攻撃している場合は申し訳ありません）。
ピアAがDataConnection.on('connection', function() {...})を介して別のピアBの接続を処理する場合、その接続はハンドラー内で準備ができていますか、それともイベントハンドラーが戻った後に完全に使用可能になりますか？ つまり、このコードのように、AがBにデータメッセージを送信できますか？
peerA.on('connection', function(c) {
// do something
c.send("Welcome! (will this message ever got delivered?)");
// do something else
});
これが不可能な場合は、これらのケースを処理するために「afterconnection」イベントを設定するのは良いことではないでしょうか。 または、次のコードが機能すると予想されますか？
peerA.on('connection', function(c) {
// do something
setTimeout(function() {
c.send("Welcome! (will this message ever got delivered?)");
}, 0);
});
ありがとう。
bilo1967
全てのコメント7件
ハンドラーで使用する準備ができています。 「接続開始」イベントはあまり役に立ちません。 どちらの場合に役立ちますか？
kidandcat
2019年06月25日
私が開発しているプロジェクトでは、不要な接続を回避することが1つの問題です。
学生、講演者、教師の3つの役割があります（ピアを登録するときにオプション配列に役割を示すメタデータフラグを追加しました）。 教師は既知のIDを使用してサーバーに接続し、スピーカーと生徒を待ちます。 それらがすべて接続されたら、それ以上の接続は避ける必要があります。
v2.0.0で実装した拒否でうまくいくはずですが、APIの変更は非常に根本的なもののようです。
bilo1967
2019年06月26日
はい、新しいバージョンは市長のものです（最新バージョン、下位互換性はありません）。 古いAPIは非常に紛らわしく、コードには2013年の最初の日から多くのレガシートリックがあり、保守が非常に困難です。
ただし、これは重大な変更であるため、引き続き古いバージョンをサポートするため、v1で何らかの拒否方法を実装します。 とにかく、非常に古いブラウザをサポートする必要がない場合は、v2に移行することをお勧めします。 安定性が増し、PeerServerをホストする必要がなくなります。
v2での拒否はまだ行われていませんが、私はv2の開発に焦点を合わせているので、その機能はまもなく準備が整います。
kidandcat
2019年06月26日
あなたがv2に提供した例を見てみましたが、それは本当に印象的です。数行のコードでの単純な1対1のチャットです。 また、そのコードを少し調整しました。誰かが部屋に参加するたびにonRemoteStreamが各ピアで起動され、帯域幅がサポートする可能性のあるすべてのメディア接続を処理できるようになりました。
ほんの少しの質問：
- v1のようなメタデータ機能を使用して誰が接続しているかを区別することは可能ですか？
- リモートストリームとローカルストリームにアクセスして、AudioContextを介して（ローカル）オーディオ処理を実行できますか？ 私のプロジェクトでは、ヘッドセットのLチャンネルで洋ナシBを、RチャンネルでCを聞き、それぞれの音量を個別に変更する必要があるピアAを探しました。 また、BとCの両方で、マイクが正常に機能しているかどうかを継続的に監視するために、マイクに接続されたVUメーターが必要です（この機能はすでに部分的に実装されており、維持する必要があります）。
- 私はデータチャネルをテストしていませんが、メディアチャネルと同じだと思います。各接続でonDataStreamが起動された各ピア間の1-1接続ですか？ そして、メッセージは各ピアに個別に送信されますか？
- ピアサーバーは必要ないと聞いてうれしいです。 しかし、そのwss：//broker.peerjs.comは何のためのものですか？
PSロードマップの計画を更新して、部屋ごとに最大数のピアを追加したことを確認しました。これは私が本当に必要としていることです。
bilo1967
2019年06月26日
- v1のようなメタデータ機能を使用して誰が接続しているかを区別することは可能ですか？
はい！ その機能を計画に追加したばかりです。実装は非常に簡単なはずです。
- リモートストリームとローカルストリームにアクセスして、AudioContextを介して（ローカル）オーディオ処理を実行できますか？ 私のプロジェクトでは、ヘッドセットのLチャンネルで洋ナシBを、RチャンネルでCを聞き、それぞれの音量を個別に変更する必要があるピアAを探しました。 また、BとCの両方で、マイクが正常に機能しているかどうかを継続的に監視するために、マイクに接続されたVUメーターが必要です（この機能はすでに部分的に実装されており、維持する必要があります）。
ハンドラーのストリームにはすでにアクセスできます。 十分に文書化されていませんが、ピアごとに1つのリモートストリームを受信し、独自のリモートストリームを1回受信します。これは現在すべての接続で再利用され、必要に応じて将来変更される可能性があります。
ストリームを送信する前に処理するという意味ですか？ もしそうなら、それも実装することができます。
- 私はデータチャネルをテストしていませんが、メディアチャネルと同じだと思います。各接続でonDataStreamが起動された各ピア間の1-1接続ですか？ そして、メッセージは各ピアに個別に送信されますか？
はい、接続されているピアごとに1つずつ、生のdataChannelを受け取ります。 上記のメタデータ機能でもうまく機能します。
- ピアサーバーは必要ないと聞いてうれしいです。 しかし、そのwss：//broker.peerjs.comは何のためのものですか？
PeerJSには、初期シグナリングを行うためのチャネルが必要です。 しかし、PeerServerを使用する代わりに、すべてのロジックはPeerJSライブラリ自体によって作成され、MQTTブローカーのみが必要になります。 したがって、サーバーは引き続き必要ですが、MQTTは標準プロトコルであるため、ブローカーをセットアップするだけで済みます。また、データベースを必要とせず、サーバーメモリに何も保存されないため（v1のように）、完全にスケーラブルです。
kidandcat
2019年06月26日
素晴らしいニュース！ 私は間違いなくv1からv2に切り替えると思います。 それはすべてをはるかに簡単にします。 どうもありがとうございました！
bilo1967
2019年06月26日
素晴らしいライブラリをありがとう
shivarajnaidu
2019年06月26日
関連する問題
veezo2007pk
·
7コメント
geraldsamosir
·
6コメント
furozen
·
9コメント
jameshfisher
·
5コメント
Kitanga
·
5コメント
最も参考になるコメント
はい！ その機能を計画に追加したばかりです。実装は非常に簡単なはずです。
ハンドラーのストリームにはすでにアクセスできます。 十分に文書化されていませんが、ピアごとに1つのリモートストリームを受信し、独自のリモートストリームを1回受信します。これは現在すべての接続で再利用され、必要に応じて将来変更される可能性があります。
ストリームを送信する前に処理するという意味ですか？ もしそうなら、それも実装することができます。
はい、接続されているピアごとに1つずつ、生のdataChannelを受け取ります。 上記のメタデータ機能でもうまく機能します。
PeerJSには、初期シグナリングを行うためのチャネルが必要です。 しかし、PeerServerを使用する代わりに、すべてのロジックはPeerJSライブラリ自体によって作成され、MQTTブローカーのみが必要になります。 したがって、サーバーは引き続き必要ですが、MQTTは標準プロトコルであるため、ブローカーをセットアップするだけで済みます。また、データベースを必要とせず、サーバーメモリに何も保存されないため（v1のように）、完全にスケーラブルです。