Peerjs: послесоединение

Созданный на 25 июн. 2019  ·  7Комментарии  ·  Источник: peers/peerjs

Прежде всего: мои знания о времени событий в 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);
});

Спасибо.

Самый полезный комментарий

  1. Можно ли будет определить, кто подключается, используя функцию метаданных, как в версии 1?

Да! Я только что добавил эту функцию в план, ее должно быть очень легко реализовать.

  1. Смогу ли я получить доступ к удаленным и локальным потокам для выполнения некоторой (локальной) обработки звука через AudioContext? В моем проекте есть партнер А, которому нужно слышать грушу Б в L-канале и C в R-канале своей гарнитуры, и независимо менять громкость каждого из них; и B, и C нуждаются в измерителе звука, подключенном к их микрофону, чтобы постоянно контролировать, правильно ли он работает (я уже частично реализовал эти функции, и мне нужно их сохранить).

У вас уже есть доступ к потокам на обработчиках. Это не очень хорошо документировано, но, как вы сказали, вы получаете один удаленный поток на одноранговый узел и свой собственный удаленный поток один раз, который прямо сейчас повторно используется для всех подключений и может быть изменен в будущем при необходимости.

Вы имеете в виду обрабатывать потоки перед их отправкой? если да, то его тоже можно реализовать.

  1. Я не тестировал канал данных, но думаю, что это то же самое, что и медиа-канал: соединение 1-1 между каждым узлом с onDataStream, запускаемым при каждом соединении? И сообщения будут отправляться индивидуально каждому пиру?

Да, вы получаете необработанные каналы данных, по одному на подключенный одноранговый узел. Он также будет хорошо работать с упомянутой выше функцией метаданных.

  1. Приятно слышать, что одноранговый сервер не понадобится. Однако для чего нужен этот wss://broker.peerjs.com ?

PeerJS нужен канал для начальной передачи сигналов. Но теперь вместо использования PeerServer вся логика выполняется самой библиотекой PeerJS, и ей нужен только брокер MQTT. Таким образом, вам все еще нужен сервер, но MQTT — это стандартный протокол, поэтому вам нужно только настроить брокера, также ему не нужна база данных или что-либо сохраняется в памяти сервера (как в v1), поэтому он полностью масштабируется.

Все 7 Комментарий

Он готов к использованию в обработчике. Я не нахожу очень полезным событие «начать соединение». В каком случае вы считаете это полезным?

В проекте, который я разрабатываю, одна проблема заключается в том, чтобы избежать нежелательных подключений.

Есть три роли: студент, спикер, преподаватель (я добавил флаг метаданных, указывающий роль в массиве опций при регистрации пира). Преподаватель подключается к серверу со своим известным ID и ждет спикера и ученика. После того, как все они подключены, следует избегать дальнейших подключений.
Отказ, который вы реализовали в версии 2.0.0, должен работать, но мне кажется, что изменения в API довольно радикальны.

Да, новая версия майорская (ломка, обратной совместимости нет). Старый API довольно сбивает с толку, а в коде много устаревших трюков с его первых дней в 2013 году, его очень сложно поддерживать.

Но так как это критическое изменение, я продолжу поддерживать старую версию, поэтому я реализую какой-то способ отклонения в v1. В любом случае, я рекомендую вам перейти на v2, если вам не нужна поддержка очень старых браузеров. Вы получите стабильность, и вам не нужно будет размещать PeerServer.

Отказ от версии 2 еще не завершен, но я сосредоточен на разработке версии 2, так что эта функция скоро будет готова.

Я взглянул на пример, который вы предоставили для v2, и он действительно выглядит впечатляюще: простой чат один на один в нескольких строках кода! Кроме того, я немного подправил этот код и увидел, что onRemoteStream запускается на каждом узле каждый раз, когда кто-то присоединяется к комнате, что позволяет обрабатывать все медиа-соединения, которые может поддерживать ваша пропускная способность: вау!!!

Всего несколько вопросов:

  1. Можно ли будет определить, кто подключается, используя функцию метаданных, как в версии 1?
  2. Смогу ли я получить доступ к удаленным и локальным потокам для выполнения некоторой (локальной) обработки звука через AudioContext? В моем проекте есть партнер А, которому нужно слышать грушу Б в L-канале и C в R-канале своей гарнитуры, и независимо менять громкость каждого из них; и B, и C нуждаются в измерителе звука, подключенном к их микрофону, чтобы постоянно контролировать, правильно ли он работает (я уже частично реализовал эти функции, и мне нужно их сохранить).
  3. Я не тестировал канал данных, но думаю, что это то же самое, что и медиа-канал: соединение 1-1 между каждым узлом с onDataStream, запускаемым при каждом соединении? И сообщения будут отправляться индивидуально каждому пиру?
  4. Приятно слышать, что одноранговый сервер не понадобится. Однако для чего нужен этот wss://broker.peerjs.com ?

PS Я видел, что вы обновили дорожную карту, планируя добавить максимальное количество пиров на комнату, и это то, что мне действительно нужно!

  1. Можно ли будет определить, кто подключается, используя функцию метаданных, как в версии 1?

Да! Я только что добавил эту функцию в план, ее должно быть очень легко реализовать.

  1. Смогу ли я получить доступ к удаленным и локальным потокам для выполнения некоторой (локальной) обработки звука через AudioContext? В моем проекте есть партнер А, которому нужно слышать грушу Б в L-канале и C в R-канале своей гарнитуры, и независимо менять громкость каждого из них; и B, и C нуждаются в измерителе звука, подключенном к их микрофону, чтобы постоянно контролировать, правильно ли он работает (я уже частично реализовал эти функции, и мне нужно их сохранить).

У вас уже есть доступ к потокам на обработчиках. Это не очень хорошо документировано, но, как вы сказали, вы получаете один удаленный поток на одноранговый узел и свой собственный удаленный поток один раз, который прямо сейчас повторно используется для всех подключений и может быть изменен в будущем при необходимости.

Вы имеете в виду обрабатывать потоки перед их отправкой? если да, то его тоже можно реализовать.

  1. Я не тестировал канал данных, но думаю, что это то же самое, что и медиа-канал: соединение 1-1 между каждым узлом с onDataStream, запускаемым при каждом соединении? И сообщения будут отправляться индивидуально каждому пиру?

Да, вы получаете необработанные каналы данных, по одному на подключенный одноранговый узел. Он также будет хорошо работать с упомянутой выше функцией метаданных.

  1. Приятно слышать, что одноранговый сервер не понадобится. Однако для чего нужен этот wss://broker.peerjs.com ?

PeerJS нужен канал для начальной передачи сигналов. Но теперь вместо использования PeerServer вся логика выполняется самой библиотекой PeerJS, и ей нужен только брокер MQTT. Таким образом, вам все еще нужен сервер, но MQTT — это стандартный протокол, поэтому вам нужно только настроить брокера, также ему не нужна база данных или что-либо сохраняется в памяти сервера (как в v1), поэтому он полностью масштабируется.

Отличные новости! Думаю обязательно перейду с v1 на v2. Это сделает все намного проще. Большое спасибо!

Спасибо за замечательную библиотеку

Была ли эта страница полезной?
0 / 5 - 0 рейтинги