Тёмная тема
- Вий
- Постоялец
IndieDev
Ну в остальном то я не спорю, у TCP одни недостатки. Но если у тебя TCP да на 80 порт, вероятность что трафик дойдёт максимальная.
Zab
>В случае UDP никакого обрыва то и нет, клиент шлет себе и шлет, но в какой-то момент его адрес меняется, а он этого не замечает и продолжает слать как ни в чем не бывало.
>Серверу же надо как-то сообразить, что вот этот новый клиент ни фига не новый и продолжить работу, поправив свои данные.
Динамический адрес обычно меняется при переподключении к сети провайдера, а не пока вы находитесь в сети.
В целом, вы все не туда метите, вы описываете не транспортный уровень модели OSI в состав которого и входят протоколы TCP/UDP, как говорится "Проблемы индейцев шерифа не волнуют".
Смена динамического IP - это вообще провайдерские проблемы и они никакого отношения к TCP/UDP не имеют.
IndieDev
> Динамический адрес обычно меняется при переподключении к сети провайдера, а не
> пока вы находитесь в сети.
Обычно адрес меняется либо раз в день, либо раз в неделю твоим же роутером. Ну в плане переподключение происходит.
И на роутере провайдера подобная настройка тоже есть и ее дефолтное положение тоже вовсе не бесконечность.
IndieDev
> Динамический адрес обычно меняется при переподключении к сети провайдера, а не
> пока вы находитесь в сети.
Как часто вы переподключаетесь? Если у вас дома стоит свич с натом, он всегда включен, на большинстве из них даже кнопки выключения не предусмотрено.
Zab
>Как часто вы переподключаетесь? Если у вас дома стоит свич с натом, он всегда включен, на большинстве из них даже кнопки выключения не предусмотрено.
Не понял к чему этот вопрос, есть какое-то продолжение после моего ответа?
Я просто связи не уловил, а так частота переподключений моего свича прямо пропорционально
частоте отключения света, в последнее время отключают несколько раз в день по причине "жара",
причина отключения электричества - "жара", Карл. Вчера гроза, сегодня жара, а завтра ветер, а послезавтра, наверное, углекислый газ будет причиной отключения электричества. Это я о наболевшем...
P.S. У меня статический ip
IndieDev
> P.S. У меня статический ip
С этого надо было начинать.
IndieDev
> Не понял к чему этот вопрос, есть какое-то продолжение после моего ответа?
> Я просто связи не уловил, а так частота переподключений моего свича прямо
> пропорционально
Сеансовый адрес выдается твоему домашнему хабу, а не твоему компу. Пока хаб включен, сеанс продолжается и адрес не обновляется с твоей стороны. Сервер обновляет периодически, везде с разной частотой, чаще всего раз в сутки. Бывает и чаще. Бывает что и не меняет тебе адрес, изыскивает возможность выдать тебе тот, которым ты пользовался в последний раз.
Хаб может не перезагружаться по полгода, если не больше.
Если адрес вдруг решил смениться, на это надо в игровом проекте корректно реагировать. А вдруг там юзер в этом момент в каком-нибудь коллективном бою увяз... Нельзя его просто так выкидывать.
Статический IP, это конечно хорошо, но у большинства он ни разу не статический.
Zab
> Если адрес вдруг решил смениться, на это надо в игровом проекте корректно
> реагировать. А вдруг там юзер в этом момент в каком-нибудь коллективном бою
> увяз... Нельзя его просто так выкидывать.
Большая часть проектов просто выкидывает. Как говорится - пускай юзер сам следит за тем когда у него там IP меняется.
Выкидывать или не выкидывать - это уже вопрос не к сетям опять же, а к архитектуре клиента и сервера.
Я могу спокойно использовать любой протокол и реализовать так, что если клиент отключился, то его персонажа удаляло с игры через N времени, если он успеет к этому моменту переподключиться, то по его уникальному идентификатору я могу найти его сессию на сервере авторизации к примеру.
В качестве идентификатора для сессии может вон хеш из IP получить или из данных железа.
IndieDev
> для сессии может вон хеш из IP получить
а ты молодец, тут уже вторую страницу талдычат что IP может поменяться прямо на лету
> или из данных железа
или коли способ получения MAC
ради экономии места в пакете можно вместо идентификатора сессии слать его хэш (пусть даже однобайтовый). идентифицировать пользователя по порту/айпи и валидировать по этому хэшу. если хэш не прошел валидацию - либо шлем лесом, либо, если это слишком частый кейс - запрашиваем реаутентификацию, в рамках которой клиент разово пришлет полный старый айди сессии с которым и восстанавливаем ассоциацию.
Играет такой челик в игру, получил лут за 50к реала и тут хакерман подключается с таким же маком. Вот это поворот будет. Эксперты по сетевым технологиям такие эксперты.
Dampire
> Играет такой челик в игру, получил лут за 50к реала и тут хакерман подключается
> с таким же маком. Вот это поворот будет. Эксперты по сетевым технологиям такие
> эксперты.
Какой ужас. Ну F этому игроку получившему лут за 50к реала. Ты не банк. Да и вообще
если злоумышленник узнал мак адрес, а не ип кого-то из твоих игроков, смог его выбить из сети,
то проблема вовсе не в механизме автореконнекта.
Dampire
вопрос баланса между производительностью и безопасностью в играх часто решается в сторону производительности, а потерпевшие прекрасно обрабатываются суппортом (не банк же).
> Эксперты по сетевым технологиям такие эксперты.
расскажи, коли есть что. скептически сотрясать воздух каждый может.