- kkolyan
- Постоялец
Dampire
> В каждом пакете ID вообще не упал
PeerId нужен, скажем ENet шлёт в каждом пакете и даже в открытом виде, и нумерация тупо от нуля до макс подключений
иначе за O(1) ты не поймёшь от кого пакет
> Проблему смены IP решает автоматическое переподключение и решает эту проблему
> ненагруженное клиентское приложение
расскажи как клиент может определить свой внешний IP?
не, я просто не знаю
#!
В реальном проекте так и так придется маршрутизировать данные из пакета. Один лукап в хешмапе мало что сможет изменить, но может ощутимо сократить объем трафика на сервере, если куча мелких пакетов гоняется. Как и везде трейдофф BW/CPU.
Dampire
> В каждом пакете ID вообще не упал. У тебя есть сессия. Все пакеты приходят в рамках сессии. Сессию поддерживает эхо. В эхо можно слать ID, а можно и не слать.
а, понял. тогда мое решение с хэшами хрень, да)
Dampire
> Ноу-хау деревенского разлива изобретаете тут только вы. Если бы вместо бесконечных срачей читали папирусы или хотя бы доклады, то не было бы и всего этого бреда на 14 страниц.
как будто что-то плохое. напомню, здесь бурно обсуждается реализация экшн-баталии 500х500. серьезно ожидал увидеть тут профессионалов? :)
#!
> расскажи как клиент может определить свой внешний IP?
а зачем? просто просто переподключится при дисконнекте.
#!
> расскажи как клиент может определить свой внешний IP?
Например web-реквест к сервису по определению адреса. Зачем ему знать свой IP? 30 секунд сервер не отвечает ни на один эхо, сессия оборвалась, подрубись заново с условным логином-паролем/ClientID/???. Дальше уже логика сервера. Новая сессия, поиск старой по креденшелам, если сервер любезно придержал ее.
kkolyan
> здесь бурно обсуждается реализация экшн-баталии 500х500
Проблема баталий 500x500 не в сетевом протоколе, а в менеджменте видимости. Даже упакованную в 16 бит позицию 15 раз в секунду ни один сервер не сможет обработать и разослать всем.
Dampire
> Проблема баталий 500x500 не в сетевом протоколе, а в менеджменте видимости.
менеджер видимости прошлый век. Надо в группы объединять игроков которые дальше и их позиции передавать
группа+сдвиг, притом сдвиг раз в n фреймов, где n от расстояния зависит.
Super_inoy
Тот же самый менеджмент видимости, только сбоку. RPC через какое количество раз ты будешь отсылать у юнитов в 100 и 1000 метрах от игрока? Видим каждый 3 прокаст в 100 метрах и каждый 10 в 1000? Что будешь делать, если надо не только позиции синхронить, но и ауры и эффекты? Тоже раз 10 кадров, когда мне например нафиг не упало знать о том какая там аура у того эльфа в 100 метрах, которого я даже затаргетить не могу.
Как самый простой и лежащий на поверхности вариант - spatial структура, чтобы сервер не разложился на рассчетах, где каждая ячейка имеет свой тикрейт в зависимости от позиции игрока и уровень детализации сообщений/данных. На дальних синхроним позиции/скорости с тикрейтом раз в пол часа, на ближнем обрабатываем все RPC, максимальный тикрейт и максимальный набор данных. Чем это не менеджемент видимости я хз.
Dampire
> но и ауры и эффекты?
Ауры и эфффекты надо считать на каждом клиенте отдельно, т.е. пересылать надо только применение с длительностью.
Приоритетно, всегда, пропускать то можно только позиции, а не действия. А если потом данные расходятся - логировать и банить.
Super_inoy
> Приоритетно, всегда, пропускать то можно только позиции, а не действия. А если потом данные расходятся - логировать и банить.
Удачки. Как сделаешь потом расскажешь, не прилег ли клиент от объемов расчетов.
Dampire
> 30 секунд сервер не отвечает ни на один эхо, сессия оборвалась, подрубись заново с условным логином
Это проблему не решает, 30 секунд для игры - очень много, все планы игрока уже нарушены, все проиграно, с таким же успехом можно просто выкинуть.
Но ведь адрес может меняться у игрока, но не у сервера. Для сервера вы уж как-нибудь выбьете фиксированный IP.
Если соединение по tcp, оно через 30 секунд отсутствия связи само оборвется, для этого не надо прилагать никаких усилий.
Если по UDP - можете делать что хотите, на ходу подменять адреса на сервере. Обнаруживаете, что пришла какая-то левая посылка, приводите в соответствие. Клиент же постоянно что-то шлет серверу, не будет задержки даже в секунду.
Zab
это да, легендарка упадёт, а поднять её не успеешь, кто-нибудь другой подшакалит
но хоть точно не злодей-хакер
Да фиг с ней, с легендаркой. Ты на 30 секунд завис, не выполняешь свою функцию - пати легла. И это после того, как вы уже 40 минут били какого-нибудь боса.
Dampire
> Один лукап в хешмапе мало что сможет изменить, но может ощутимо сократить объем
> трафика на сервере, если куча мелких пакетов гоняется
о-о-очень ощутимо, засунуть туда идентификатор в 4-8 байт прям бьёт по трафику,
по-моему этот трафик вообще бесплатный
оплачивается только исходящий с сервера
ну конечно lookup в мапу дешевле чем прочитать тот же идентификатор
сейчас склоняюсь к варианту kkolyan, посылать короткий шифрованный id юзера-сессии в каждом пакете, а на несовпадение IP быстро отвечать полным id юзера-сессии и не ждать 30 сек неизвестно чего
Тема в архиве.
