информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Spanning Tree Protocol: недокументированное применениеСтрашный баг в WindowsПортрет посетителя
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Ростелеком заподозрили в попытке... 
 Линуксовый ботнет, распространяющийся... 
 Конец поддержки Internet Explorer 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / theory
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
"В отличие от web, online игра должна реагировать очень... 29.10.08 18:25  Число просмотров: 4555
Автор: Vedrus <Serokhvostov Anton> Статус: Member
<"чистая" ссылка>
"В отличие от web, online игра должна реагировать очень быстро. А пока клиент прочухается, пока отошлет запрос, пока сервер отработает пол миллиона запросов - ты, как игрок, уснешь перед монитором.
Как вариант: избавится от логики запросов. "
Может есть, что почитать по этому поводу? Я так понял, нужно игнорируя Apache свой сервер писать и ставить в идеале?
<theory>
Синхронизация в многопользовательских онлайн играх 29.10.08 09:53  
Автор: Vedrus <Serokhvostov Anton> Статус: Member
<"чистая" ссылка>
Пытаюсь разобраться вот с какой вещью. Например, есть 3D сцена, по которой гуляют несколько человек (зарегистрированных пользователей), в том числе я.

Со мной понятно: когда я нажимаю на клавиатуру или мышь данные передаются серверу и он фиксирует моё перемещение. А как быть с другими пользователями, чтобы на моём компе их перемещения тоже отображались?

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

Как можно решить такую проблему более цивилизованно?
Всем спасибо за много информации. Буду вникать. 30.10.08 02:24  
Автор: Vedrus <Serokhvostov Anton> Статус: Member
<"чистая" ссылка>
Скорее не опрос, а push 29.10.08 17:45  
Автор: PS <PS> Статус: Elderman
<"чистая" ссылка>
> Со мной понятно: когда я нажимаю на клавиатуру или мышь
> данные передаются серверу и он фиксирует моё перемещение. А
> как быть с другими пользователями, чтобы на моём компе их
> перемещения тоже отображались?
>
> То, что придумал я – это несколько раз в секунду опрашивать
> сервер о текущем состоянии сцены и на основе полученных
> данных прорисовывать сцену. Но такой вариант трафика и
> других ресурсов очень много жрать будет.
>

При действии пользователя данные отсылаются серверу. Сервер рассылает их всем подписчикам (другим пользователям).
Клиент умный. Клиент умеет вычислять возможную точку находжения объектов в последующие моменты времени.
Например от пользователя не передается информация о точке нахождения, а передается информация о действии. Я нахожусь там то и там то, и начал бежать на северо-восток, с такой-то скоростью. Все.
Все остальные клиенты начинают вычислять где этот перец сейчас может находится.

А вообще, самый простой способ разобраться - поставить любую online игру и проанализировать снятый сниффером траффик.
Боюсь, снифить трафик бесполезно. Высоковероятно - данные криптуются для защиты от читеров. 29.10.08 19:45  
Автор: Garick <Yuriy> Статус: Elderman
<"чистая" ссылка>
Ну, всегда можно попробовать... 30.10.08 19:07  
Автор: Fighter <Vladimir> Статус: Elderman
<"чистая" ссылка>
"Сервер рассылает их всем подписчикам (другим... 29.10.08 17:48  
Автор: Vedrus <Serokhvostov Anton> Статус: Member
Отредактировано 29.10.08 17:51  Количество правок: 1
<"чистая" ссылка>
"Сервер рассылает их всем подписчикам (другим пользователям)"
А про это можно поподробнее? Я всегда думал, что сервер инициативу не проявляет, а только по запросу клиента всё делает.

ЗЫ. Мне кажется не факт, что в игре, которая мне попадётся будет оптимальный алгоритм передачи данных.
Это как вариант 29.10.08 18:11  
Автор: PS <PS> Статус: Elderman
<"чистая" ссылка>
> "Сервер рассылает их всем подписчикам (другим
> пользователям)"
> А про это можно поподробнее? Я всегда думал, что сервер
> инициативу не проявляет, а только по запросу клиента всё
> делает.
>
> ЗЫ. Мне кажется не факт, что в игре, которая мне попадётся
> будет оптимальный алгоритм передачи данных.

В отличие от web, online игра должна реагировать очень быстро. А пока клиент прочухается, пока отошлет запрос, пока сервер отработает пол миллиона запросов - ты, как игрок, уснешь перед монитором.
Как вариант: избавится от логики запросов. Клиенту все равно нужны свежие данные (иначе смысла в игре нет), так зачем от него ждать запросов? Можно при появлении обновлений в контексте - сразу поставлять их клиенту.
При этом сервер может даже не отслеживать положении игроков, или отслеживать их на отдельном сервере не в рилтайм режиме, с целью выискивания читтеров.
Например, если ты подменяешь стандартный игровой клиент своей чит-программой, которая игнорирует карту, и проходишь сквозь стены, летаешь по воздуху и т.д., то тебя засекут не сразу, а скажем, через пол часика. Это такой компромисный вариант между функциональностью и скорострельностью серверной части.
Как конкретно реализована каждая игра - можно разобраться по траффику.
Пусть сервак все рассылает без запросов. 30.10.08 14:36  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 30.10.08 14:36  Количество правок: 1
<"чистая" ссылка>
> Как вариант: избавится от логики запросов.

Пусть сервак все рассылает без запросов.

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

Чтоб такого не было - вся игра идет на серваке, а клиенты посылают серваку сигналы управления (нажатия на кнопки и движения мышки). Сервак рассылает всем координаты и положения всех игроков и прочих подвижных предметов, которые находятся в пределах видимости.
Не соглашусь с последним утверждением 31.10.08 11:35  
Автор: PS <PS> Статус: Elderman
<"чистая" ссылка>
> Чтоб такого не было - вся игра идет на серваке, а клиенты
> посылают серваку сигналы управления (нажатия на кнопки и
> движения мышки). Сервак рассылает всем координаты и
> положения всех игроков и прочих подвижных предметов,
> которые находятся в пределах видимости.

Пусть у тебя играют 500000 человек. Количество зон в игре не важно, т.к. все зоны в пределах сервера обрабатываются одной машиной. Кроме людей есть еще мобы и игровые предметы. Количество мобов примем три на человека.
Если ты решишь рассылать координаты всех подвижных участников игры: игроков и мобов, то тебе придется в рил-тайм обсчитывать полтора миллиона объектов. Причем не только их положение, но и зону видимости пол миллиона людей.
Ничего не настораживает ?
Эта какая игра сейчас позволяет иметь полмиллиона участников в одном мире? [upd] 31.10.08 20:05  
Автор: amirul <Serge> Статус: The Elderman
Отредактировано 31.10.08 20:12  Количество правок: 1
<"чистая" ссылка>
> Пусть у тебя играют 500000 человек. Количество зон в игре
> не важно, т.к. все зоны в пределах сервера обрабатываются
> одной машиной. Кроме людей есть еще мобы и игровые
Нет, не одной. Вполне можно сделать распределенную считалку с синхронизацией на швах.

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

Зону видимости можно только прикинуть - вместо обычной метрики sqrt(x^2 + y^2 + x^2) можно использовать метрикуx+y+z

> Ничего не настораживает ?
Ничего. Полтора миллиона объектов на сцене - вполне сопоставимо с числом полигонов в одном фрейме современной игрушки. Обсчитываются легко - рисовать то ничего не надо.

----------------------
Вот здесь http://en.wikipedia.org/wiki/Comparison_of_MMORPGs пишут о нагрузке примерно 36к игроков на один сервер в WoW. И это не тот результат, которого когда либо сможет достичь синглдевелопер. Так что ориентироваться нужно в лучшем случае на 1-2к
Написание в расчете на 5, 50 и 500000 игроков должно иметь несколько... 31.10.08 15:52  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 31.10.08 15:54  Количество правок: 3
<"чистая" ссылка>
> Пусть у тебя играют 500000 человек. Количество зон в игре

Написание в расчете на 5, 50 и 500000 игроков должно иметь несколько разный подход.
Когда народа много (сомневаюсь, что активных плееров у Ведруса в игрушке достигет поллимона, но отрицать тоже нельзя), можно раскидывать народ по сервакам. Не обязательно всем в одной сцене/эпизоде/уровне участвовать.

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

Все зависит от узкого места. Если это вычислялка, а сетка сверхскоростная (80386 на гигабитке), то да, а если наоборот (многопроцовый многоядровый Коре2 на мегабитном интернете), то придется стараться уменьшать трафик.
Настораживает 31.10.08 13:08  
Автор: Heller <Heller> Статус: Elderman
<"чистая" ссылка>
> Пусть у тебя играют 500000 человек. Количество зон в игре
> не важно, т.к. все зоны в пределах сервера обрабатываются
> одной машиной. Кроме людей есть еще мобы и игровые
> предметы. Количество мобов примем три на человека.
> Если ты решишь рассылать координаты всех подвижных
> участников игры: игроков и мобов, то тебе придется в
> рил-тайм обсчитывать полтора миллиона объектов. Причем не
> только их положение, но и зону видимости пол миллиона
> людей.
> Ничего не настораживает ?
Отправлять надо только то, что для конкретного клиента актуально. Однако настораживает меня именно твой вариант, а не DPP. Если пользователь будет сам сообщать какую информацию ему отдать, появляется широкое поле для читерства. Все равно решать что кому отдать должен сервер.
Проблема читерства может быть решена другими способами 31.10.08 13:32  
Автор: PS <PS> Статус: Elderman
<"чистая" ссылка>
> Отправлять надо только то, что для конкретного клиента
> актуально. Однако настораживает меня именно твой вариант, а
> не DPP. Если пользователь будет сам сообщать какую
> информацию ему отдать, появляется широкое поле для
> читерства. Все равно решать что кому отдать должен сервер.

Повторю еще раз: пол миллиона человек в online - высчитывать что для каждого из них актуально, а что нет - физически не возможно.
Проблема читерства может быть решена другим способом: есть back сервер, на котором неспешно проверяются команды и состояния игроков. Сервера загружены не постоянно, в ночное время, и рабочее дневное - количество игроков много меньше чем с 18 до 24 по москве. Значит именно в ночное время back сервер будет "догонять" текущую ситуацию. При обнаружение читеров back просто блокирует данный аккаунт. Все читерские последствия отменяются (если возможно). Например из счетчика побед игроков, с которым сражался читер - исключаются поражения, связаные с этим читером.
Так же в игре может быть предусмотрена команда: "Пожаловаться на читера".
Ну и напоследок - не совсем прозрачные протоколы между клиентом и сервером (это так, от школьников).

P.S. Такой алгоритм работы возможен для широкомаштабных игр, в которых люди проводят месяца или года (вряд ли кто пойдет ради выиграша одного двух боев на риск потерять персонажа на которого затрачено пол года сидения перед монитором). И совсем не подходит для локальных стрелялок (ну забанили твой аккаунт - завел новый и перестрелял всех). Однако в локальных стрелялках нет полу-миллионой аудитории :) А за 20ю человеками может и front последить в рил-тайме.
Не вижу сложностей 31.10.08 15:11  
Автор: Heller <Heller> Статус: Elderman
<"чистая" ссылка>
> Повторю еще раз: пол миллиона человек в online -
> высчитывать что для каждого из них актуально, а что нет -
> физически не возможно.
По-моему вполне возможно, главное грамотно локализовать данные (кластеризовать игроков или не знаю как правильнее сказать). Грубо говоря у тебя есть много локаций, и когда кто-то совершает некое действие, оно рассылается всем в пределах данной локации. Где сложности? А вот механизм с запрашиванием новых данных от сервера мне выглядит более трудоемким, причем ничем не упрощающим реализацию.

Мне моя реализация видится так:
Сервер - Игрок A двинулся в сектор Б.
Клиент - Ок, понял.
Сервер - Игрое Б замочил игрока Ц.
Клиент - Ок, понял.

Кому рассылать данные клиент решает просто пробегая по вектору игроков локации.

Твоя реализация:
Клиент - Ну че там, есть нового чо?
Сервер - Не-а, нету :-(
Клиент - Ну че там, есть нового чо?
Сервер - Не-а, нету :-(
Клиент - Ну че там, есть нового чо?
Сервер - Да, А двинулся в Б, Б замочил Ц.
Клиент - Ок, понял.
Клиент - Ну че там, есть нового чо?

Для реалтаймовой игрушки не особо скоростной подход получается даже на пальцах.
Я уже ничего не понимаю, споришь ты со мной или соглашаешся... 01.11.08 13:37  
Автор: PS <PS> Статус: Elderman
<"чистая" ссылка>
> > Повторю еще раз: пол миллиона человек в online -
> > высчитывать что для каждого из них актуально, а что
> нет -
> > физически не возможно.
> По-моему вполне возможно, главное грамотно локализовать
> данные (кластеризовать игроков или не знаю как правильнее
> сказать). Грубо говоря у тебя есть много локаций, и когда
> кто-то совершает некое действие, оно рассылается всем в
> пределах данной локации. Где сложности? А вот механизм с
> запрашиванием новых данных от сервера мне выглядит более
> трудоемким, причем ничем не упрощающим реализацию.

Я об этом и говорю - действие рассылается всем (в пределах локации, зоны, класстера - это все оптимизация траффика).

Спор тут затевается о другом.
Мое утверждение: front не должен следить за ПРАВИЛАМИ.
Утверждение противоположной стороны: front должен рассылать данные только после необходимых проверок в их валидности.

P.S. Опять же оговорюсь, что следует иметь ввиду масштаб игры.
Можно и без подтверждения. Сам сетевой протокол... 31.10.08 16:01  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 31.10.08 16:03  Количество правок: 3
<"чистая" ссылка>
> Мне моя реализация видится так:
> Сервер - Игрок A двинулся в сектор Б.
> Клиент - Ок, понял.
> Сервер - Игрое Б замочил игрока Ц.
> Клиент - Ок, понял.

Можно и без подтверждения. Сам сетевой протокол подразумевает гарантированность доставки.
Сервер - Игрок A двинулся в сектор Б.
Сервер - Игрое Б замочил игрока Ц.

> Твоя реализация:
> Клиент - Ну че там, есть нового чо?
> Сервер - Не-а, нету :-(
> Клиент - Ну че там, есть нового чо?
> Сервер - Не-а, нету :-(
> Клиент - Ну че там, есть нового чо?
> Сервер - Да, А двинулся в Б, Б замочил Ц.
> Клиент - Ок, понял.
> Клиент - Ну че там, есть нового чо?

А здесь без запросов нельзя. Хотя зачем они нужны, если на них все равно идет ответ "Не-а, нету :-(". Зачем пустой инфой каналы забивать. Ее же все равно еще и обрабатывать надо. Хочется своевременно получать инфу - надо пулить с бешенной частотой, но своевременность получения "по прерыванию" будет всегда своевременнее чем "по запросу".
Лучше взять простенькую open source online multiplayer игру... 29.10.08 20:12  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Как конкретно реализована каждая игра - можно разобраться
> по траффику.
Лучше взять простенькую open source online multiplayer игру и смотреть как это сделано у них. Первое, что пришло в голову:
http://teeworlds.com/

Очень хорошо модуляризовано, во всяком случае моды клепать довольно легко (сам я делал инстагиб, менял характеристики респавна и пр.), так что найти реализацию клиент-серверного протокола не составит труда. Игра довольно динамична, так что требования к протоколу жесткие.
"В отличие от web, online игра должна реагировать очень... 29.10.08 18:25  
Автор: Vedrus <Serokhvostov Anton> Статус: Member
<"чистая" ссылка>
"В отличие от web, online игра должна реагировать очень быстро. А пока клиент прочухается, пока отошлет запрос, пока сервер отработает пол миллиона запросов - ты, как игрок, уснешь перед монитором.
Как вариант: избавится от логики запросов. "
Может есть, что почитать по этому поводу? Я так понял, нужно игнорируя Apache свой сервер писать и ставить в идеале?
А что тут еще можно придумать... Можно еще учитывать вектор... 29.10.08 17:03  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
> То, что придумал я – это несколько раз в секунду опрашивать
> сервер о текущем состоянии сцены и на основе полученных

А что тут еще можно придумать... Можно еще учитывать вектор скорости - величину и направление. Время так же надо синхронизировать. Это чтоб побороть латентность канала.

> данных прорисовывать сцену. Но такой вариант трафика и
> других ресурсов очень много жрать будет.

Какой трафик, какие ресурсы, десяток байт на опрос, десять опросов в секунду, сотня байт в секунду, килобит в секунду, да хоть в десять раз больше - десять килобит, такой трафик любой модем на коммутируемых линиях потянет.
Ну оптимизация всё равно не повредит. 10 байт это на один движущийся объект. А если их сотня в одной сцене движется. Да и сервер наверно загудит, если 10 раз в секунду запросы к БД отсылать. Или я не прав? 29.10.08 17:50  
Автор: Vedrus <Serokhvostov Anton> Статус: Member
Отредактировано 29.10.08 18:03  Количество правок: 1
<"чистая" ссылка>
1  |  2 >>  »  




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2022 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach