AMF3 + JAVA SE
 

Всем привет =)
Суть вопроса:
Пытаюсь сделать отправку и пересылку объектов через AMF (socket.readObject() / socket.writeObject())
Для этого, как я понимаю, мне нужно создать класс в AS3 и его эквивалент в JAVA. Маленькая проблемка в том, что я так и не понял, как это правильно сделать.
Если у кого-либо есть понимание этого вопроса или просто полезные ссылки - большая просьба поделиться
Торжественно обещаю сказать спасибо в удобной для Вас форме :drinks:

ЗЫ
Server-side мне тоже очень интересен

Вы случайно сокет с NetConnection не спутали?

Нет. А с чего мне их путать?
Если вопрос стоит, какой сервер я использую - то нет, не red5, а простенький самописный.
Просто есть возможность передавать сжатые бинарные данные в аффигенно удобном виде. То есть AMF.
И NetConnection тут абсолютно незачем (мне, по крайней мере)

в исходниках blaze ds покопайтесь.

Не сказал бы, что AMF это самый удобный вид.

здесь не копали?

сериализация AMF3 достаточно простая - почитай доку по стандарту.
но советую лучше все-таки использовать json + gzip (скорость сериализации быстрее).

А отчего так? Может тогда взялся не за то? Просто писать собственный парсер на сервер-сайде неохота =)

я оттуда начал раскопки =)

Ну уж нет. Я ленивый => не буду делать то, что сделали другие
Ну с точки зрения клиента (FlashPlayer) это вряд ли... А с точки зрения сервера - да, наверное, но есть и ощутимые плюсы.

По итогу решил ковырять BlazeDS + нашел еще несколько бесплатных вариантов, правда немного обездоленных в плане документации. Не хватает только толкового туториала...

А там в чем проблема-то? Сделать качественный registerClassAlias^_^?

Да причем тут ClassAlias?
Классы будут вкомпилированы.
Просто я не совсем понимаю, как переслать объект кастомного класса так, чтобы в JAVA он распознался.
И наоборот - как из JAVA отправить объект класса, существующего в AS3

Свой собственный бинарный формат будет быстрее и экономичнее, чем AMF и уж тем более json + gzip (с фига ли посимвольный JSON будет быстрее нативного ByteArray?).

посмотрите в сторону google protobuf
тут мои эксперименты., если заинтерисует, есть больше.. пиши в личку.

Мой ответ относится к серверной части, обычно она шлет дохренище данных клиенту, а не наоборот...

Типа раззиповать и распарсить дофигища строковых данных средствами AS3 будет быстрее? Protobuf - интересный формат, но некоторые его структуры в AS3 нечем обеспечить (типа все тех же енумов), и записать его будет чуть дольше на клиенте, а с точки зрения сервера - лучше не придумаешь :)

просто не надо создавать .proto данные с энумами.. вполне достаточно (99%) int, string, boolean, составной message и array.
Другая проблема что само message несериализованно, но это лечится вводом поля alias..

Чего-то я поковырял-поковырял и решил придумать лучше =)
Под игровые нужды.
Пока мысли такие - первые байты - short, являющийся номером команды и определяющий, как смотреть на оставшиеся байты.
Или вообще сделать нечто вроде бинарного дерева команд (как бы наследующих друг-друга) и читать 2-3 Boolean (и так двигаться по дереву влево-вправо), а после этого "хвост" сообщения уже будет однозначно обработан
Или это не так делается? Посоветуйте, кто знает =)

Ну да, т. е. клиент у нас будет тупить на посимвольном парсинге этого самого JSON.

Ну и еще проблема - а что делать с 64-битными числами? Number их полностью не опишет, точности не хватит, а писать только ради этого специальный класс имитирующий работу 64-битного числа... ну даже не знаю...

EDIT:
Ксати, решил более вплотную этим занятся :) Посмотрел исходники AS библиотеки... ну, прямо скажем, можно было бы и лучше... калька с Джавы + недоделаная. Человек не знал про свойство endian у ByteArray ну и еще по мелочам, типа, сам написал упаковку int, в то время, как в AMF она точно так же работает :)

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

со стороны серверной части - отсылается же не одному клиенту и сериализация в данном моменте лучше подходит та что я описал, так что все зависит от случая.

вообще лучше использовать как уже вами подмечено свой протокол.

Есть проблемы конечно.. в код сериализации AS3 я практически не лазил, сделал только сериализацию самих мессаждей ( в моём блоге устаревшый код - есть пофиксенный, если надо выложу..)
другой вопрос, что 64- битный double, 64int, enum, etc. совершенно не обязательно использовать при создании .proto на конкретном проекте. есть способы как обойтись без этого.. ( тысячи их) можно для этих целей вообще работать только с protobuf lite (могу ошибаться, но там, кажется, уменьшенный набор типов)
Большая просьба! если будут интересности по PB - как нибудь мне маякните! очень интересна мне эта тема.. пока правда отложена на неопределённое время..

Добавлено через 8 минут
Главный минус: абсолютная нерасширяемость протокола.
Тут какбы есть 2 пути - использовать раздутый, но отлично расширяемый amf - подобный протокол
либо писать жосткий и мегаоптимизированный.
если протокол написан 1 раз и больше меняться не будет, тогда лучше 2 вариант, если изменения будут, или хотя бы возможны, нужно смотреть в сторону более расширяемого варианта сериализации.
а так можно все возможные данные зашить в пару байт и проверять кэйсом (ифом)
if (a==1) значит смотрим заранее загруженные варианты данных с id = 1.. итп. (утрирую)..т.е. именнованные по id события, с минимальным количеством данных, или вообще без них...
кстати 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 заложена возможность не посылать все поля, что в принципе удобно, и передача массивов, здесь без тагов не обойтись..

На самом деле, перечитав спеку, понял, что не такой уж он и раздутый. Да, можно написать свой очень-быстро-парсящийся(сяемый? суемый? ... ?) + мега-ужатый протокол, но как-то лень потом по пол дня добавлять одну опцию.
В общем, пришел к выводу, что надо научиться парсить и записывать Unsigned 29-bit Integer (с парсингом, в принципе, я уже разобрался), и ... все! Потому как за вчерашний вечер я успел написать парсер для всех простых типов в AMF.
Да, быдлокод. Ну и что? =)