doom2d.org

Написать велосипед или заюзать https://github.com/paullouisageneau/libjuice. А может и то, и другое. Мастер можно использовать в качестве stun-сервера.
Даже простенький велосипед, возвращающий реальный адрес+порт сервера, упростит создание домашних серверов.

Не совсем в тему, но всё же. Попалась на глаза вот такая альтернатива MiniUPnP, но попроще и чисто для FPC:
https://github.com/rvk01/upnp
https://forum.lazarus.freepascal.org/index.php/topic,63652.msg482630.html#msg482630 - тема на форуме Lazarus, из которой она выросла.

Покуда искал ссылку выше, набрёл ещё на вот такую библиотечку для Delphi из 2011:
https://forum.lazarus.freepascal.org/index.php/topic,43865.msg307698.html#msg307698
Судя по всему, она представляет собой интерфейсный заголовок для встроенной в Windows COM-реализации UPnP.

К слову, для разнообразия я бы также рассмотрел вот эти вещи:
https://github.com/paullouisageneau/libplum
http://miniupnp.free.fr/libnatpmp.html

_________________
Чёрный Думер, Чёрный Думер
С монстрами сражается.
Чёрный Думер, Чёрный Думер
Рокетланчер плавится.

Ещё вариант: http://samy.pl/pwnat/

Я постоянно забываю этот термин: https://en.wikipedia.org/wiki/UDP_hole_punching.

Исходники этой вещицы лежат на GitHub - https://github.com/samyk/pwnat.
Репозиторий вроде живой и на нём дофига звёзд, однако всё равно пишут, что в наше время это всё уже дохлый номер:
https://stackoverflow.com/questions/22985793/is-pwnat-still-an-applicable-solution
https://github.com/samyk/pwnat/issues/18 - Does pwnat still work?

Ну и да:
» pwnat will work on most *nix operating systems, and potentially Windows via cygwin. Tested on Linux and OS X.
Хотя есть и такое: https://www.sumitgupta.net/pwnat-windows-complied-version/.

_________________
Чёрный Думер, Чёрный Думер
С монстрами сражается.
Чёрный Думер, Чёрный Думер
Рокетланчер плавится.

Не. Надо связку libjuice+libplum.

Проблема в том, что во-первых, miniupnpc не всегда срабатывает штатно. Во-вторых, даже если на роутере нет поддержки этого протокола, на резидентских соединениях очень легко пробить UDP порт. Т.е в 99% случаев когда кто-то захочет залететь с компа и поиграть с друзьями, это должно и может работать.

Алгоритм такой:
1. пробуем libplum. если от библиотеки успех -> ничего не делаем
2. пробуем libjuice. если успех -> меняем порт на пробитый и сообщаем об этом мастеру. в этом случае порт в настройках будет бесполезен, потому что мы пляшем от того что нам дал NAT.
3. если ничего не работает, используем TURN сервер. это будет медленно и через посредника, но лучше чем неподключение вообще. тут порт тоже будет бесполезен

Оставлю себе ссылку с более-менее внятным описанием того, как это работает: http://neerc.ifmo.ru/wiki/index.php?title=NAT#UDP_hole_punching.

Правильно же понимаю, что это предлагается вместо нынешнего miniupnpc?

Я начинаю жёстко путаться во всём этом. Чей NAT здесь подразумевается - провайдерный или наш?
Если первое, то какое отношение ко всему этому имеет проброс портов на домашнему роутере?
Если же наш, то как данные вообще умудряются пройти через провайдера с его NAT в таком случае?
Кто ему сообщает, что васян с адресом 228.42.148.137 из внутренней сети поднял сервер дум 2жвадэ форева на порту 46969 и ждёт не дождётся таких же аутистов?

В libjuice вроде бы заявлен "TURN relaying (RFC5766 then RFC8656)", или это другое?

_________________
Чёрный Думер, Чёрный Думер
С монстрами сражается.
Чёрный Думер, Чёрный Думер
Рокетланчер плавится.

Представь, что ты пытаешься подключиться к серверу ДФ на порту 2228. Ты отсылаешь пакет на хост 55.55.55.55:2228, и провайдерский NAT выделяет тебе рандомный эфемерный порт (допустим 57228). Сервер будет тебе отсылать пакеты на твой внешний адрес с портом 57228.

И вот в зависимости от типа NAT, этот порт обладает полезными свойствами. Чаще всего, любой трафик на твой внешний адрес и порт 57228 будет приходить к тебе.

И вот это свойство можно использовать в своих корыстных целях. Найди STUN сервер, подключись к нему, и выбей этот эфемерный порт. Теперь на этот порт траффик будет идти к тебе (в общем, частом случае!) И вот на этом выбитом порте нужно делать сервер ДФ. Ещё, чтобы порт не пропал, тебе нужно обновлять этот порт в таблице маршрутизации путём отправки пакетов-пустышек на этот STUN сервер. Детали могут меняться в зависимости от типа NAT.

Эфемерных портов так-то маловато для провайдерского NAT'а будет, не? Даже если брать весь диапазон от 0, а не только от 49152, рекомендованный IANA.
Или он ещё поле отправителя в ответах сервера проверяет? Если да, то тогда, выходит, вот этого "полезного свойства" нет, так?

Интересно, я понятия не имел, что STUN-сервера бывают публичными. А сейчас погуглил чутка - и вправду:
https://openrelayproject.org
https://gist.github.com/mondain/b0ec1cf5f60ae726202e
https://gist.github.com/zziuni/3741933
https://stunprotocol.org - stunserver2024.stunprotocol.org

А есть ли какие-нибудь преимущества у использования публичного STUN-сервера вместо того, чтобы держать свой собственный?

Объясни мне ещё тогда, пожалуйста, разницу между STUN, TURN и ICE таким же простым и понятным языком.
И ответь на вопросы (1) и (3) из прошлого сообщения.

_________________
Чёрный Думер, Чёрный Думер
С монстрами сражается.
Чёрный Думер, Чёрный Думер
Рокетланчер плавится.

» Правильно же понимаю, что это предлагается вместо нынешнего miniupnpc?
Да, но не обязательно. Всё-таки эти протоколы не так уж и часто поддерживаются.

» В libjuice вроде бы заявлен "TURN relaying (RFC5766 then RFC8656)", или это другое?
Вроде то. Но я сейчас понял, что TURN не сработает, потому что нужно будет переделывать сеть и механизм установки соединения с "сервером".

» Эфемерных портов так-то маловато для провайдерского NAT'а будет, не?
Для обычного резиденсткого вполне, это же позволяет один адрес на тысячи устройств растянуть.
У мобильных есть своя хитрая армянская схема с CGNAT, вот потому что у них не хватает адресов.

» Или он ещё поле отправителя в ответах сервера проверяет? Если да, то тогда, выходит, вот этого "полезного свойства" нет, так?
Да. В таком случае пирам нужно будет друг другу одновременно отправить пакеты, чтобы успокоить свои файрволлы, и там разбираться на месте с NAT. Но для ДФ не важно, потому что тогда придётся сеть переделывать, если захочется это учитывать. И такое довольно редко для обычных резидентских (не мобильных!) соединений у нас. С мобильными большие траблы.

» Интересно, я понятия не имел, что STUN-сервера бывают публичными.
Ты наверное путаешь с TURN серверами. STUN сервера вообще не затратно держать, в отличие от TURN серверов.

» А есть ли какие-нибудь преимущества у использования публичного STUN-сервера вместо того, чтобы держать свой собственный?
Преимуществ особых нету, как и недостатков. Неважный вопрос.

» Объясни мне ещё тогда, пожалуйста, разницу между STUN, TURN и ICE таким же простым и понятным языком.
ICE - название для процесса установления прямого соединения между двумя устройствами
STUN - определение "разогретых" портов, по которым можно установить прямое соединение с пиром
TURN - передача произвольного трафика между двумя пирами, которым не установить прямое соединение, когда оба за тяжелейшими условиями для установления прямого соединения

Я к тому, что в libjuice указан UPnP-IGD среди поддерживаемых протоколов, а это буквально то, что делает MiniUPnP.

А если в ENet добавить возможность использовать уже существующий UDP-сокет со стороны? Или там глубже переделывать придётся?

Вот кстати вопрос. А если между клиентом и сервером больше одного NAT, то как этот схематоз работает? Как второй NAT (и далее) будет пересылать пакеты с первого и обратно до него? Он в таком случае перезаписывает уже и поле внутреннего порта у исходящего IP-пакета с UDP-датаграммой на тот порт, с которого он от первого NAT поступил?

Так когда проверяет, а когда не проверяет? И как "такой случай" определять?

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

Ну вот кстати Open Relay Project по ссылке выше помимо STUN предлагает и TURN-сервер публичный. Но, видимо, только для WebRTC.
А в TURN вообще весь трафик ретранслируется или только установка соединения?

_________________
Чёрный Думер, Чёрный Думер
С монстрами сражается.
Чёрный Думер, Чёрный Думер
Рокетланчер плавится.

» Я к тому, что в libjuice указан UPnP-IGD среди поддерживаемых протоколов, а это буквально то, что делает MiniUPnP.
В случае ДФ лучше пытаться открыть порт отдельной библиотекой.

» А если в ENet добавить возможность использовать уже существующий UDP-сокет со стороны? Или там глубже переделывать придётся?
Боюсь, что глубже. Если использовать TURN, тогда "сервер" должен сообщать каждому "клиенту" о том, как надо подключаться (пытаться напрямую на порт, через не-TURN методы ICE или через TURN сервер)

» Вот кстати вопрос. А если между клиентом и сервером больше одного NAT, то как этот схематоз работает? Как второй NAT (и далее) будет пересылать пакеты с первого и обратно до него? Он в таком случае перезаписывает уже и поле внутреннего порта у исходящего IP-пакета с UDP-датаграммой на тот порт, с которого он от первого NAT поступил?
Этот схематоз тогда ломается, и становится непредсказуемым для ICE.

» Так когда проверяет, а когда не проверяет? И как "такой случай" определять?
Приложение в целом должно быть так сделано, чтобы оба клиента знали, что друг-друга надо "щупать". Пиры разговаривают с помощью матчмейкера, STUN сервера. Но обычно, если у клиента уже есть успешно прогретый порт, его переиспользуют, и STUN сервер с радостью об этом сообщит. Вот в этом и трабл в случае с ДФ дальше простого кейса статичного пробития порта.

» Мне это нужно как минимум для общего образования, потому что в книгах описано очень мутно. А сеть нам всё равно придётся переделывать, и уже очень скоро. Поэтому чем больше я буду знать таких деталей, тем полнее смогу их учесть и тем лучше спроектирую всё.
Делай так, чтобы работало в вебе, будет работать везде. WebRTC/WebTransport.

» Ну вот кстати Open Relay Project по ссылке выше помимо STUN предлагает и TURN-сервер публичный. Но, видимо, только для WebRTC.
А в TURN вообще весь трафик ретранслируется или только установка соединения?
Весь трафик. Ретрансляция установки соединения это скорее про STUN.

Ты пиши к таким утверждениям сразу и обоснование, чтобы очевидное "почему?" не спрашивать.

А это был вопрос с подвохой. Тогда как он работает вообще если в обычном случае у нас как минимум четыре слоя NAT (клиент:роутер - клиент:провайдер - сервер:провайдер - сервер:роутер)?

Если я правильно понимаю, то описываемое тобой - это port-restricted cone NAT. А когда проверяется ещё и адрес отправителя, то это symmetric NAT. Верно?

А WebSocket?

_________________
Чёрный Думер, Чёрный Думер
С монстрами сражается.
Чёрный Думер, Чёрный Думер
Рокетланчер плавится.

» А это был вопрос с подвохой. Тогда как он работает вообще если в обычном случае у нас как минимум четыре слоя NAT (клиент:роутер - клиент:провайдер - сервер:провайдер - сервер:роутер)?
На роутер пофиг. Главное, чтобы до него дошел пакет с провайдера.

» Если я правильно понимаю, то то, что ты описываешь - это port-restricted cone NAT. А когда проверяется ещё и адрес отправителя, то это symmetric NAT. Верно?
Вроде да.

» А WebSocket?
Там сложнее с ICE.

Ну по хорошему - да. Но надо это нормально интегрировать в enet, а не сбоку прилепливать: все данные надо слать через juice_send и получать через juice_cb_recv_t. (https://github.com/paullouisageneau/libjuice/issues/204)

А тут только такие варианты:
- Юзать форк в котором есть абстракция для i/o (если такой существуют)
- Форкнуть enet и допилить самим
- Юзать какой-то порт на паскаль, который утащить в реп игры и допиливать
- Перетащить сеть на кастомный велосипедный протокол


Есть ещё libnice как альтернатива libjuice.