×

Помогите с протоколом передачи данных для онлайн игры

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

Сейчас используем JSON.
В чем минусы:
1. Много данных передается
2. Формат достаточно очевидный для анализа
3. П1. приводит к тому, что если много пакетов, то могут приходить несколько команд на сервер на один раз
плюс последняя или первая может быть разбитая.

Какой формат посоветуете?

Требования к формату:

1. Компактность
2. Защищенность (желательно как-то его шифровать)
3. Легкость сборки всего пакета если например за один раз в сокет пришло начало пакета, а потом конец пакета

Підписуйтеся на Telegram-канал @gamedev_dou, щоб не пропустити найважливіші статті і новини про геймдев

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Итак, выбирая между TLV, Binary XML и bson решил попробовать использовать bson, завершая в конце \0 — это как признак окончания полноценного пакета. Соотв. если окончания нет — значит пакет пришел не полный и его надо склеивать.

В качестве библиотеки под node.js решил попробовать Buffalo — github.com/...3d/node-buffalo Прост как угол дома, как покажет себя на реальных пакетах будем посмотреть.

Пока беспокоит есть ли поддержка bson на клиенте. Если кто знает — дайте плиз знать.

Если есть еще какие идеи как гонять данные между клиентом и сервером — буду рад услышать комментарии.

Не совсем понятна проблема, но в этом контексте:
1) Сжимайте поток данных (либо копайте в сторону Binary XML)
2) Самый простой способ шифрования и самый доступный — использование XOR (исключающее ИЛИ на поток, обратимая операция, на клиенте и на сервере — одинаковый аргумент шифрования/дешифровки, естественно)

3) Ну а постановку в очередь и разгребание очереди по признаку окончания пакета не используете?

1) Кстати да, это мысль
2) Xor попробуем

3) На сервере у нас очередь команд. То есть каждая команда попадает в очередь. Очередь разбирается сейчас раз в одну десятую секунду и потом идет рассылка всем клинтам об измененном состоянии игры. В качестве разделителя команд пока искользуем \0. Но, как я уже говорил при большой динамики со стороны игрока идет рассылка большего числа команд. То есть в сокет может придти не одна команда а больше причем первая или последняя может быть неполной. Пока для теста берем только полноценные команды — они идут в очередь команд на обработку. Битые команды пока не клеем. Соотв. и стал вопрос, что не хочется изобретать свой велосипед. Может есть уже готовые идеи, алгоритмы.

bson, и переходить легче будет.
Еще thrift и протобуферы.

А клиент какой(ц++, яваскрипт)?

bson посмотрю, начет других идей тоже сенкс — буду разбираться

клиент у нас JavaScript, сервер на Node.js соединение постоянное через сокет — соотв. на текущий момент у нас проблемный момент это протокол передачи данных между клиентом и сервером.

Если клиент javascript — я бы остался с json, так как браузеры его хорошо нативно парсят, a своя реализация сложного парсинга и криптографии могут нехило подтормозить браузер.

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

назащищенность — то есть очень легко разобраться что передает сервер

А кому это может быть интересно и чем? Может, излишняя паранойя?

Игрокам читерам, хотя у нас все рассчитывается на сервере.

хотя у нас все рассчитывается на сервере

Я об этом же.

Да, возможно немного параноей попахивает))

Підписатись на коментарі