Моя мотивация
Наша цель состояла в том, чтобы сделать оптимизированное и простое в использовании одноранговое веб-приложение для обмена файлами. Больше усилий для удобства пользователей и простоты выполнения задач. Веб-приложение предназначено не только для определенной группы людей, но и для всего сообщества.
Мы хотим создать механизм передачи файлов ZERO THOUGHT, при котором для обмена файлами между двумя устройствами или людьми просто не нужно думать о КАК, ГДЕ, ПОЧЕМУ и ЧТО .
Зачем все это, когда существует так много веб-сайтов для обмена файлами?
Ну, я тоже думал об этом, но все эти веб-сайты никогда по-настоящему не объясняли, где эти файлы передаются или хранятся. Это может быть угрозой конфиденциальности, поскольку многие люди во время текущей ситуации пандемии или обычно будут делиться конфиденциальными документами или файлами, используя эти службы. Используя безопасное одноранговое соединение и его каналы данных, можно передавать огромные файлы, не сохраняя их на каком-либо сервере, что делает его действительно надежным и по-настоящему приватным, поскольку только подключенные клиенты / одноранговые узлы обмениваются данными напрямую без промежуточного сервера для передачи.
Одноранговое соединение и каналы данных становятся возможными благодаря WebRTC. WebRTC - это, по сути, способ глобальной сети для связи и передачи данных друг другу. Что очень похоже на обмен данными по Bluetooth, NFC и WIFI. Используя WebRTC, мы можем добиться кроссплатформенной поддержки, так как это веб-интерфейс.
Давайте подробнее рассмотрим WebRTC.
WebRTC
WebRTC - это бесплатный открытый проект, который предоставляет браузерам и мобильным приложениям возможности связи в реальном времени (RTC) через простые API. Компоненты WebRTC оптимизированы, чтобы наилучшим образом служить этой цели. «-« webrtc.org
Что ж, гипотетически, «одноранговая» ассоциация рассматривает прямую информацию, передаваемую между двумя устройствами, без требования к серверу для обработки этой информации. Идеально подходит для нашего случая? 😕 К сожалению, WebRTC работает не так!
Хотя WebRTC создает одноранговое соединение, несмотря на все, что он действительно требует, сервер, известный как сервер сигнализации, используется для обмена данными об устройствах, которые, как ожидается, будут подключаться друг к другу. Этими тонкостями можно поделиться с помощью любых обычных методов обмена информацией. Здесь предпочтение отдается WebSockets, поскольку он снижает инертность при совместном использовании этих дополнительных данных в огромной системе для настройки ассоциации.
Проще говоря, сервер сигнализации помогает в установлении соединения, однако, когда соединение установлено, сервер больше не обращается к информации, совместно используемой между связанными устройствами.
Год назад, когда я начал свой первый проект WebRTC, было немного сложно найти достойную рабочую модель, которая работала бы на уровнях Производство. Так что впоследствии, просматривая Интернет, я нашел этот канал Youtube Coding With Chaim. Разработчик привел действительно хорошие примеры, касающиеся готовых к производству приложений Webrtc.
Как WebRTC создает соединение (технически)
Что ж, нет простого способа объяснить это, но вот мой подход к этому: из всего значительного количества устройств в сети в любом случае должно быть одно устройство, которое запускает соединение, производя информацию о сигнале, которая будет отправлена на сигнальный сервер. Этот одноранговый узел известен как инициатор, и в простом узле (модуль, используемый в этом проекте) { initiator: true }
передается конструктору, когда создается одноранговый узел инициатора.
Когда мы получаем сигнальную информацию однорангового узла, эта информация должна быть так или иначе отправлена на разные концентраторы через сервер сигнализации. Различные концентраторы получают эту информацию и пытаются установить связь с инициатором. Во время этой процедуры эти одноранговые узлы также создают свою сигнальную информацию и отправляются инициатору. Инициатор получает эту информацию и пытается установить соединение с остальными узлами.
И вуаля! 🥳 Теперь устройства подключены и теперь имеют канал данных для обмена информацией без промежуточных серверов.
Постарайтесь не подчеркивать вероятность того, что вы не смогли понять описанную выше работу WebRTC и то, как простой одноранговый узел его абстрагирует. Когда я только начал возиться с WebRTC, меня сильно одурачило. Предстоящие и предстоящие сегменты дают гораздо более простое и подробное объяснение этого.
Совместное использование файла с помощью WebRTC (с использованием простой одноранговой сети)
Найдите весь код на этом Репо. Если вы попытаетесь выполнить приведенный выше код в браузере и выберите какой-нибудь файл изображения (желательно менее 100 КБ), вы увидите, что он сразу же загружает его. Это потому, что одноранговый узел находится в аналогичном браузере, а отправитель подсказывает.
Размер отправленной и полученной информации эквивалентен. Это показывает, что у нас была возможность переместить всю запись за один раз! 🥳
Зачем использовать буфер массива вместо больших двоичных объектов?
В нашем предыдущем коде, если мы выберем огромный файл (более 100 КБ), документ, скорее всего, не будет отправлен, это прямой результат определенных ограничений каналов WebRTC.
Каждый буфер массива имеет ограничение в 16 КБ за один раз. Вкратце, это означает, что мы должны разделить файл на небольшие буферы массива. (нарезать отбивную 🔪)
Незначительные файлы могут быть отправлены через WebRTC за один раз, однако для больших документов разумно изолировать наши документы в меньшем буфере массива и аналогичным образом отправить каждую часть. Объекты ArrayBuffer и Blob имеют ограниченную емкость, что упрощает эту задачу. Для этого, если вы внимательно посмотрите на код, мы использовали модуль под названием stream saver, который затем преобразует буфер массива обратно в большой двоичный объект.
Маленькая заметка
Поскольку javascript однопоточный. Обработка большого количества буферов массива может привести к зависанию нашего красивого пользовательского интерфейса. Чтобы исправить это, мы будем использовать сервис-воркеров. Service worker - это сценарий, который ваш браузер запускает в фоновом режиме, отдельно от веб-страницы, открывая доступ к функциям, которым не нужны веб-страница или взаимодействие с пользователем. Подробнее об этом вы можете узнать здесь.
Преимущества разделения файлов на буферы массива
Хотя может показаться, что разделение файла - это всего лишь некоторый дополнительный код для запутывания материала, мы получаем следующие преимущества, которые могут помочь в улучшении нашего приложения для обмена документами.
- Поддерживается почти во всех браузерах.
- Поддержка огромного размера документа. Как упоминалось ранее, это основное объяснение того, почему мы его внедряем.
- Превосходный метод для расшифровки объема отправленной информации. Отправляя запись в буферах, мы теперь можем отображать информацию, например уровень отправленного документа, скорость отправки записи и т. д. и так далее.
- Определить отправленный неполный документ - ситуации, когда файл не может быть отправлен полностью, теперь можно будет получить и обработать другим способом.
Заключение
Поскольку у нас есть простое приложение для обмена документами, использующее WebRTC, которое дополнительно использует ArrayBuffer, теперь мы должны начать рассмотрение того, что подготовит наше приложение к производству. Эти детали в значительной степени предназначены для изучения, а не просто следования прямому руководству.
Что еще можно добавить: -
· Сервер сигнализации (серверы STUN и TURN)
· Обеспечение масштабируемости множественных одноранговых соединений.
· Гибридный способ поделиться, когда кажется, что WebRTC не работает.
· Повышение эффективности и скорости переводов.
Надеюсь, я дал достаточно знаний, чтобы вы, ребята, начали работу с вашими приложениями WebRTC.
Psst… Ребята, я создал веб-приложение, которое использует WebRTC и WebSockets для обмена файлами между устройствами.
Он называется Vegh 🌪️ и имеет открытый исходный код. Я не мог представить себе ничего лучше, чем увидеть ваши обязательства и критику в отношении приложения. Предложите немного ❤️ на репозитории GitHub.
Кроме того, вы знали? Вы можете держать аплодисменты до 50 раз! 😊