Прежде всего: мои знания о времени событий в javascript плохие, поэтому, пожалуйста, примите мои извинения, если то, что я прошу, кажется очевидным (и извините, если я бомбардирую вас вопросами).
Когда одноранговый узел 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);
});
Спасибо.
Он готов к использованию в обработчике. Я не нахожу очень полезным событие «начать соединение». В каком случае вы считаете это полезным?
В проекте, который я разрабатываю, одна проблема заключается в том, чтобы избежать нежелательных подключений.
Есть три роли: студент, спикер, преподаватель (я добавил флаг метаданных, указывающий роль в массиве опций при регистрации пира). Преподаватель подключается к серверу со своим известным ID и ждет спикера и ученика. После того, как все они подключены, следует избегать дальнейших подключений.
Отказ, который вы реализовали в версии 2.0.0, должен работать, но мне кажется, что изменения в API довольно радикальны.
Да, новая версия майорская (ломка, обратной совместимости нет). Старый API довольно сбивает с толку, а в коде много устаревших трюков с его первых дней в 2013 году, его очень сложно поддерживать.
Но так как это критическое изменение, я продолжу поддерживать старую версию, поэтому я реализую какой-то способ отклонения в v1. В любом случае, я рекомендую вам перейти на v2, если вам не нужна поддержка очень старых браузеров. Вы получите стабильность, и вам не нужно будет размещать PeerServer.
Отказ от версии 2 еще не завершен, но я сосредоточен на разработке версии 2, так что эта функция скоро будет готова.
Я взглянул на пример, который вы предоставили для v2, и он действительно выглядит впечатляюще: простой чат один на один в нескольких строках кода! Кроме того, я немного подправил этот код и увидел, что onRemoteStream запускается на каждом узле каждый раз, когда кто-то присоединяется к комнате, что позволяет обрабатывать все медиа-соединения, которые может поддерживать ваша пропускная способность: вау!!!
Всего несколько вопросов:
PS Я видел, что вы обновили дорожную карту, планируя добавить максимальное количество пиров на комнату, и это то, что мне действительно нужно!
Да! Я только что добавил эту функцию в план, ее должно быть очень легко реализовать.
У вас уже есть доступ к потокам на обработчиках. Это не очень хорошо документировано, но, как вы сказали, вы получаете один удаленный поток на одноранговый узел и свой собственный удаленный поток один раз, который прямо сейчас повторно используется для всех подключений и может быть изменен в будущем при необходимости.
Вы имеете в виду обрабатывать потоки перед их отправкой? если да, то его тоже можно реализовать.
Да, вы получаете необработанные каналы данных, по одному на подключенный одноранговый узел. Он также будет хорошо работать с упомянутой выше функцией метаданных.
PeerJS нужен канал для начальной передачи сигналов. Но теперь вместо использования PeerServer вся логика выполняется самой библиотекой PeerJS, и ей нужен только брокер MQTT. Таким образом, вам все еще нужен сервер, но MQTT — это стандартный протокол, поэтому вам нужно только настроить брокера, также ему не нужна база данных или что-либо сохраняется в памяти сервера (как в v1), поэтому он полностью масштабируется.
Отличные новости! Думаю обязательно перейду с v1 на v2. Это сделает все намного проще. Большое спасибо!
Спасибо за замечательную библиотеку
Самый полезный комментарий
Да! Я только что добавил эту функцию в план, ее должно быть очень легко реализовать.
У вас уже есть доступ к потокам на обработчиках. Это не очень хорошо документировано, но, как вы сказали, вы получаете один удаленный поток на одноранговый узел и свой собственный удаленный поток один раз, который прямо сейчас повторно используется для всех подключений и может быть изменен в будущем при необходимости.
Вы имеете в виду обрабатывать потоки перед их отправкой? если да, то его тоже можно реализовать.
Да, вы получаете необработанные каналы данных, по одному на подключенный одноранговый узел. Он также будет хорошо работать с упомянутой выше функцией метаданных.
PeerJS нужен канал для начальной передачи сигналов. Но теперь вместо использования PeerServer вся логика выполняется самой библиотекой PeerJS, и ей нужен только брокер MQTT. Таким образом, вам все еще нужен сервер, но MQTT — это стандартный протокол, поэтому вам нужно только настроить брокера, также ему не нужна база данных или что-либо сохраняется в памяти сервера (как в v1), поэтому он полностью масштабируется.