Быстрый анализатор текста для сообщений сервер-клиент - MMO - PullRequest
2 голосов
/ 15 января 2012

Применение

Я работаю над MMO и столкнулся с проблемой. Созданный мной MMO-сервер быстро и локально отправляет сообщения моему игровому клиенту каждые ~ 50 миллисекунд по сокетам UDP. Вот пример сообщения от сервера клиенту через мою текущую систему сообщений:

кол = {2} тела = {[г = {АГТ} = {ID 42231} поз = {[50.40142117456183,146.3123192153775]} гнили = {200,0}, т = {АГТ} = {идентификатор 4946} = {поз [65.83051652925558,495.25839757504866]} гнили = {187,0}}

count={2}, 2 = number of objects
[,] = array of objects

Я создал простой анализатор текста, код: http://tinypaste.com/af3fb928

Я использую сообщение как:

    int objects = int.Parse(UTL.Parser.DecodeMessage("count", message));
    string body = UTL.Parser.DecodeMessage("body", message);
    for (int i = 0; i < objects; i++)
    {
        string objectStr = UTL.Parser.DecodeMessage("[" + i + "]", body);
        // parse objecStr with UTL.Parser.DecodeMessage to extract pos & rot and apply to objects
    )

Выпуск

Когда у меня больше объектов ~ 60+, производительность резко падает.

Вопрос

Каков стандартный метод упаковки и чтения сообщений между клиентами и сервером в MMO или онлайн-играх в реальном времени?

Ответы [ 3 ]

2 голосов
/ 18 июня 2013

Бинарный протокол будет намного быстрее здесь.Возьмите координаты, которые вы передаете, например.Когда вы транспортируете их как байты, они будут занимать 8 байтов на ось, тогда как строковое представление использует 2 байта на символ (если вы не переносите как ASCII, но даже тогда двоичный дубль будет меньше).

Тогда на самом деле превращение этой строки в число - намного больше работы;сначала необходимо создать подстроку, что приведет к дополнительным затратам на сборку мусора, затем нужно проанализировать число, что не быстро (но, честно говоря, вы все равно можете анализировать сотни тысяч удваивается в секунду), потому что .NET * double.Parseносит очень общий характер и должен учитывать множество различных форматов.Вы бы получили заметную скорость, написав свой собственный двойной парсер на случай, если вы будете придерживаться текста, но, как я уже сказал, вы должны использовать двоичный код, если разбор сообщений является узким местом.Превращение байтов в двойные (с небольшим количеством волшебства unsafe, что должно быть хорошо, если вы работаете на сервере и должен иметь режим полного доверия), это вопрос копирования 8 байтов.

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

1 голос
/ 15 января 2012

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

Попытайтесь изменить свой код, чтобы перебирать строку за символом, и анализировать данные, используя только исходную строку. Вы должны использовать только индексирование, indexOf и, возможно, даже написать свои собственные парсеры int и float, которые принимают строку смещение + длина, чтобы вообще не создавать подстроки. Я не уверен, является ли это излишним, но это не «преждевременная» оптимизация, если у вас есть веские доказательства того, что она работает медленно.

Кроме того, вы пробовали буферы протокола? Я считаю, что их производительность должна быть довольно хорошей (просто напишите небольшое консольное приложение для теста производительности). Или с JSON, это стандартный лаконичный формат (но я понятия не имею, насколько оптимизирован Json.NET). Ничто не должно побеждать жестко закодированный специализированный синтаксический анализатор с точки зрения производительности, но, учитывая будущее обслуживание, я бы попробовал один из этих протоколов раньше всего.

1 голос
/ 15 января 2012

Я бы хотел использовать RPC-фреймворк, такой как Thrift , чтобы сделать подъем за вас. Он будет выполнять упаковку и анализ для вас, и посылать вещи по проводам в двоичном формате, чтобы он был более эффективным.

Также есть множество других опций. Здесь - сравнение некоторых.

...