Pertama-tama: pengetahuan saya tentang waktu acara dalam javascript buruk, jadi terimalah permintaan maaf saya jika apa yang saya tanyakan tampak jelas (dan maaf jika saya membombardir Anda dengan pertanyaan).
Ketika rekan A menangani koneksi rekan B lain melalui DataConnection.on('connection', function() {...}) apakah koneksi itu siap di dalam handler atau apakah menjadi tersedia sepenuhnya setelah event handler kembali? Maksud saya: bolehkah A mengirim pesan data ke B seperti dalam kode ini?
peerA.on('connection', function(c) {
// do something
c.send("Welcome! (will this message ever got delivered?)");
// do something else
});
Jika ini tidak mungkin, bukankah lebih baik untuk memiliki acara 'afterconnection' untuk menangani kasus-kasus ini? Atau mungkin kode berikut diharapkan berfungsi?
peerA.on('connection', function(c) {
// do something
setTimeout(function() {
c.send("Welcome! (will this message ever got delivered?)");
}, 0);
});
Terima kasih.
bilo1967
Semua 7 komentar
Ini siap digunakan di handler. Saya tidak menemukan acara "mulai menghubungkan" yang sangat berguna. Dalam hal apa Anda merasa berguna?
kidandcat
pada 25 Jun 2019
Dalam proyek yang saya kembangkan satu masalah adalah menghindari koneksi yang tidak diinginkan.
Ada tiga peran: siswa, pembicara, guru (Saya telah menambahkan tanda metadata yang menunjukkan peran dalam larik opsi saat mendaftarkan rekan). Guru terhubung ke server dengan ID-nya, yang diketahui, dan menunggu pembicara dan siswa. Setelah semuanya terhubung, koneksi lebih lanjut harus dihindari.
Penolakan yang Anda terapkan di v2.0.0 seharusnya berhasil, tetapi bagi saya tampaknya perubahan dalam API cukup radikal.
bilo1967
pada 26 Jun 2019
Ya, versi baru adalah versi mayor (melanggar, tidak ada kompatibilitas ke belakang). API lama cukup membingungkan, dan kodenya memiliki banyak trik lama sejak hari pertama di tahun 2013, sangat sulit untuk dipertahankan.
Tetapi karena ini adalah perubahan yang melanggar, saya akan terus mendukung versi lama, jadi saya akan menerapkan beberapa cara penolakan di v1. Pokoknya saya sarankan Anda untuk pindah ke v2 jika Anda tidak perlu mendukung browser yang sangat lama. Anda akan mendapatkan stabilitas dan Anda tidak perlu meng-host PeerServer.
Penolakan di v2 belum selesai, tetapi saya fokus pada pengembangan v2, sehingga fitur itu akan segera siap.
kidandcat
pada 26 Jun 2019
Saya telah melihat contoh yang Anda berikan untuk v2 dan itu benar-benar terlihat mengesankan: obrolan satu-ke-satu yang sederhana dalam beberapa baris kode! Juga, saya telah mengubah sedikit kode itu dan saya telah melihat bahwa onRemoteStream diaktifkan pada setiap rekan setiap kali seseorang bergabung dengan ruangan, sehingga memungkinkan untuk menangani semua koneksi media yang mungkin didukung oleh bandwidth Anda: wow!!!
Hanya beberapa pertanyaan:
- Apakah mungkin untuk membedakan siapa yang terhubung menggunakan fitur metadata seperti di v1?
- Apakah saya dapat mengakses streaming jarak jauh dan lokal untuk melakukan beberapa pemrosesan audio (lokal) melalui AudioContext? Dalam proyek saya, saya memiliki rekan A yang perlu mendengar pir B di saluran-L dan C di saluran-R headset-nya, dan untuk mengubah volume masing-masing secara independen; dan baik B dan C memerlukan vu-meter yang terhubung ke mikrofon mereka untuk terus memantau apakah itu berfungsi dengan benar (saya sudah menerapkan sebagian fitur ini dan perlu menyimpannya).
- Saya belum menguji saluran data tetapi saya kira itu sama dengan saluran media: koneksi 1-1 antara setiap rekan dengan onDataStream diaktifkan pada setiap koneksi? Dan pesan akan dikirim secara individual ke setiap rekan?
- Senang mendengar bahwa peer-server tidak diperlukan. Namun, untuk apa wss://broker.peerjs.com itu ?
PS Saya telah melihat bahwa Anda telah memperbarui perencanaan peta jalan untuk menambahkan jumlah maksimum rekan per kamar dan itu adalah sesuatu yang sangat saya butuhkan!
bilo1967
pada 26 Jun 2019
- Apakah mungkin untuk membedakan siapa yang terhubung menggunakan fitur metadata seperti di v1?
Ya! Saya baru saja menambahkan fitur itu ke dalam rencana, seharusnya sangat mudah diterapkan
- Apakah saya dapat mengakses streaming jarak jauh dan lokal untuk melakukan beberapa pemrosesan audio (lokal) melalui AudioContext? Dalam proyek saya, saya memiliki rekan A yang perlu mendengar pir B di saluran-L dan C di saluran-R headset-nya, dan untuk mengubah volume masing-masing secara independen; dan baik B dan C memerlukan vu-meter yang terhubung ke mikrofon mereka untuk terus memantau apakah itu berfungsi dengan benar (saya sudah menerapkan sebagian fitur ini dan perlu menyimpannya).
Anda sudah memiliki akses ke aliran di penangan. Itu tidak didokumentasikan dengan baik, tetapi seperti yang Anda katakan, Anda menerima satu streaming jarak jauh per peer, dan streaming jarak jauh Anda sendiri satu kali, yang digunakan kembali untuk semua koneksi saat ini, yang dapat diubah di masa mendatang jika diperlukan.
Apakah maksud Anda untuk memproses aliran sebelum mengirimnya? jika demikian, itu dapat diterapkan juga.
- Saya belum menguji saluran data tetapi saya kira itu sama dengan saluran media: koneksi 1-1 antara setiap rekan dengan onDataStream diaktifkan pada setiap koneksi? Dan pesan akan dikirim secara individual ke setiap rekan?
Ya, Anda menerima DataChannels mentah, satu per peer terhubung. Ini akan bekerja dengan baik juga dengan fitur metadata yang disebutkan di atas.
- Senang mendengar bahwa peer-server tidak diperlukan. Namun, untuk apa wss://broker.peerjs.com itu ?
PeerJS membutuhkan saluran untuk melakukan pensinyalan awal. Tapi sekarang alih-alih menggunakan PeerServer, semua logika dibuat oleh perpustakaan PeerJS itu sendiri, dan hanya membutuhkan broker MQTT. Jadi Anda masih membutuhkan server, tetapi MQTT adalah protokol standar, jadi Anda hanya perlu menyiapkan broker, juga tidak memerlukan database atau apa pun disimpan di memori server (seperti di v1) sehingga benar-benar scalable.
kidandcat
pada 26 Jun 2019
Kabar baik! Saya pikir saya pasti akan beralih dari v1 ke v2. Ini akan membuat segalanya jauh lebih mudah. Terima kasih banyak!
bilo1967
pada 26 Jun 2019
Terima kasih untuk perpustakaan yang luar biasa
shivarajnaidu
pada 26 Jun 2019
Masalah terkait
veezo2007pk
·
7Komentar
l2aelba
·
3Komentar
jameshfisher
·
6Komentar
fresheneesz
·
10Komentar
afrokick
·
5Komentar
Komentar yang paling membantu
Ya! Saya baru saja menambahkan fitur itu ke dalam rencana, seharusnya sangat mudah diterapkan
Anda sudah memiliki akses ke aliran di penangan. Itu tidak didokumentasikan dengan baik, tetapi seperti yang Anda katakan, Anda menerima satu streaming jarak jauh per peer, dan streaming jarak jauh Anda sendiri satu kali, yang digunakan kembali untuk semua koneksi saat ini, yang dapat diubah di masa mendatang jika diperlukan.
Apakah maksud Anda untuk memproses aliran sebelum mengirimnya? jika demikian, itu dapat diterapkan juga.
Ya, Anda menerima DataChannels mentah, satu per peer terhubung. Ini akan bekerja dengan baik juga dengan fitur metadata yang disebutkan di atas.
PeerJS membutuhkan saluran untuk melakukan pensinyalan awal. Tapi sekarang alih-alih menggunakan PeerServer, semua logika dibuat oleh perpustakaan PeerJS itu sendiri, dan hanya membutuhkan broker MQTT. Jadi Anda masih membutuhkan server, tetapi MQTT adalah protokol standar, jadi Anda hanya perlu menyiapkan broker, juga tidak memerlukan database atau apa pun disimpan di memori server (seperti di v1) sehingga benar-benar scalable.