Не могу пробить NAT, UDP создает канал (7 стр)

Сейчас в большинстве случаев до _квартиры_ доходит занатовый адрес, и в каждой квартире по роутеру, сужу по количеству wifi точек соседей, которые, гадство, их не отключают... Чему тут удивляться? Жду еще комментарий Dampire по поводу поиска локальных адресов роутеров...

А трассировка пути - это совсем черная магия?

Ramm
> А трассировка пути - это совсем черная магия?
При проходе через роутер в пакет дописывается информация о пути, которым он шел. Весь путь можно проследить, по идее, если его специально не стирали аннонимайзерами, и не подделывали. Но как это сделать не знаю, через сокеты оно не доступно.

Ramm
> А трассировка пути - это совсем черная магия?

tracert трассирует так: посылает пакеты до цели с возрастающим TTL, 1, 2, 3, ..., пакет соответственно сдыхает сначала на роутере, потом на шлюзе роутера, потом далее по цепочке до цели. Вся эта цепочка по очереди посылает обратно сообщение, что время жизни истекло, получите пакет обратно. Ну и адрес свой оставляют. Делается это кажись через ICMP. Вообще могут быть ситуации когда это не поможет. Например, если у провайдера 2 локальные сетки между собой не связанные, сидят за NAT'ом у которого NAT Loopback не включен, ну и соответственно 2 клиента, один в первой, другой во второй, Loopback это то самое которое отвечает на то отвечает ли NAT на запросы из внутренней сети или нет. В этом случае вообще ничего походу не сделаешь) Но думаю, что это нечастая ситуация в реале.

Еще во всяких игровых серверах, на некоторых клиентов вешают функции посредника. Тогда получается трафик будет идти не через сервер нагружая его, а через одного\нескольких игроков, которых тоже можно подбирать по значению пинга, мол у игрока 1 пинг до игрока 2 и 3 хороший, а игроки 2 и 3 не могут друг до друга достучаться, значит будешь им посредником.

Ramm
Локальный адрес в сети провайдера узнавать тухлая затея, порты то мапиться могут как угодно. Но ты сам понимаешь, что это невероятно? В одной квартире - да легко, тут тебе надо знать только локальный адрес и локальный порт. Плюс учитывай, что невозможность игры за одним натом это особенность настройки. За каким хером ты сам придумываешь невероятные сценарии и начинаешь вайн? То у тебя порты все рандомятся, то у тебя у всех симметрик, теперь вот все сидят за одним натом.

Dampire
> За каким хером ты сам придумываешь невероятные сценарии и начинаешь вайн?
Хз, но у меня этот невероятный сценарий прям передо мной сейчас работает)))
Ок, план такой:
1. Получаем на сервере пакеты от клиентов, узнаем их адреса и порты, отправляем им, они начинают совершать фрикции, слать пакеты друг другу в надежде пробиться...
2. Если у них это не удалось, они уведомляют сервер, типа 20 секунд молчание, он проверяет адрес, если он не совпадает - пускаем весь их трафик через сервер, т.к. NAT не пробит и нихрена не вышло. Если совпадает - просим их прислать локальные адреса и забиндинные на прослушку порты. Отправляем им полученную инфу.
3. Клиенты пробуют подключиться по локальным адресам, если выходит - повезло, нет - пускаем весь трафик через сервер.
Так? Все правильно?

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

Ramm
> Хз, но у меня этот невероятный сценарий прям передо мной сейчас работает)))
Этот невероятный сценарий перед тобой потому что у тебя отладка идет, это раз. Во вторых это решается локальными адресами (которые можно сразу хранить вместе с внешними и отсылать их тоже парой, пусть клиенты сами разбираются к чему подключаться). А чтобы у тебя два клиента сидели за одним провайдерским натом (но за разным домашним) это как раз из области уличной магии.

Что касается сервера доставки - достаточно подменить адрес проблемного клиента адресом сервера доставки. Весь трафик гонять через него не нужно.

Zab
Да, я тоже об этом думал. Ну и если что-то хоть немного получится - увеличить кол-во серверов...
Dampire
Да, точно, только для проблемных клиентов, а те, кто смогут подключиться напрямую - будут слать напрямую.
Уфф, блин, всем спасибо большое, более-менее начал шарить в теме.

CoderInTank
> Тогда получается трафик будет идти не через сервер нагружая его, а через
> одного\нескольких игроков, которых тоже можно подбирать по значению пинга, мол
> у игрока 1 пинг до игрока 2 и 3 хороший, а игроки 2 и 3 не могут друг до друга
> достучаться, значит будешь им посредником.
И если кто-нибудь уйдет - у тех, кто к ним подключен все ляжет)

Ну почти так работает don't starve together. Когда выходит "хозяин" сервера у остальных игра заканчивается.

GLoom
Одно дело - создатель лобби, другое - пятый чел, к которому тебе повезло подключиться... Как вариант - тут же переключаться на другого в лобби или на свой сервер.

Ramm
> И если кто-нибудь уйдет - у тех, кто к ним подключен все ляжет)

ну вот в Awesomenawts допустим иногда возникает прямо посреди игры на пару секунд сообщение "Подождите, идет смена хоста\оптимизация подключений".  Вполне себе нормальная ситуация и не раздражает так как понимаешь, что сейчас то получше должно стать) Но и это убрать просто введя запасного посредника который если что налету подхватит.

Ребят, я тут тему создал по поводу внутреннего буфера сокета
http://www.gamedev.ru/code/forum/?id=232860#m14
Можете написать свои мысли по этому поводу?=)

У меня (Address) restricted cone nat - узнал через приложение в play market (stun for NAT)
Возможно ли пробить его имея 1.тачку с Bungecord(белый аипи)
2.тачка с сервером Minecraft (серый аипи)
Вторая тачка находится за NAT, двойной ли он хз,т.к не знаю других методов проверки какой NAT, провайдер Московский.