- kkolyan
- Постоялец
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
вопрос баланса между производительностью и безопасностью в играх часто решается в сторону производительности, а потерпевшие прекрасно обрабатываются суппортом (не банк же).
> Эксперты по сетевым технологиям такие эксперты.
расскажи, коли есть что. скептически сотрясать воздух каждый может.
kkolyan
> вопрос баланаса между производительностью и безопасностью в играх часто
> решается в сторону производительности
Производительно в каждом пакете слать ID игрока и обрабатывать миграцию? Ну-ну.
> расскажи, коли есть что. скептически сотрясать воздух каждый может.
Нормальная авторизация, токен сессии и эхо запросы поддерживающие сессию. Автоматическая отправка запроса авторизации со стороны клиента при отсутствии на стороне клиента N секунд эхо/ответа на эхо от сервера. Игнорирование любых пакетов, от неавторизованных адресов кроме запросов авторизации на сервере.
Dampire
резюмирую ты предлагаешь
1. слать полный айдишник сессии в каждом пакете.
2. слать лесом тех, у кого сменился апишник
где тут ноу-хау?
всем и так ясно что если хотелки по траффику позволяют включать в каждый пакет полный токен - то так и надо делать.
всем и так ясно что если можно слать лесом тех у кого свичнулся айпишник - надо слать.
Dampire
> Производительно в каждом пакете слать ID игрока и обрабатывать миграцию? Ну-ну.
да, если делать в лоб, то это уязвимость. не надо делать в лоб :)
kkolyan
Как-то ты печально все резюмируешь.
1. В каждом пакете ID вообще не упал. У тебя есть сессия, у которой есть однозначная метрика - эндпоинт. Все пакеты приходят и маршрутизируются в рамках сессии. Сессию поддерживает эхо. В эхо можно слать ID, а можно и не слать.
2. Проблему смены IP решает автоматическое переподключение и решает эту проблему ненагруженное клиентское приложение, а не нагруженный сервер. Причем безопасно решает.
Ноу-хау тут никаких, так работает большинство нормальных сетевых решений. Ноу-хау деревенского разлива изобретаете тут только вы. Если бы вместо бесконечных срачей читали папирусы или хотя бы доклады, то не было бы и всего этого бреда на 14 страниц.
Тема в архиве.