Вопросы о передаче данных через inte rnet напрямую, без загрузки данных на платформы разработки мобильных приложений, Android, iOS - PullRequest
0 голосов
/ 10 марта 2020

Проводил исследования в течение нескольких часов, но не дал четкого объяснения.

Файлы размером 100 КБ должны быть отправлены через устройство inte rnet на устройство. Одним из методов является использование платных серверов между ними (т.е. загрузка данных на сервер, уведомление клиента и загрузка файла с сервера клиентом). Этот метод дает преимущество в случаях обрывов соединения или офлайн-клиентов.

Однако есть ли способ отправить данные «напрямую», не загружая их на сервер (Вопрос 1)?

Возможно, есть, но «самая популярная поисковая система» возвращает сторонние решения или методы на короткие расстояния, такие как соединение Bluetooth или WiFi.


Предполагается, что есть способ отправлять данные напрямую на большие расстояния:

  1. Как установить соединение между устройством загрузки и загрузкой на Android или iOS? Мне кажется, что между ними должен быть хотя бы сервер, чтобы хранить адреса обоих устройств и передавать их на другую сторону. Другими словами, сервер необходим «всегда», даже если данные не должны храниться в облаке. Правильно ли это утверждение (Вопрос 2)? Если да, существует ли совершенно бесплатная (или, скажем, бесплатное рукопожатие) платформа или услуга для передачи адресов?

  2. Слишком много 100 КБ для отправки напрямую (Вопрос 3)? Если слишком много, учитывая, что соединение прерывается и т. Д. c - возможно ли разделить файл на более мелкие пакеты и повторно объединяться после скачивания на Android или iOS? Каков оптимальный размер пакета разделения для такой передачи?

  3. Будет ли отправка и получение данных напрямую потреблять больше батареи, чем метод загрузки на сервер (Вопрос 4)? Если да, то какая процентная разница ожидается в среднем?

Спасибо.

1 Ответ

0 голосов
/ 10 марта 2020
  1. Магические c термины, которые необходимо найти, - это обход NAT или согласование NAT. По сути, соединить двух клиентов друг с другом намного сложнее, чем вы думаете. Ваш сервер не просто должен будет делиться своими IP-адресами друг с другом, он должен будет координировать устройства для совместной работы, чтобы помочь преодолеть уровни NAT и брандмауэры, которые будут работать против вас. Даже при надежной реализации у вас будет значительный процент отказов (вы можете получить 80-90% успеха после больших усилий). Вы всегда не сможете подключить IPv6 к клиентам IPv4 друг к другу. Если значительная частота отказов неприемлема для вашего приложения, то вам нужен запасной путь, по которому данные отправляются через сервер. Возможно, вам лучше избавиться от боли и просто каждый раз использовать путь к серверу.

  2. Я не знаю ни о каком таком бесплатном сервисе. Если вы катите свое собственное решение и у вас не слишком много пользователей, то, возможно, вы можете претендовать на бесплатный уровень с облачным провайдером.

  3. 100KB не особенно важны, вы будете хорошо. Он не помещается в один сетевой пакет, поэтому он будет отправлен через целое число rnet в виде множества небольших пакетов (вероятно, где-то между 500 и 1200 байтами каждый). В зависимости от технологии, которую вы выбираете для отправки данных, разделение сообщений на мелкие части и повторная сборка могут или не могут быть вашей проблемой.

  4. Я не думаю, что будет Разница в энергопотреблении между отправкой данных в одноранговой сети и между отправкой данных в одноранговом сервере. Устройство просто отправляет данные в маршрутизатор / сотовую сеть в любом случае.

...