Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Толстый/тонкий сервер. Синхронизация состояние мира. Какие минусы видите в такой реализации? (10 стр)

Толстый/тонкий сервер. Синхронизация состояние мира. Какие минусы видите в такой реализации? (10 стр)

Поделиться
Advanced: Тема повышенной сложности или важная.

Страницы: 1 2 3 4 ... 9 10 11 12 Следующая

i2um1Постоялецwww6 окт. 20162:10#135
tac
> Ждать игрокам ничего не надо, просто будет ситуация, когда ему показалось, что он взял камень, но окажется что камень он не взял.
Он взял камень и повис до ответа сервера, так как что было потом пока неизвестно и надо подождать другого игрока.
tacПостоялецwww6 окт. 20162:12#136
MrShoor
> Какая разница есть он или нет
А может начать с того, чтобы прочитать и понять что именно предлагается, и не пороть чушь основываясь на то, что сам придумал?
tacПостоялецwww6 окт. 20162:12#137
i2um1
> Он взял камень и повис до ответа сервера
ешкин кот, НЕТ! еще попытка ? сервер не отвечает !!
i2um1Постоялецwww6 окт. 20162:15#138
tac
> ешкин кот, НЕТ! еще попытка ? сервер не отвечает !!
Если сервер не отвечает, то и игры нет. Логи-то на сервере.

tac
> лучшие?

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

Автор этой темы называет это "толстым" сервером.

tac
> и не пороть чушь основываясь на то, что сам придумал?
Могу скинуть цитаты более двух людей в этой теме, которые говорят об одном и том же.

Правка: 6 окт. 2016 2:16

tacПостоялецwww6 окт. 20162:16#139
i2um1
> так как что было потом пока неизвестно и надо подождать другого игрока.

MrShoor
> И тут с какого-то тормознутого клиента приходит инфа, о том, что оказывается
> это не ты камень взял


стоп, я понял, есть другая ситуация обратная той которую я описал .... ну господа, вы объяснять не мастера ( сча подумаем ..

tacПостоялецwww6 окт. 20162:18#140
i2um1
> Если сервер не отвечает
не в том смысле не отвечает, клиент его в обсуждаемом случае ничего не спрашивает
i2um1Постоялецwww6 окт. 20162:20#141
tac
> не в том смысле не отвечает, клиент его в обсуждаемом случае ничего не спрашивает
Я разницы не вижу.

tac
> сча подумаем ..
Еще хотелось бы получить ответ на
Как определить за какой период времени необходимо клиенту отправлять логи о текущем состоянии игрового мире? Ведь игрок мог не появляться в мире день, неделю, месяц, а может даже год.
Как долго сервер вынужден хранить логи о текущем состоянии игрового мира?
Поддержка горизонтальной и вертикальной масштабируемости?

Правка: 6 окт. 2016 2:25

tacПостоялецwww6 окт. 20162:29#142
tac
> стоп, я понял, есть другая ситуация обратная той которую я описал

впрочем, она решается аналогично, только визуальный эффект другой ..

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

и хочу заметить что разницы между тем есть авторитарный сервер или нет - никакой, по-крайней мере в том смысле как предложено в моем смешанном решении.

tacПостоялецwww6 окт. 20162:32#143
i2um1
> Как определить за какой период времени необходимо клиенту отправлять логи о
> текущем состоянии игрового мире? Ведь игрок мог не появляться в мире день,
> неделю, месяц, а может даже год.
> Как долго сервер вынужден хранить логи о текущем состоянии игрового мира?
а это совершенно не понятно. В каком это случае? Подключаясь он сам запрашивает и указывает с какого времени ему интересно. А потом пока в сети. А серверу ничего хранить и не надо, кроме последнего состояния
tacПостоялецwww6 окт. 20162:35#144
i2um1
> Могу скинуть цитаты более двух людей в этой теме, которые говорят об одном и том же.
хоть папы римского, чушь повторенная многократно остается чушью
i2um1Постоялецwww6 окт. 20162:35#145
tac
> но фактических ошибок не будет.
Ошибки в логах будут и не всегда возможно правильно восстановить состояние мира по ним, даже если делать какие-нибудь гипотезы, допущения, коррективыкостыли.

tac
> авторитарный сервер
Он же был у меня изначально, потом убрал, снова вернул, а вопрос свой так и не поменял.

tac
> чушь повторенная многократно остается чушью
Мудрые учатся на чужих ошибках, умные учатся на своих ошибках, а дураки не замечают своих ошибок.

tac
> Подключаясь он сам запрашивает и указывает с какого времени ему интересно.
Будем логи за весь год отправлять? А их ох как много.

tac
> А серверу ничего хранить и не надо, кроме последнего состояния
Сервер же логи хранит, а не состояние. Отдает логи клиентам, а они их парсят и применяют. У нас же "тонкий" сервер, который ничего не делает, только хранит. И вообще, как мы тут выяснили, его можно спокойно удалить и ничего не изменится.
Вот только какой-то лог мог еще не успеть сохраниться, например, один маленький лог об уничтожении мира и потеряться, потому что клиенту больше об этом никто не скажет, мир-то уничтожен.

Правка: 6 окт. 2016 2:50

tacПостоялецwww6 окт. 20162:54#146
tac
> Есть два камня которые лежат перед двумя игроками А и Б в сети. Каждый из них
> условно одновременно (т.к. в реальности микросекунды будут отличаться) берет
> камень. Если они берут разные камни, то проблемы не возникает. Если они берут
> один и тот же камень, что происходит? "А" берет все таки чуть раньше, но у "Б"
> он все еще лежит перед носом и его клиент позволяет его взять, а секундой позже
> приходит сообщение, что этот камень взял "А". А т.к. клиент игрока "Б" не успел
> обработать ситуацию, то и "A" приходит сообщение, что камень взял "Б". Чтобы
> еще конкретнее распишем по времени. Канал между А и Б проходится за 3 сек. в
> одну сторону (от А к серверу 1 сек., и от сервера к Б 2 сек.), в момент времени
>
> 101 - камень берет A
> 102 - камень берет Б
> 103
> 104 - Б получает сообщение, что камень взял А (чуть позже 104.1 Б видит, как
> камень из его руки, попадает в руку А)
> 105 - А получает сообщение, что камень взял Б (чуть позже 105.2 А видит, как
> камень из его руки, попадает в руку Б)
>
>
> Если клиенты игроков ничего не будут делать (а помним, что сервер не
> вмешивается), то Б будет думать, что камень у А, а А будет думать, что камень у
> Б. И никто из них не сможет его использовать, пока не перезагрузится, но и
> тогда на сервере останется последние сообщение про камень  гласит, что камень у
> Б.

Решение.

101 - камень берет A
102 - камень берет Б; Сервер помещает в элемент массива состояние камня измененное клиентом A и запирает к нему доступ
103
104 - Б получает сообщение, что камень взял А (чуть позже 104.1 Б видит, как камень из его руки, попадает в руку А); Сервер пробует поместить в элемент массива состояние камня измененное клиентом Б, но видит что доступ закрыт. Проверяет был ли оповещен Б, что камень взял А, понимает, что нет и игнорирует сообщение от Б. Повторно отправляет A, состояние камня измененное им.
105 - А получает сообщение, что камень взял Б (чуть позже 105.2 А видит, как камень из его руки, попадает в руку Б). А получает от сервера приоритетное сообщение, что камень остается у него. (чуть позже 105.5 А видит, как камень из руки Б, бежит обратно к нему)

Правка: 6 окт. 2016 3:02

tacПостоялецwww6 окт. 20162:59#147
i2um1
> Будем логи за весь год отправлять? А их ох как много.
я устал вас возвращать к написанному о моем решении
Такой подход, только в самом худшем случае, когда за время отсутствия игрока случилось так, что другие игроки изменили ВСЕ объекты, будет получать состояния всех объектов, а как правило будет получать информацию лишь об измененных объектах, что ускоряет начальную загрузку состояния игрового мира.


i2um1
> Сервер же логи хранит, а не состояние. Отдает логи клиентам, а они их парсят и
> применяют. У нас же "тонкий" сервер, который ничего не делает, только хранит. И
> вообще, как мы тут выяснили, его можно спокойно удалить и ничего не изменится.

а от того, что вы продолжаете писать глупости, не имеющие отношения к моему решению, суть его не меняется. Сервер давно уже хранит состояние объекта, которое он просто не разбирает, и не анализирует. И отдает он то, что послал другой клиент - тоже состояние. Вы запутались окончательно.

i2um1Постоялецwww6 окт. 20163:16#148
Итого:
1. Сервер хранит состояния объектов, а не логи. Отдает только нужную информацию, запрашиваемую клиентом, который как-то ее узнает, не зная весь мир. Однако по непонятному критерию клиент определяет, когда ему вдруг надо запросить состояние всего мира.
2. Все сообщения проходят через сервер, а не peer-to-peer, потому что пункт 3.
3. Сервер контролирует целостность данных выдавая эксклюзивный доступ к ресурсу = разбирает и анализирует состояние объекта.
4. Спустя некоторое время клиенты с неправильным состоянием исправляют его без всяких объяснений игроку. Всякие телепорты, откаты назад во времени и другие прелести путешествия во времени.

tac
> Вы запутались окончательно.
Мне интересны минусы тонкого/толстого сервера в общем случае, не привязываясь к конкретной специфической ситуации. Такая система должна уметь решать очевидные проблемы синхронизации данных. Потому что зная общее решение проблемы глобально, я могу легко применить его к частной проблеме.

tac
> не имеющие отношения к моему решению
Я вроде первым же постом дал понять, что меня интересует сферический конь в вакууме. И это имеет прямое отношение к решению, потому что мы, как я понял, пытаемся выяснить какой такой велосипед соорудить из "тонкого" сервера, только чтобы не использовать "толстый" сервер.

Правка: 6 окт. 2016 3:19

tacПостоялецwww6 окт. 20163:24#149
i2um1
> Итого:
> 1. Сервер хранит состояния объектов, а не логи.
да (написал вчера, позавчера было не так)
> 2. Все сообщения проходят через сервер, а не peer-to-peer
да (так было изначально)
> 3. Сервер контролирует целостность данных выдавая эксклюзивный доступ к ресурсу
да (решено сегодня)
> - разбирает и анализирует состояние объекта.
нет (иначе это станет авторитарный сервер по определению)
> 4. Спустя некоторое время клиенты с неправильным состоянием исправляют его без
всяких объяснений игроку. Всякие телепорты, откаты назад во времени и другие прелести путешествия во времени.

да, предложения? Игроку можно выкинуть фразу "Бл.., временной косяк. Хорошо бы обзавестись стабильным подключением."


> Однако по непонятному критерию определяет, когда надо писать логи и отдавать логи вместо состояний.
Я не понимаю, что вы называете логами, поэтому не могу это прокомментировать.

Правка: 6 окт. 2016 3:32

Страницы: 1 2 3 4 ... 9 10 11 12 Следующая

/ Форум / Программирование игр / Сеть

2001—2017 © GameDev.ru — Разработка игр