Comments 25
Осталось только примотать файлообменник!
Например, два телефона показывают друг другу QR-коды, после чего могут обмениваться файлами. Получится что-то типа https://ru.wikipedia.org/wiki/Shareit, только через интернет.
Вообще, необходимость иметь дополнительный канал связи для обмена адресами это проблема. Если хотим удобства, придётся использовать третью сторону для этого. А ей придётся доверять.
Я же правильно понимаю, что если я хочу добавлять в свой уютный чатик кого угодно, то кому-то из чатика придётся руками добавлять каждого нового участника?
Третья сторона нужна только чтобы пробить "тоннель". При обмене достаточно шифровать трафик чтобы исключить прослушку. Хотя тут уже проблема обмена ключами всплывает.
Я скорее про то, что если мы не хотим заниматься передачей портов друг другу, т.е. хотим удобства, то нужна третья сторона, которая сделает это за нас. Типа в приложении будет уведомление "Вася хочет подключиться к вам, Ок?".
Если вы оба за NAT, то без третий стороны никак.
А учитывая что кто угодно может пытаться пробить тоннель к вам, то даже если это ваш stun-сервер, нельзя быть уверенным что к вам реально подключается Вася. Это просто вариант создания канала для обмена сообщениями. А вот Вася на то стороне или нет, всё равно придется выяснять с помощью обмена сообщениями после настройки канала.
Т.е. всё-равно нужна идентификация по установленному каналу.
Вообще, пока я ещё не знал про hole punching у меня был рабочий прототип "штормового пробития")
Оба участника начинали яростно спамить друг другу во все порты, при этом с небольшой долей вероятности направления взаимно совпадали и канал поднимался, так что при достаточном упорстве всё возможно.
С другой стороны, сетевое оборудование на это не рассчитано и процессор моего RouterBoard нормально так напрягался на этом моменте)
cp866
А что за приколы с кодировкой? Оно по-умолчанию прикидывается DOS?
Если бы все было так просто в реальности, то к STUN был бы не нужен TURN в паре =)
Ну, ретрансляция не есть решение задачи p2p. Само собой, не каждый транслятор можно так пробить, не в каждой корпоративной сети вообще есть гейтвей в интернет)
Однако большинство кейсов покрываются STUN, иначе бы Telegram и Discord не работали с таким широким покрытием.
Вот что нашёл по теме
Преодоление барьера из двух симметричных NAT
http://yourcmc.ru/wiki/Преодоление_барьера_из_двух_симметричных_NAT
Т.е. пробитие возможно, но только не за разумное (для работы) время
Если кратко, то предлагается найти закономерность выделения портов
Так в чем уникальность метода если используются STUN сервера? Это десятки лет назад так же было реализовано. Что нового выдумал автор?
Идея с децентрализованным форумом интересна, но не реалистична. Множеству участников надо независимо на своих устройствах хранить историю сообщений. Но при больших размерах сети места для этого не хватит. Тогда, выходит, клиенты будут стремиться удалять ненужное. При сильно больших размерах сети этого ненужного (в том числе спама) будет столько, что хранить будут только что-то вроде личных сообщений. Но в таком случае не будет даже стимула хранить чужие личные сообщения, на случай, если получатель находится вне сети. Тогда выйдет, что личные сообщения будут доходить, когда оба отправитель и получатель находятся в сети. В итоге вся концепция выродиться в нечто вроде децентрализованного мессенджера (вроде Tox).
Спасибо автору за пост, очень интересно почитать на русском.
Если эта тема интересна советую посмотреть keet.io, и фреймворк под ним holepunch.to
А торренты же тоже используют без трекинговый обмен при включенном DHT. Насколько этот подход хуже вашего? или DHT это поверх аналога вашего только от bittorrent ?
У NAT есть киллер-фича — он представляет собой идеальный фаервол:
O_O Эта киллер фича реализуется просто настройкой дефолтного поведения нормального брандмауэра. Например, у меня на маршрутизаторе стоит OpenWRT и задано, что никого внутрь не пускать по IPv6 (как ни странно, дефолтное поведение из коробки). Мне не нужны никакие NAT. Всё работает и также защищено, как было бы «защищено» NAT.
А вот «киллер фича» NAT раскрывается в полной мере, когда я хочу пустить куда-то извне. В IPv6 я просто говорю брандмауэру, а пусти ка вот на этот хост или группу хостов соединения по вот этому порту. А теперь попробуйте сделать тоже самое при использовании NAT! А уж если хотите p2p соединений, то придётся пользоваться услугами посредников.
Отлично, давайте кооперироваться! У нас есть проект $hyoo_crowd реализующий децентрализованную субд с крипто-аутентификацией, крипто-авторизацией, бесконфликтным слиянием изменений и, конечно, гуями. Хотелось бы переложить её на полноценные P2P рельсы (пока что клиенты коннектятся к серверам, но алгоритмически это такие же равноправные ноды, как и клиенты), а у вас есть как раз именно они. Так что давайте сообща сделаем что-то по настоящему крутое. Предлагаю обсудить это на нашем форуме.
Заканчивался 2023ий год ... на дворе свирепствовал древний cp866 ...
P2P-форум с нуля | от NAT hole punching до автономной и полностью децентрализованной сети