Цитата:
Сообщение от VDm
Предлагаю так же учесть доводы user456 насчет указания направления пакета, и расширить это поле с 1 до 4 байт, заодно, сделав размер заголовка чанка кратным 4:
Код:
struct ChunkHeader
{
char direction[4]; // 'RECV' и 'SEND', либо 'SMSG' и 'CMSG', либо то, что вы предложите.
|
пожалуй соглашусь на SMSG и CMSG. и действительно, когда открываешь бинарные данные в фаре, ругаешься, что слету не видно, где начинается чанк.
Цитата:
Сообщение от VDm
Конечно, сомнительно, что номера сборок превысят 65 535, но я увидел uint в описании у RomanRom2.
|
да, я тоже было подумал, что вдруг мы доживем до билда 65к. ну а пусть будет? для унификации и выравнивания, что ли. кто
принципиально против?
Цитата:
Сообщение от Йоха
по поводу byte SnifferID - иожет сделать не 1 байт, а немного длинней, и хранить там символьное представление
|
а это ничего не меняет. какая то сигнатура будет вместо 1 байта. а кто будет поддерживать эти сигнатуры? точно так же их надо будет описывать где то.
Цитата:
Сообщение от LordJZ
И так, на последний момент:
— предлагаю именно такой порядок: длина DD, длина данных, DD, данные.
Данные включают в себя опкод, выравненный до 32 бит.
|
в данном случае не принципиально в какой последовательности хранить. пусть так, логика парсеров ни сколько не меняется.
только хочу еще добавить, что длина данных содержит в себе 4 байта опкода (который выравнен до 4 байт).