Серверная часть для масштабной MMORPG (15 стр)

IndieDev
> Для клиент-серверного общения никакой nat punchthrough не требуется, это для
> P2P общения
только начинаю с этим разбираться, есть гарантия что UDP порт вдруг не поменяется на лету даже при схеме клиент (за чёрти-чем) - сервер с белым IP?

например ENet жёстко привязывает клиента, и если адрес порт не совпадают, то игнорит клиента а потом отключает по таймауту
мне кажется не самый лучший подход

#!

На счет гарантии - без понятия, это надо уже для каждой ОСи читать документацию.
Что касается внешнего IP, то обязательно, а как вы хотите принимать соединения имея серый IP?
Если вы знаете такой способ, то расскажите мне тоже, а то не хочется за внешний IP адрес провайдерам переплачивать (no-ip не в счет)

Не уверен, что правильно понял, но ответ примерно такой "а какой смысл начинать общение непонятно с кем?"

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

#!
> это может быть тот же клиент с которым до этого нормально общались
> просто у него "скакнул" порт из-за "чёрти-чего"
> и сервер его уже не признаёт, что беда для такого клиента

Не знаю честно говоря, как там может порт "скакнуть" и думаю, что
это мало имеет отношения к протоколам, порт и на TCP может "скакнуть", согласны?

IndieDev
> это мало имеет отношения к протоколам
это имеет отношение к провайдерам их оборудованию

> порт и на TCP может "скакнуть", согласны?
на TCP не может ибо создаётся соединение, в UDP соединений нет
и порт разумно переиспользовать

ну в общем я пока склоняюсь что нужен id клиента и id сессии которое зашифровано
единственное эти id не могут быть хоть сколько-нибудь длинными т.к. пересылаются в каждом пакете

#!
>на TCP не может ибо создаётся соединение, в UDP соединений нет
Кажется, это не имеет никакого отношения к портам и сокетам.

IndieDev
> Вы можете предоставить ссылку на статью об этом?
Нет, это данные полученные на личном опыте, а не теория. Мне в целом все равно, в чем в конкретном случае дело: в маленьком тайм-ауте на UDP «сессию», в закрытии портов фаерволом, в произволе провайдера которому не нравится UDP трафик, суть в том что есть заметное количество потенциальных игроков которые не смогут играть по UDP

IndieDev
> И никаких jitter'ов там нет, так что пакеты отправляются моментально.
Ты точно понимаешь о чем говоришь? Jitter может быть вызван разницей маршрутов, загрузкой сетевого оборудования по пути и и.п., причём тут протокол?!

Вий
> в произволе провайдера которому не нравится UDP трафик
там железо настроено так что первым под нож идёт UDP трафик ибо он может теряться по определению
но вообще сейчас все довольно жирные и канал у них не заткнуть просто так

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

Zab
> Часто даже требование такое выставляют при разработке, чтобы смена адреса не
> обрывала связь.
Невозможно.

Вий
>Ты точно понимаешь о чем говоришь? Jitter может быть вызван разницей маршрутов, загрузкой сетевого оборудования по пути и и.п., причём тут протокол?!
Да, извиняюсь, я имел в виду nagle

Super_inoy
> а вот автореконнект с определением сессии по другим параметрам возможен
Так и делают. И что в этом невозможного?

Zab
> Так и делают. И что в этом невозможного?
То что связь то оборвалась. И реконнект не мгновенный, поэтому это так или иначе заметно.

Super_inoy
В случае UDP никакого обрыва то и нет, клиент шлет себе и шлет, но в какой-то момент его адрес меняется, а он этого не замечает и продолжает слать как ни в чем не бывало.
Серверу же надо как-то сообразить, что вот этот новый клиент ни фига не новый и продолжить работу, поправив свои данные.