Peerjs: بعد التوصيل

تم إنشاؤها على ٢٥ يونيو ٢٠١٩ · 7تعليقات · مصدر: peers/peerjs

بادئ ذي بدء: معرفتي بتوقيت الأحداث في جافا سكريبت ضعيفة ، لذا يرجى قبول اعتذاري إذا كان ما أطرحه يبدو واضحًا (وآسف إذا كنت أقصفك بالأسئلة).

عندما يتعامل النظير A مع اتصال نظير آخر B عبر DataConnection.on('connection', function() {...}) هل هذا الاتصال جاهز داخل المعالج أم أنه يصبح متاحًا تمامًا بعد عودة معالج الأحداث؟ أعني: هل يجوز لـ A إرسال رسالة بيانات إلى B كما في هذا الرمز؟

peerA.on('connection', function(c) {
    // do something
    c.send("Welcome! (will this message ever got delivered?)");
    // do something else
});

في حالة عدم إمكانية ذلك ، ألن يكون من الجيد أن يكون هناك حدث "اتصال لاحق" للتعامل مع هذه الحالات؟ أو ربما من المتوقع أن يعمل الكود التالي؟

peerA.on('connection', function(c) {
    // do something
    setTimeout(function() {
        c.send("Welcome! (will this message ever got delivered?)");
    }, 0);
});

شكرا لك.

مصدر

bilo1967

التعليق الأكثر فائدة

هل سيكون من الممكن التمييز بين المتصلين باستخدام ميزة البيانات الوصفية كما في v1؟

نعم! لقد أضفت للتو هذه الميزة إلى الخطة ، يجب أن تكون سهلة التنفيذ للغاية

هل سأتمكن من الوصول إلى التدفقات البعيدة والمحلية لإجراء بعض معالجة الصوت (المحلية) عبر AudioContext؟ في مشروعي ، لدي نظير "أ" يحتاج إلى سماع كمثرى B في القناة L و C في القناة R الخاصة بسماعة الرأس الخاصة به ، وأن يغير مستوى صوت كل منهما بشكل مستقل ؛ ويحتاج كل من B و C إلى مقياس vu متصلاً بالميكروفون الخاص بهما لمراقبة ما إذا كان يعمل بشكل صحيح باستمرار (لقد قمت بالفعل بتنفيذ هذه الميزات جزئيًا وأحتاج إلى الاحتفاظ بها).

لديك بالفعل حق الوصول إلى التدفقات على المعالجات. لم يتم توثيقه جيدًا ، ولكن كما قلت ، تتلقى دفقًا بعيدًا واحدًا لكل نظير ، والدفق البعيد الخاص بك مرة واحدة ، والذي يُعاد استخدامه لجميع الاتصالات في الوقت الحالي ، والتي يمكن تغييرها في المستقبل إذا لزم الأمر.

هل تقصد معالجة التدفقات قبل إرسالها؟ إذا كان الأمر كذلك ، فيمكن تنفيذه أيضًا.

لم أختبر قناة البيانات ولكني أعتقد أنها نفس قناة الوسائط: اتصال 1-1 بين كل نظير مع onDataStream الذي تم إطلاقه عند كل اتصال؟ و سيتم إرسال الرسائل بشكل فردي لكل نظير؟

نعم ، تتلقى قنوات البيانات الأولية ، واحدة لكل نظير متصل. ستعمل بشكل جيد أيضًا مع ميزة البيانات الوصفية المذكورة أعلاه.

من الجيد أن نسمع أنه لن تكون هناك حاجة إلى خادم نظير. ومع ذلك ، ما هو هذا wss: //broker.peerjs.com ؟

يحتاج PeerJS إلى قناة للقيام بالإشارة الأولية. ولكن الآن بدلاً من استخدام PeerServer ، يتم إنشاء كل المنطق بواسطة مكتبة PeerJS نفسها ، وهي تحتاج فقط إلى وسيط MQTT. لذلك ما زلت بحاجة إلى خادم ، لكن MQTT هو بروتوكول قياسي ، لذلك تحتاج فقط إلى إعداد وسيط ، كما أنه لا يحتاج إلى قاعدة بيانات أو يتم حفظ أي شيء في ذاكرة الخادم (كما هو الحال في الإصدار 1) لذا فهو قابل للتطوير تمامًا.

kidandcat في ٢٦ يونيو ٢٠١٩

🎉3

ال 7 كومينتر

إنه جاهز للاستخدام في المعالج. لا أجد حدث "اتصال البدء" مفيدًا جدًا. في هذه الحالة هل تجدها مفيدة؟

kidandcat في ٢٥ يونيو ٢٠١٩

في المشروع الذي أقوم بتطويره ، هناك مشكلة واحدة وهي تجنب الاتصالات غير المرغوب فيها.

هناك ثلاثة أدوار: الطالب ، المتحدث ، المعلم (لقد أضفت علامة بيانات وصفية تشير إلى الدور في مصفوفة الخيارات عند تسجيل النظير). يتصل المدرس بالسيرفر بمعرفه المعروف وينتظر المتحدث والطالب. بمجرد اتصالهم جميعًا ، يجب تجنب المزيد من الاتصالات.
الرفض الذي قمت بتطبيقه في الإصدار 2.0.0 يجب أن يؤدي المهمة ولكن يبدو لي أن التغييرات في API جذرية تمامًا.

bilo1967 في ٢٦ يونيو ٢٠١٩

نعم ، النسخة الجديدة هي نسخة عمدة (معطلة ، لا توافق مع الإصدارات السابقة). واجهة برمجة التطبيقات القديمة مربكة للغاية ، والكود يحتوي على الكثير من الحيل القديمة منذ أيامه الأولى في عام 2013 ، ومن الصعب جدًا الحفاظ عليه.

ولكن نظرًا لأنه تغيير جذري ، سأستمر في دعم الإصدار القديم ، لذلك سأنفذ طريقة ما للرفض في الإصدار 1. على أي حال ، أوصيك بالانتقال إلى الإصدار 2 إذا لم تكن بحاجة إلى دعم المتصفحات القديمة جدًا. سوف تكسب الاستقرار ولن تحتاج إلى استضافة PeerServer.

لم يتم الرفض في الإصدار 2 بعد ، لكنني أركز على تطوير الإصدار 2 ، لذلك ستكون هذه الميزة جاهزة قريبًا.

kidandcat في ٢٦ يونيو ٢٠١٩

لقد ألقيت نظرة على المثال الذي قدمته لـ v2 ويبدو حقًا مثيرًا للإعجاب: محادثة بسيطة فردية في بضعة أسطر من التعليمات البرمجية! أيضًا ، لقد قمت بتعديل هذا الرمز قليلاً ورأيت أنه يتم تشغيل onRemoteStream على كل نظير في أي وقت ينضم فيه شخص ما إلى الغرفة ، مما يجعل من الممكن التعامل مع جميع اتصالات الوسائط التي قد يدعمها النطاق الترددي الخاص بك: رائع !!!

فقط بضعة أسئلة:

هل سيكون من الممكن التمييز بين المتصلين باستخدام ميزة البيانات الوصفية كما في v1؟
هل سأتمكن من الوصول إلى التدفقات البعيدة والمحلية لإجراء بعض معالجة الصوت (المحلية) عبر AudioContext؟ في مشروعي ، لدي نظير "أ" يحتاج إلى سماع كمثرى B في القناة L و C في القناة R الخاصة بسماعة الرأس الخاصة به ، وأن يغير مستوى صوت كل منهما بشكل مستقل ؛ ويحتاج كل من B و C إلى مقياس vu متصلاً بالميكروفون الخاص بهما لمراقبة ما إذا كان يعمل بشكل صحيح باستمرار (لقد قمت بالفعل بتنفيذ هذه الميزات جزئيًا وأحتاج إلى الاحتفاظ بها).
لم أختبر قناة البيانات ولكني أعتقد أنها نفس قناة الوسائط: اتصال 1-1 بين كل نظير مع onDataStream الذي تم إطلاقه عند كل اتصال؟ و سيتم إرسال الرسائل بشكل فردي لكل نظير؟
من الجيد أن نسمع أنه لن تكون هناك حاجة إلى خادم نظير. ومع ذلك ، ما هو هذا wss: //broker.peerjs.com ؟

ملاحظة: لقد لاحظت أنك قمت بتحديث تخطيط خارطة الطريق لإضافة أقصى عدد من الأقران لكل غرفة وهذا شيء أحتاجه حقًا!

bilo1967 في ٢٦ يونيو ٢٠١٩

هل سيكون من الممكن التمييز بين المتصلين باستخدام ميزة البيانات الوصفية كما في v1؟

نعم! لقد أضفت للتو هذه الميزة إلى الخطة ، يجب أن تكون سهلة التنفيذ للغاية

هل سأتمكن من الوصول إلى التدفقات البعيدة والمحلية لإجراء بعض معالجة الصوت (المحلية) عبر AudioContext؟ في مشروعي ، لدي نظير "أ" يحتاج إلى سماع كمثرى B في القناة L و C في القناة R الخاصة بسماعة الرأس الخاصة به ، وأن يغير مستوى صوت كل منهما بشكل مستقل ؛ ويحتاج كل من B و C إلى مقياس vu متصلاً بالميكروفون الخاص بهما لمراقبة ما إذا كان يعمل بشكل صحيح باستمرار (لقد قمت بالفعل بتنفيذ هذه الميزات جزئيًا وأحتاج إلى الاحتفاظ بها).

هل تقصد معالجة التدفقات قبل إرسالها؟ إذا كان الأمر كذلك ، فيمكن تنفيذه أيضًا.

لم أختبر قناة البيانات ولكني أعتقد أنها نفس قناة الوسائط: اتصال 1-1 بين كل نظير مع onDataStream الذي تم إطلاقه عند كل اتصال؟ و سيتم إرسال الرسائل بشكل فردي لكل نظير؟