SITE LOGO
[ Новые сообщения · Участники · Правила форума · Поиск · RSS ]
Страница 1 из 11
Форум » Counter Strike » Серверы » Клиент-сервер в HL и Counter-strike
Клиент-сервер в HL и Counter-strike
Сатурн22Дата: Вторник, 03.03.2009, 11:21 | Сообщение # 1
Группа: Удаленные





Вот какие моменты будут затронуты в данной статье: Коммуникации клиент-сервер Вопросы ширины канала Вопросцы задержки Настройка сетевых переменных Различные нюансы поведения клиента Коммуникации клиент-сервер Клиент - программа Half-life используемая игроком для подключения к серверу. Сервер Half-Life - центральная программа, к которой могут подключаться клиенты для игры в Half-Life и его модификации, например Counter-Strike. Клиенты не общаются друг с другом, лишь с сервером. Сервер следит за тем, что делаеткаждый клиент и как они влияют друг на друга и сообщает клиентам то, что им необходимознать. Если представить картину схематично, то мы получим что-то вроде звезды, с сервером в середине и расходящимися от него соединениями к клиентам в виде лучей. При общениисервера с клиентом используются два главных понятия - ширина канала (bandwidth) и задержка (latency).

В идеальном мире, общение клиент-сервер должно быть мгновенным, не должно быть никаких ограничений по количеству передаваемых данных и сама передача обязана быть моментальной. В итоге, клиент всегда имел бы ту же информацию о происходящем, что и сервер. В реальности, существует предел данных, которые можно передать между клиентом и сервером за секунду - ширина канала и время, за которое эти данные передаются - задержка. Ограничение ширины канала происходит 2-мя способами. - Во-первых, на сервере выставляется настройка, ограничивающая наибольшее значениеширины канала, которое сервер может использовать для общения с одним клиентом. Врезультате, даже если клиент соединяется через выделенный канал либо xDSL, пропускнаяспособность которого не меньше 64 килобайт в секунду, сервер всеравно будет передаватьсо скоростью не более чем 8 кб в секунду (стандартное значение, которое однакоможет меняться в зависимости от сервера). Это - ограничение со стороны сервера.

Это делается поэтому, что большое количество "высокоскоростных" клиентов "съедят" слишкомбольшой объем трафика, за который соответственно нужно платить. Выставление болеевысокого лимита имеет легко предсказуемые денежные последствия. - Во-вторых, клиенты с менее скоростным соединением (56k модемы) обычно не имеютдостаточной ширины канала для заслуги максимума, выставленного на сервере. В данномслучае работает ограничение со стороны клиента. Задержка в основном зависит от типа соединения клиента (56k модем, ISDN, xDSL и т.д.).Чем больше задержка, тем больше времени требуется для передачи данных. Чем меньшезадержка, тем лучше. Тип соединения Ширина канала Задержка 56k модем Низкая Высокая ISDN Низкая Низкая xDSL Высокая Низкая Спутник Высокая Высокая Заметьте, что задержканикак не зависит от ширины канала. Именно потому напримеродноканальный ISDN имеет ту же задержку, что и двухканальный ISDN, а спутниковый канал -хотя и способен передавать мегабайты в секунду - бесполезен для игр в реальном временииз-за задержки в районе 2000 миллисекунд (ms).

Вопросцы ширины канала Основная проблема с тем, что послан может быть лишь конечный объем данных состоит в том, что если в какой то момент происходит столько событий, что сервер обязан послать больше данных, чем клиент способен принять, чем-то придется пожертвовать. Что произойдет если какие то данные - потенциально критичные данные, к примеру выстрел игрока - просто не были посланы? Представьте себе игрока с модемом 56k. В данном случае скорость передачи от клиента ксерверу составляет 3 килобайта в секунду, а от сервера к клиенту - 5 кб в секунду(большинство типов соединения имеют асинхронны, то есть в одном направлении могутпередавать скорее чем в другом). Для начала наш игрок ходит в пустой части карты. ничего особенного не происходит, кромесмены его позиции и клиент передаетминимум данных серверу - грубо говоря 1 кб всекунду. Соответственно и серверу нечего сообщать клиенту, как рядом с ним ничего непроисходит.

 
Сатурн22Дата: Вторник, 03.03.2009, 13:37 | Сообщение # 2
Группа: Удаленные





Сейчас наш игрок сворачивает за угол и оказывается в самом центре боя. Неожиданно егоклиент должен получить множество инфы - вокруг много игроков, много выстрелов,гранаты летают и т.д. Сервер начинает усиленно передавать и в какой то момент долженпослать 10 килобайт данных в секунду, однако наш клиент может принять только 5. Чтопроисходит в итоге? Сервер просто не может передать полные 10 килобайт и долженвыбрать, какие 5 отбросить, а какие 5 все же послать. Как вы можете себе представить - Это Не Есть Отлично. Как именно это делается относится к тому, как конкретно организовано общение. Если честно, сервер может отбросить достаточно много данных ничего в действительности, не испортив для клиента. Игры в реальном времени протекают очень похоже на кинофильм - чем чаще обновляетсяэкран,тем реалистичнее смотрится кино. В данном случае вместо кадров выступает количествообновлений инфы, которую клиент имеет о происходящем вокруг.

Представьте что сервер сообщает клиенту о происходящем лишь раз в 5 секунд. Клиентбудет видеть, как игроки перескакивают на большие расстояния, вообще не будет видетьгранат и вероятно будет умирать так и не увидев противника. Сейчас представим обновление раз в секунду. Улучшение будет значительным - игроки будутдвигаться практически плавно, гранаты будут видны, однако прицеливание будет все равно значительнозатруднено. Теперь вообразим обновление 25 раз в секунду. наш игрок в деле! Клиент обновляетсянастолько частенько, что достигается почти полная иллюзия естественности движения. Но здесь то и кроется конфликт. Чем чаще сервер отправляет обновления, тем большеданных в секунду необходимо передать. Если данных очень много, если их больше чем каналклиента может выдержать, серверначнет отбрасывать данные. Когда это происходит, сервер просто временно уменьшает частоту обновлений. Мир со стороныигрока станет более дискретным, но остается функциональным.

Если напротив, клиент посылает очень много данных серверу, клиент уменьшит частотусвоих обновлений. Важно помнить, что чем больше событий происходит вокруг игрока, тем больше данныхпосылается с каждым обновлением. Потому 35 обновлений в секунду могут работать идеальнона пустынной карте, но начнут "лагать" в бою. Конкретно здесь игрок может приложить свою руку при настройке клиента. Ширина канала -величина фиксированная, однако количество обновлений полностью в руках юзера. Этодает игроку грубый, однако эффективный контроль над количеством посылаемых данных (грубыйпотом, что количество данных, посылаемых за раз не постоянно и контроля над этим упользователя нет). Сетевая настройка в Half-life - это вопросец знания того, какова ширина канала в вашемраспоряжении и вычислениясколько обновлений вы сможете выдержать без нарушений связи вразгар боя. Вопросы задержки Как упомянуто ранее, задержка в соединении является одним из основных факторов, влияющихна процесс общения клиента с сервером.

Основная неувязка такова: Сервер получает от всех клиентов информацию о том что ониделают. Далее сервер непрерывно обновляет состояние мира Counter-Strike на базе этойинформации и сообщает всем клиентам о текущем состоянии. Сейчас предположим что игрок нажал клавишу идти вперед. Через 250ms сервер получает этуинформацию. До этого момента этого движения не существует, так как сервер о нем незнал. Когда сервер узнал о движении, он обновляет позицию игрока и докладывает всем клиентам чтоигрок передвинулся. Еще 250ms спустя все клиенты получают эту информацию и наконец-то видят изменения наэкране. Все отлично, не считая того факта, что игрок был на этой позиции пол секунды назад! То чтокаждый игрок видит на экране - это позиция игрока приблизительно пол секунды назад. Есть ещеодна особенность, которую нужно понимать. Есть разница между тем, чтоделает игрок (в данном случае 500ms назад) и тем, что знает о нем сервер (250ms назад).

 
Сатурн22Дата: Вторник, 03.03.2009, 13:39 | Сообщение # 3
Группа: Удаленные





Когда игрок прицеливается и стреляет значение имеет лишь позиция, о которой знаетсервер, а не позиция, о которой знает клиент, ведь информация об этом еще не дошла досервера. Так что, когда игрок целится и стреляет, он целится в позицию противника, которую тотзанимал 500ms назад с точки зрения этого противника, но только 250 ms назад с точкизрения сервера. Естественно, что если б все было именно так, обычное прицеливание было бы оченьзатруднено. Решение этой трудности достаточно просто. Сервер сохраняет историю передвижений игроковза последние полсекунды либо около того. Когда информация о выстреле достигает сервера,сервер знает сколько она к нему шла (допустим 241ms для данного конкретного выстрела) итакже знает среднюю задержку цели (предположим 70ms). В итоге сервер смотритисториюпозиций по сумме этих двух значений (311ms) и проверяет была ли в момент выстрела цельточно в перекрестии прицела.

Сервер вычисляет как смотрелся мир для стрелявшего игрока в момент выстрела.Если прицел игрока был точен, то он попадет даже беря во внимание что мир с тех пор изменился (а вреальности он поменялся еще до выстрела). Таким образом игроки могут прицеливаться нормально, не вычисляя позиций. Также, это причина, по которой игроки иногда погибают уже после того, как они забежали заугол, где их вроде бы не видно. В них попали до того, как они забежали за угол, однако серверпонял это несколько позднее и еще позднее об этом узнал клиент убитого игрока. Клиент может сам выбирать, хочет ли он использовать историю позиций на сервере (то естьжелает ли он целиться прямо в цель либо предсказывать ее позицию без помощи других). Делается это помощью команды cl_lc. Установленная в 1, онаприказывает клиентуиспользовать историю, при значении 0 - не использовать. Настройка сетевых переменных

Различными параметрами сетевой настройки управляют четыре команды: cl_cmdrate - количество раз в секунду, которые клиент докладывает о своих действиях серверу. Помните, что размер данных, передаваемых за одно обновление зависит от происходящего вокруг. cl_updaterate - количество раз в секунду, которые сервер сообщает о происходящем на карте клиенту. Точно также, чем больше событий происходит, тем больше размер данных за одно обновление. cl_rate - устанавливает ограничение количества байт в секунду, которые клиент может отправить серверу. Это значение необходимо, как сервер не может точно вычислить способности соединения клиента. Значение должно совпадать со скоростью исходящей передачи вашего соединения. rate - устанавливает предел байт в секунду, которые сервер можетпередать клиенту. Со стороны сервера это значение можно ограничить при помощи команды sv_maxrate. Обновления от клиента к серверу обычно содержат совсем мало данных - приблизительно 20 байт.

Обновления от сервера к клиенту сравнительно значительны - от 30 байт на тихих участках картыдо 175 б в бою. Для примера, модем 56k имеет максимальную исходящую ширину канала 33.6k, и входящую - 56k. Эти значения - бит в секунду (то есть 33600 бит в секунду). Однако это - общее значение, а не количество данных, то есть часть из этого употребляется на собственно поддержание соединения и сигнализацию (приблизительно 10 процентов) и только часть может содержать реальные данные. В итоге соединение на 33.6k в реальности может передавать настоящие данные только со скоростью 30.2k, что составляет 3780 б (для тех кто не знает - в одном байте - 8 бит) - и это как раз значение, которому должен приравниваться параметр cl_rate (подразумевается идеальное соединение - если модемная линия низкогосвойства, скорость соответственно падает). Соответственно, идеально соединение на 56k дает нам 56000 бит в секунду. Уменьшаем на 10процентов и получаем 6300 б в секунду. Это и есть нужное на значение rate.

rate приравнивается скорости скачивания умноженной на 0.9 и разделенной на 8 cl_rate равняется скорости закачки умноженной на 0.9 и разделенной на 8 Беря во внимание что клиентам особо нечего сообщать серверу, в общении клиент -> сервер оченьредко появляются проблемы даже на модемах. Отметим, что объем служебной инфы различается в зависимости от типа соединения, ноэто не имеет особого значения для высокоскоростных соединений, т.к. клиент обычно имеет большуюширину канала, чем сервер дозволит ему использовать. Дробные значения cl_rate и rate не оказывают никакого влияния и миф о том, что они улучшаю, что либо - не более чем миф. Как упомянуто выше, обновления от клиента к серверу традиционно очень малы и находятся где то в районе 20 б. На 56k модеме с идеальной линиейдоступны 3780 байт в секунду, так что cl_cmdrate может быть установлен в 189. В Half-life существует ограничение на значение cl_cmdrate равное 60.

 
Сатурн22Дата: Вторник, 03.03.2009, 13:40 | Сообщение # 4
Группа: Удаленные





Обновления от сервера к клиенту содержат больше данных. Большие обновления (к примеру вовремя боя) могут достигать 175 б. Имея 6300 байт в секунду на идеальном 56k соединениимы можем выставить cl_updaterate равным 36. cl_updaterate приравнивается значению rate деленному на 175 cl_cmdrate равняется значению cl_rate деленному на 20 У игроков со высокоскоростными соединениями значения будут отличаться. Во-первых потому, что высокоскоростное соединение обычно отдаёт большую полосу, чем сервер дозволит использовать. Соответственно значения rate и cl_rate нужно выставлять на максимум, чтобы применять весь доступный канал. Максимальное значение для rate и cl_rate равняется 20,000. Вычисление правильных значений cl_cmdrate и cl_updaterate традиционно зависит от конкретногосервера, так как значение sv_maxrate ограничивает доступную ширину канала, и соответственно влияет на число обновлений.

Основная цель - иметь очень возможные значения cl_updaterate и cl_cmdrate, сохраняя при всем этом полное отсутствие "удушья". Различные нюансы поведения клиента Движок Half-life обладает еще несколькими трюками, позволяющими увеличивать ощущениереалистичного окружения без задержек. Когда игрок стреляет, клиент сразу же запускает анимацию орудия, рассчитывает траекториюпули и отрисовывает попадание в объект (miss decal или "промах") там, куда как он думаетпопала пуля - и все это несмотря на факт, что сервер еще даже не знает о выстреле, неговоря уже о том, куда ушла пуля и попала ли она во что либо. Таким образом у игрокасоздается чувство, что окружение реагирует на его выстрелы моментально. Опосля обработки траектории пули и отрисовки попадания, клиент отсылает информациюовыстреле на сервер. Однако клиент не отсылает информацию о траектории пули, лишь тотфакт, что игрок совершил выстрел.

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

И что теперь? Не может же клиент по волшебству поновой построить стекло? Естественно нет.Идея в том, что если клиент думает, что игрок попал куда то, он не делает ничего, кромеотрисовки "промаха" если его можно отрисовать на данном объекте (на стекле напримерможно, а на заложнике нет). Однако есть малеханькое исключение. Если клиент думает, что пуля попала в игрока илизаложника, он проигрывает звук попадания. В результате время от времени вы можете слышать звукпопадания, когда самого попадания не случилось. До версии 1.1.0.6 Half-life, отрисовка "промахов" на клиенте могла намного различаться оттого, что думает сервер, особенно с автоматическими снайперскими винтовками. ПатчHalf-life 1.1.0.8 исправил эту ошибку, сделав траектории клиента и сервера болееблизкими. Ситуация улучшиласьи траектории стали похожи, но они все еще различаются. В заключении. Учитывая что клиент не может отрисовать "промах" на игроке или заложнике,если клиент думает что пуля попала, а сервер думает что промазала, эта пуля просто"исчезнет" - ведь ни попадания, ни промаха не было отрисовано.

 
Форум » Counter Strike » Серверы » Клиент-сервер в HL и Counter-strike
Страница 1 из 11
Поиск:

Copyright MyCorp © 2017