Как чат должен передаваться и храниться в MMO?

Игроки в MMO-играх обычно могут отправлять сообщения по разным каналам (частные, публичные, гильдии и т. Д.).

Как бы я передал и сохранил эти данные, чтобы внешние пользователи не могли получить доступ к чьим-то приватным сообщениям в чате? Должен ли я хранить данные во временном игровом журнале или базе данных?

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

Вы должны реализовать сообщения чата следующим образом:

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

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

Тем не менее, очень важно, чтобы вы проходили чат через сервер, который вы контролируете. Это не обязательно должен быть игровой сервер, это может быть выделенный сервер для передачи чата, но вы хотите управлять маршрутизацией. Он позволяет вам контролировать диспуты GM, позволяет принудительно выполнять запросы пользователей, чтобы блокировать или отключать звук других пользователей, он решает проблемы, которые могут возникнуть у вас с перфорированием NAT или другими сетевыми махинациями, которые могут возникнуть при попытке однорангового чата, и он обеспечивает достаточный барьер для случайного взлома (к которому склонен одноранговый чат), чтобы решить 90% проблем безопасности. Что примерно так же хорошо, как вы получите.

Я, честно говоря, не уверен на 100%, что вы спрашиваете. Но, надеюсь, следующее полезно.

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

Вот несколько направлений для загрузки их источника. Вам нужно будет проверить это через SVN

Я посмотрел, и если вы зайдете в, src/client/gui/вы увидите класс ChatWindow. Он заботится об отправке сообщений обратно и четвертый на сервер для чата, а также заботится о истории ввода. Похоже, они упаковывают информацию и отправляют ее на сервер для доставки. Так что я представляю, что эта информация чата хранится на их сервере и, следовательно, недоступна для всех. Это если вы не можете войти в базу данных серверов для доступа к записям чата. Я не могу себе представить, что они могут все тоже хранить. Если они ведут журналы чата, возможно, только в течение определенного периода времени (возможно, несколько дней?)

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

Edit1: также обратите внимание, что в папке клиента вы можете найти и authenticentclient класс. Это обрабатывает аутентификацию клиента и т. Д. Я полагаю, что она также будет обеспечивать безопасность, связанную с чатом, с точки зрения аутентификации себя на сервере чата. Они могут не иметь выделенных серверов для чата. Таким образом, это может быть игровой сервер, на котором также работают службы чата для всех своих клиентов. Это то, что вы можете выяснить, действительно изучив код.

Для более крупных MMO я бы положил деньги на них, имея выделенные серверы чата только для того, чтобы позаботиться о чате между игроками. (Так же, как они делают для экземпляров).

Большинство ММО, в которые я играл, не хранят сообщения в течение более длительного периода времени. Потому что это, скорее всего, превратит их в GameCompany с негативным значком, подобным АНБ. Если только у игроков не было прямого доступа к их базе данных.

В Runescape хранятся сообщения в кеше, и он доступен только в течение небольшого промежутка времени. Я никогда не слышал о том, чтобы кого-то забанили из-за того, что такие данные были сохранены. Если нужно когда-либо сообщать о другой игре за то, что он сказал. Он должен быть быстрым, пока его лимит чата в 500 линий не будет исчерпан. После этого все его сообщения будут удалены. В самом людном месте, где игроки кричат ​​друг другу, это до 10 секунд.

Сообщения всегда отправляются через сервер, и их хранение происходит на сервере, а не на клиенте. В противном случае игрок A, взломавший клиент, сможет манипулировать массивом, отвечающим за чат, и буквально напишет, что PLAYER B написал что-то еще. Через некоторое время он мог сообщить об этом игроке, который что-то написал, и кеш других игроков мог больше не хранить такую ​​информацию.

Если вы храните сообщения на КЛИЕНТЕ, что было сделано на чат-портале GaduGadu.pl, пользователи теряют возможность проверять свои чаты на разных компьютерах. Данные, сгенерированные пользователем, будут уязвимы для третьих лиц. В основном в общедоступных интернет-кафе. Или в доме друзей, которые могут отомстить своему бывшему другу.

Если вы сохраните его на своем сервере, игрок B не сможет получить доступ к данным игрока A и наоборот. Имейте в виду, что высказывание «может ли игрок B получить доступ к этим данным» - это широкий вопрос. Вы никогда не можете сказать, если данные в безопасности, если ваш сервер не в сети! Вот пример.

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

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

Каждое сообщение чата, которое отправляет клиент, должно включать некоторую информацию о получателе (общедоступное, гильдия, личное сообщение игроку X). Затем сервер должен определить символы, которым разрешено читать сообщение:

• Для публичных сообщений это символы в определенном радиусе вокруг отправляющего символа.
• Для сообщений гильдии это персонажи, которые имеют ту же гильдию, что и отправитель, который в данный момент находится в сети.
• Для личных сообщений это персонаж с тем же именем, когда он в сети

Затем сообщение должно быть отправлено клиентам, которые контролируют эти символы.

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