Все о мультиплеере

[Fox Хороший 2]

Основной автор: Nestyreff

Оформил: Fox (разрешение автора есть)

 

1. Мультиплеер.

 

Для начала нужно понять, что такое мультиплеер, а вернее как он работает. Основная идея в том, чтобы синхронизировать игру нескольких игроков и создать между ними связь.

Когда вы скачиваете игру с мультиплеером, будь то SAMP или Gta V online, cs go, вы скачиваете некий лаунчер, который имеет свою информацию/файлы/скрипты, которые активно будут использоваться в будущем. Все это вместе называется клиент (клиентская часть).

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

Когда мы заходим в игру, наш клиент начинает отправлять пакеты данных на сервер. В этих пакетах содержится некоторая информация, хранящаяся на клиенте, в случае сампа это данные о версии клиента, никнейм, настройки подключения к серверу и ещё кое какая информация.

Когда этот пакет дойдет до сервера, сервер начнет его обрабатывать, тут же срабатывает каллбэк OnPlayerConnect. В общем-то само понятие "присоединиться к игре" это отправить пакет на сервер и начать получать обратные.

Как только наш клиент получает ответный от сервера пакет, нам отправляется сообщение(в случае сампа): "Connected. Joining the Game...". После этого сообщения, сервер начинает штурмовать наш клиент постоянными пакетами, которые передают информацию не только о вас, но ещё и обо всех других игроках, о своей личной информации(маппинг как пример) и ещё много чего.

Происходит это вот все очень быстро, в случае с CS go это происходит в среднем 64 раза за секунду, в случае сампа 60. Но бывает такое, что наш клиент, ввиду проблем с интернетом, просто не успевает получать пакеты с информацией, а отправленные пакеты приходят на сервер достаточно долго. Так вот задержка в получении пакетов называется ping. Когда нам пишет, что наш пинг 1000, это означает, что задержка в получении информации (или ее отправлении) от сервера составляет 1 секунду (ping измеряется в 1/1000 секунды). Конечно, бывает такое, что наши пакеты и вовсе не доходят до сервера, в таком случае они теряются и наш клиент, получая ошибку, начинает откатывать действия или их тормозить (распространенные фризы в игре, при плохом интернете, или как говорят в народе: большой пинг). 

Так же работает Raknet, вернее это просто платформа для передачи пакетов. У пакетов есть несколько видов и каждый из них подходит под определенные ситуации. Например, Remote Procedure Call (RPC) пакеты вызывают определенные функции на нашем клиенте с сервера. Также это работает и в обратную сторону, когда мы садимся в машину, мы отправляем RPC пакет на вызов функции OnPlayerEnterTheVehicle с передаваемыми параметрами (playerid, carid ....). Также это работает и в обратную сторону от сервера, например сервер сам сажает нас в машину, тогда у нас в клиенте вызывается функция EnterTheVehicle с параметрами, которые были переданы от сервера в RPC пакете.

 

 

Но иногда пакеты могут не доходить до сервера и происходит это не случайно. NOP или No OPeration это некая блокировка на получаемые или отправляемые пакеты. Таким образом с помощью дополнительного софта игрок может игнорировать inComing (входящий в клиент) RPC пакет SetPlayerHealth. Тогда сервер просто не сможет изменить количество здоровья у игрока. Также можно поставить NOP на SetPlayerPos и тогда сервер не сможет изменить наше местоположение. Важно!:RPC пакеты доходят до клиента, но просто не пропускаются в игру. Такие NOP'ы могут быть абсолютно на любые пакеты, причем не только входящие, но и исходящие (Outcoming RPC), таким образом мы можем просто скрыть от сервера информацию о нашем передвижении (так работает CamHack, он блокирует для сервера пакеты местоположения камеры). NOP'ы являются большой проблемой для Samp серверов, так как их очень сложно выявить, однако сделать это можно.

 

2. Чит программы.

 

Дело в том, что если информация обо всех игроках отправляется в клиент, но лишь не показывается игрой, то почему бы не показывать ее самим? Именно так работают абсолютно все чит программы. Они либо читают пакеты, либо изменяют их во время отправления игрой.

Читы есть в любой игре и сделать их можно абсолютно без проблем. Кстати, в основном читы действуют лишь на 2 параметра, это пакеты входящие и исходящие, но есть ещё один параметр, на который они могут влиять, это внутреигровые данные. 

Возьмём пример из сампа: По умолчанию в игре есть полоска с отображением денег, читы с лёгкостью изменяют количество именно игровых денег, на что разработчики модов решили сохранять количество денег в базе данных на сервере, а не на клиенте. Так и началась(образно) борьба разработчиков читерских софтов и игровых серверов. Самым известным исходом данной войны можно назвать античит. Античит это некий алгоритм, который находя нарушение от игрока, производит с ним те или иные манипуляции. Как только выходит обновление на античит, разработчики софтов тут же подравниваются под него и делают противоборственные методы обхода этого алгоритма.

 

Алгоритмы препятствия использования читов есть нескольких видов:

 

Алгоритмы, использующие данные, передаваемые клиентом, для проведения аналитики действий игрока. Тут сразу понятно, что читы спокойно обходят такие проверки, и поэтому данный вид совсем не актуален, однако почему-то активно используется в Сампе. Конечно, тут главная проблема в исходном материале, так как функционал a_samp крайне неточен, а главное, что легко обходится. Вообще, недавно столкнулся с таким Клео как телепорт, многие думают, что телепорт легко фиксится обычной проверкой на изменение координат игрока (когда сверяем как сильно изменились координаты игрока, например за 1 секунду), но я уже говорил в этом уроке, что пакеты, отправляемые на сервер с лёгкостью можно заблокировать NOP`ом. Или вообще прикольный (но неактулальный!) способ изменения координат. Просто игрок телепортируется на точку в игре, а чит использует NOP на GetPlayerPos, сервер бессилен, так как не получает информацию о игроке, но софтер спокойно бегает по карте и убивает игроков, а потом если встанет на какой-нибудь пикап, так его ещё легально сам сервер телепортирует. Это я рассказал лишь маленькие и уже не совсем актуальные методы, подобных и более интересных очень много, но в любом случае такой вид античита крайне не эффективен и это моя основная мысль.

 

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

 

Ещё один вид из самых распространенных среди начинающих и не только разработок: шифрование пакетов. Если вы не знаете, что такое шифрование или хеширование, то самое время мне объяснить разницу: хеширование это создание хеша(некого пароля), который будет получаться только из одного такого же ключа, который мы введем, т.е. ввели ключ "samp" получили: "hsi1rhwofu293u2odnqpfh29u319"(клацал по клаве, но строка будет примерно такой же), причем такой же хеш не получим не из какого другого ключа. А шифрование, это нечто похожее на хеширование, однако здесь мы просто заменяем символы на код, после чего спокойно можем получить из алфавита нашего кода исходные символы(ну или цифры). Так вот кодирование достаточно часто используется в различных играх, но тут возникает две проблемы. Первая: опять же возможность узнать алфавит шифра и декодировать пакет. Вторая: увеличение игрового ping (так как шифр вещь тоже не быстрая). 

 

Аналитика игровых составляющих. Данный вид алгоритмов просто проверяет наличие посторонних программ, которые воздействуют на игру. Опять же не без клиентской части, однако тут исходит несколько следствий: 1. Возможность обойти такие алгоритмы, ибо маски процессов дело хоть и сложное, но возможное. 2. Клиентская часть сама по себе проблема ещё та, из-за чего вы можете просто потерять время на ее разработку. Но если вы создатель крупной игры, то впринципе внесение такого алгоритма лишь обезопасит вашу игру от софтов.

Перфорация пакетов. Каждый пакет отныне мы будем перфорировать на несколько, таким образом, когда к нам будет приходить первый подобный пакет, мы будем просто сравнивать его с последующими. Отправлять подобные пакеты будем постоянно случайное количество, но когда они будут проходить через читы, они просто не будут изменяться ВСЕ, так как все таки имеют небольшие различия(а не просто копипасты), и в следствии чего мы получим 40-60% измененных пакетов, 20-30% неактуальных и 10-40% истинных, которые и будут играть ключевую роль. Конечно, я понимаю, что данный вид лишь обезопасит от нубо-читов, которые не понимают, что может приходить несколько пакетов, а не один за 1 tick. Да и нагрузка будет явно не в плюс к КПД, но это лишь в теории. Да и клиентская часть опять же необходима.

 

Теперь стоит рассказать как проверить игрока на наличие NOP.

 

Для этого нужно провести обычный листинг callback'ов. За сколько тиков срабатывает callback OnPlayerSpawn после функции SpawnPlayer. Потом будем просто проверять, а вызвался ли callback? Если нет, то скорее всего у нашего экземпляра имеется NOP. Конечно, есть ещё много других функций, но главное, что у всех примерно такой способ работы и поэтому данный метод подойдёт для большинства NOP'ов. Приведу как ещё один пример: OnPlayerEnterTheVehicle. Ноп на данный каллбэк можно выявить обычной проверкой на доступность этого транспорта для игрока, на нажатую клавишу Enter и на "Вызвался ли callback?".

 

И единственное, что нопы не могут контролировать это Kick или Ban, так как соединение перекрывается не через RPC, а просто прекращением подачи и получения пакетов сервером для игрока.

 

3. Блок чейн.

 

Обещал рассказать про это, но есть небольшая проблема.... Дело в том, что блок чейн ещё не разработан на практичном уровне, и поэтому все, что я вам сейчас расскажу лишь теория, зачастую додуманная мной.

Блок чейн позволяет отказаться от централизованной серверной части, делая каждый клиент неким блоком в сети. Каждый клиент несёт информацию о том или ином действии игроков, подключенных к блок чейну. Чтобы информация не была доступна для мошенников с одного компьютера, на самом устройстве (клиенте) она хранится: 1. В зашифрованном виде, алфавит которого постоянно изменяется в зависимости от ключа пользователя, 2. В частичном и неактуальном виде, чтобы данная
 
информация стала полной и актуальной, ее нужно совместить в виде алгоритма (который тоже постоянно меняется да-да) с другими кусками информации, находящейся во всех остальных блоках. Для мультиплеера это представляется возможностью полностью искоренить оплату хостинга(это скорее для серверов), и полностью запретить использование серверов, так как пакеты опять же не будут полными и следовательно доступными к изменению. В качестве наглядного примера будем использовать Telegramm. Когда вы отправляете сообщение другому пользователю, оно отправляется сразу ему под кодировкой end-to-end и хранится только на вашем и его устройствах. Единственное, что хранится на сервере телеграмма это информация о самом пользователе, в частности его ip, номере телефона и никнейма.

Зачем я это рассказал? Дело в том, что система блок чейна по поводу неполной и зашифрованной информации это одно из самых интересных решений против читов. Читы, как я уже говорил, редактируют и читают пакеты, но что если прочитать или редактировать пакет не представиться возможным? Вот что интересно, ну, а на этом моя статья подходит к концу, так как по этой теме уже все.

Автор: Nestyreff
Копирование и доп.публикация без разрешения запрещена.
Любая обоснованная критика приветствуется.

 

[m1n1vv Хороший 43]

Зачем материал делать нечитабельным? Убери жирность, выравнивание по центру, и нормальный шрифт. Код добавь не скринами, а текстом.