Какой протокол сокет-сервера эффективен?

Однако большинство «профессиональных» фрагментов кода, которые я видел, по-видимому, отправляли объекты или команды xml. Мне кажется, что для этого требуется гораздо больше ресурсов сервера, не так ли?

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

Обычный текст обходится дороже, чем двоичный формат, содержащий ту же информацию. Например, если вы отправляете только 1 байт, вы можете отправить только 10 различных команд, цифры от 0 до 9. Двоичный формат может отправить столько разных команд, сколько различных значений вы можете поместить в байт, т.е. 256.

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

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

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

Вы должны знать о задержке, связанной с отправкой ваших данных. «Начать поворот»/«остановить поворот» будет менее эффективным, если время между получением этих пакетов отличается от времени между их отправкой.

Я не могу говорить обо всех играх, но когда я работал над таким кодом, мы отправляли информацию об ориентации и положении по сети. Таким образом, получатель мог бы выполнять сглаживание и экстраполяцию (выяснить, где объект должен находиться «сейчас», на основе имеющихся у меня данных, которые уже известны как старые). Разные игры будут хотеть отправлять разные данные, но, вообще говоря, вам нужно будет выяснить, как сделать так, чтобы отображение данных получателя совпадало с отправителем, поэтому вам нужно отправлять данные, которые устойчивы к сетевым проблемам.

Кроме того, многие игры используют UDP для такого рода передачи данных вместо TCP. UDP ненадежен, поэтому вы можете не получить все свои пакеты. Это означает, что «остановить движение сейчас» или «начать движение сейчас» нельзя принимать парами. При кодировании поверх UDP еще более важно время от времени отправлять «это состояние прямо сейчас», чтобы у клиентов было достаточно возможностей для синхронизации.

Распространенным способом является использование двоичного формата, а не текстового или xml. Таким образом, всего одним байтом вы можете представить одну из 256 различных команд.

Также используйте UDP, а не TCP. Игра будет намного быстрее реагировать с UDP в случае потери пакетов. В случае потери пакетов вы все равно можете экстраполировать движения. С каждым пакетом отправьте номер пакета, чтобы сервер знал, когда была отправлена ​​команда.

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

редактировать:

Чуть не забыл... Google буферы протоколов могут очень помочь, когда отправка сложных структур данных.

Я подумал, что отдам свои пять копеек и предоставлю практическое применение тому, что называется двоичной сериализацией. Концепция на самом деле невероятно проста, но только снаружи кажется сложной.

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

В качестве примера, немного грубого кода:

private const MOVE_RIGHT:int = 0; 
private const MOVE_LEFT:int = 1;
private const MOVE_UP:int = 2;
private const MOVE_DOWN:int = 3;

function processData(e:event.data)
{
    switch (e)
    {
       case MOVE_RIGHT:
       //move the clients player to the right

       case MOVE_LEFT:
       //move the clients player to the left

       case MOVE_UP:
       //move the clients player to the up

       case MOVE_DOWN:
       //move the clients player to the down

    }
}

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

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