Простой бинарный протокол (формат)

Cap N Proto?

Ну и в Protobuf есть fixed типы

там жирный рантайм и не ясно что с C#

жирный

В каком плане жирный? Размер бинаря? )

C#

https://code.google.com/p/protobuf-net/

bittorrent, точнее bencode. Размер поля не фиксирован, но для особо не могущих в символы-разделители там есть следующий лайфхак.

Например, строки кодируются как «6:string7:string2{etc}», где цифра - длина поля, а после двоеточия идёт значение.

cbor попробуй. Без схемы, но тоже простой.

Мну тут погуглил по «binary data exchange protocol java» и вышел на protobuf, openfast, MessagePack и другое. Не знаю, то ли это, но ссылки решил тут оствить. ;)

тоже видел, оно уже rfc, но тоже наркомански тегированное

6:string7:string2{etc}

круто, надо запомнить.

Если reader/writer генерируется по схеме, то в чем смысл требования о фиксированном размере полей?

два из упомянутых тобой я уже перечислил в исходном сообщении, спецификацию openfast я так и не смог скачать (https://github.com/real-logic/simple-binary-encoding спецификация идет на тотже сайт и также не скачать)

проблема не в том что их нет, а в том что они практически все под динамические структуры, да с затейливыми тегами отчего описание бинарного формата (и его парсер) выходит весьма затейливым

потому что мне не нужны поля с целочиселнными значениями переменного размера

Фиксированый размер полей
asn.1

А разве оно умеет?

Но почему? Все равно же это будет автоматически сгенерированный код обрабатывать... Просто интересно.

Из того, что здесь еще не упоминали, есть Thrift и Beep (в последнем на счет схемы не уверен).

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

Все равно же это будет автоматически сгенерированный код обрабатывать...

- думаю о тех кому может потребоваться писать парсер вручную

- это лишняя работа направленная на экономию места, мне экономить место не требуется

- думаю о тех кому может потребоваться писать парсер вручную

Имхо, как только появляется схема, из которой что-то генерируется, о такой проблеме нужно сразу забыть. Особенно, если в Java-реализациях ASN.1 смущает отсутствие поддержки extension points :)

- это лишняя работа направленная на экономию места, мне экономить место не требуется

AFAIK, в ASN.1 PER как раз упаковка значения в минимальное количество бит используется в полный рост. Причем не только для каких-нибудь int-ов или размеров последовательностей. Но, если речь идет о перечислениях, то ASN.1-компилятор сам вычисляет минимальное количество бит, необходимых для представления перечисления. Ну и, в качестве довеска, есть aligned ASN.1 PER, и есть unaligned. Если вы думаете о тех, кому может потребоваться писать парсер вручную, то не связывайтесь с ASN.1.

^^^ дело говорит.

XDR

protobufs - использовал из java и ruby. Вроде, всё нормально.

Протобуф.

Хмм, интересно, спасибо. http://linux.die.net/man/3/xdr

CORBA // thread

http://tools.ietf.org/html/rfc4506

ну там то boolean в 4 байтах храниться, то одни все пихают по битам, то другие 4 байта в качестве минимального значения

Это же форма TLV, старо как мир

asn.1 - вроде ничего но все два компилятора для java не поддерживают '...'

В смысле в них нельзя массив с переменным числом элементов сделать??

не это дырка через которую можно расширять протокол не ломая совместимость со старым

http://lionet.info/asn1c/blog/2010/09/21/question-extensibility-removing-fields/

но тут верно сказали, с моими требованиями asn1 не нужен