Цитата:
Сообщение от wvxvw
Ну и еще проблема - а что делать с 64-битными числами? Number их полностью не опишет, точности не хватит, а писать только ради этого специальный класс имитирующий работу 64-битного числа... ну даже не знаю...
EDIT:
Ксати, решил более вплотную этим занятся  Посмотрел исходники AS библиотеки... ну, прямо скажем, можно было бы и лучше... калька с Джавы + недоделаная. Человек не знал про свойство endian у ByteArray ну и еще по мелочам, типа, сам написал упаковку int, в то время, как в AMF она точно так же работает |
Есть проблемы конечно.. в код сериализации AS3 я практически не лазил, сделал только сериализацию самих мессаждей ( в моём блоге устаревшый код - есть пофиксенный, если надо выложу..)
другой вопрос, что 64- битный double, 64int, enum, etc. совершенно не обязательно использовать при создании .proto на конкретном проекте. есть способы как обойтись без этого.. ( тысячи их) можно для этих целей вообще работать только с protobuf lite (могу ошибаться, но там, кажется, уменьшенный набор типов)
Большая просьба! если будут интересности по PB - как нибудь мне маякните! очень интересна мне эта тема.. пока правда отложена на неопределённое время..
Добавлено через 8 минут
Цитата:
Сообщение от gloomyBrain
Чего-то я поковырял-поковырял и решил придумать лучше =)
Под игровые нужды.
|
Главный минус: абсолютная нерасширяемость протокола.
Тут какбы есть 2 пути - использовать раздутый, но отлично расширяемый amf - подобный протокол
либо писать жосткий и мегаоптимизированный.
если протокол написан 1 раз и больше меняться не будет, тогда лучше 2 вариант, если изменения будут, или хотя бы возможны, нужно смотреть в сторону более расширяемого варианта сериализации.
а так можно все возможные данные зашить в пару байт и проверять кэйсом (ифом)
if (a==1) значит смотрим заранее загруженные варианты данных с id = 1.. итп. (утрирую)..т.е. именнованные по id события, с минимальным количеством данных, или вообще без них...
Цитата:
Сообщение от gloomyBrain
Пока мысли такие - первые байты - short, являющийся номером команды и определяющий, как смотреть на оставшиеся байты.
Или вообще сделать нечто вроде бинарного дерева команд (как бы наследующих друг-друга) и читать 2-3 Boolean (и так двигаться по дереву влево-вправо), а после этого "хвост" сообщения уже будет однозначно обработан
Или это не так делается? Посоветуйте, кто знает =)
|
кстати PB практически так и работает.
т.е. с сервера приходит набор данных(для примера все данные int)
1.10.2.20.3.30 - сериализуем:
1 - таг типа сообщения = 10 ( alias): - соответствует, например клаcсу PointMessage
в нём таг 2 - это координата x = 20
таг= 3 - координата y = 30
- создается pointMessage {alias:10, x: 20, y:30}, у которого кстати можно прописать еще и нужные методы - я делал некий перекрываемый для всех Message - function changeModel()
минусы - отсылка лишних байт тагов, казалось бы можно без них обойтись.. передавать 10.20.30 - но в PB заложена возможность не посылать все поля, что в принципе удобно, и передача массивов, здесь без тагов не обойтись..