Бинарный сокет, что лучше кушать и выплевывать?

[Psycho Tiger]

Делаем игру, решили уйти прочь от всяких XMLSocket и работать с бинарным Socket`ом.
Делаем по принципу: 2 байта на команду (атака, сообщение в чат, пропуск хода и т.д.) - решили сделать с запасом, 2 байта на длину сообщения, далее идёт само сообщение.

Есть класс, который занимается "разговором с сервером". Вот сигнатура метода чтобы послать что-то на сервер:

public function send(packet:uint, message:ByteArray):void {

При приёме, когда сообщение полностью пришло я отправляю SampleEvent с data, который ByteArray. В итоге я плююсь туда-сюда ByteArray, но сомневаюсь, что такой подход хорош.

Как бы сделали Вы?

[Котяра]

Я использую AMF или protoBuf
мессаджи запускаю на выполнение, каждый мессадж сам знает как ему выполняться (посмотри пример про protoBuf - это вызов item.changeModel).

[mayakwd]

у нас самописный протокол для передачи объектов. методы передачи json, amf + сжатые\несжатые.

работа идет через byteArray но в send отдаются просто объекты (удобнее работать)
скорость приемлемая.

[Psycho Tiger]

@Котяра: интересная вещь) Но пока немного пугает сложность нормальной реализации, а не как у тебя запрос-ответ;

По поводу AMF думал, но ни разу не применял на практике. Я так понимаю туда сериализуется любой объект (кроме DO) и такой же объект приходит с сервера. Я только не очень понимаю эту магию, как что-то извне можно десериализовать в любой экземпляр любого класса, ну да ладно (про алиасы я знаю, я про сам алгоритм в ФП. Он меня порабощает)). Удобство здесь очевидно, а есть ли разница в объеме передаваемых данных, по сравнению с моим вариантом?

[gloomyBrain]

AMF передает наименьшее число данных, т.к. все данные кешируются как на клиенте, так и на сервере.

[Котяра]

Сообщение от Psycho Tiger

@Котяра: интересная вещь) Но пока немного пугает сложность нормальной реализации, а не как у тебя запрос-ответ;

ну я немного расширил протокол - у меня как-раз и не запрос/ответ, а парсинг любых сообщений. Кроме того
есть реализация моего "расширенного PB" на c++.

По поводу AMF думал, но ни разу не применял на практике. Я так понимаю туда сериализуется любой объект (кроме DO) и такой же объект приходит с сервера. Я только не очень понимаю эту магию, как что-то извне можно десериализовать в любой экземпляр любого класса, ну да ладно (про алиасы я знаю, я про сам алгоритм в ФП. Он меня порабощает)).

Есть тулзы которые по as3 готовят java класс и наоборот. (см graniteDS) Что-то поднобное wvxwv писал на php.

Удобство здесь очевидно, а есть ли разница в объеме передаваемых данных, по сравнению с моим вариантом?

Я не совсем понял твой протокол. т.е. ты всего навсего передаёшь сообщение, которое потом всё равно надо как-то десериализовать. или это строка)

[Psycho Tiger]

@Котяра: серверник демона на пхп пишет. Не подскажешь, в каком месте у wvxvw это можно найти? )

Я не совсем понял твой протокол. т.е. ты всего навсего передаёшь сообщение, которое потом всё равно надо как-то десериализовать. или это строка)

Ну исходили из гибкости использования. На каждую команду идёт свой парсинг.
Например, если 2 игрока подвинулись в точку x,y - то придёт пакет с ID=5 и будет парс его как номер игрока - координаты. Если ID=1, то это сообщение в чат. Ну как то так, в целом )

[Котяра]

На каждую команду идёт свой парсинг.

те же яйца — только в профиль.
Вы по сути изобретаете свой велосипед.
Я раньше тоже изобретал.
мол 2 байта - индекс для типа класса, а потом тело экземпляра, на который уже свой парсер по 1 2 байтам.
потом всё это согласовывать - писать доки итп.
нафик.
всё давно придумано до нас и на грабли понаступлено.
amf хорош, но немного избыточен
protoBuf - хорош, но немного не для системы сообщений.. причём для алиаса классов им оставалось то всего-ничего - вложенные месаджи поддерживаются.
Я этот шаг сделал. тесты по сравнеию с amf не делал, но приблизительно могу сказать: по времени сериализации pb быстрее нативного amf раза в 2-3. по длине кодировки раза в 2-10 ( зависит от структуры передаваемого класса - PB позволяет передавать неполные данные, которые на стороне AS3 преобразуется в дефолты, кроме того он реально короче. т.к. передаётся не имя поля а его битовый алиас.
Всё конечно в сравнении. если полями данных является строка, то выигрыш будет очень маленьким, а если набор интов/флоат - например для передачи текущих координат, то мой выбор -PB.

[Crenth]

такие умные вещи говорите...

я пользую стандартный customClient от netconnection
сервер присылает объект, который парсить и не нужно.

switch (object.do_what) {
   case do_it : do it; break;
   case dont_do_it : ok; dont do it; break
}

главное, что код получается читабельный и компактный

[Котяра]

2Crenth - это мало отличается от json или xml.
.proto тем и удобны что можно на основе их генерить классы данных практически на любых я зыках. решили сменить сервак с явы на плюсы- ок, либо сделать сторонний модуль на питоне - нет проблем.
Единственный косяк "чистого" protoBuf, что они почему-то не декларируют основной класс сообщения, но это решается, как я уже писал.
То же самое и про AMF - очень хороший, но временами избыточен.
В общем резюмирую: используйте бинарный сокет и собственные форматы, только если РЕАЛЬНО нужно сокращать объём ПЕРЕДАВАЕМЫХ данных и вы уверены, что ваш формат меньше чем AMF и затраты на его де/сериализацию тоже меньше.
Иначе - достаточно XMLSocket или AMF/PB.