Централизованый формат снифов

[RomanRom2]

господа, поступило шикарное предложение по формату чанка:

(byte)Direction;
(uint)UnixTime
(uint)TickCount
(uint)Data.Length
(uint)DD.Length
(byte[])Data
(byte[])DD

как вам?
при этом хидер читается структурой, что удобно само по себе.
после хидера идут данные опкода.
после данных опкода идут DevelopersData, если DD.Length больше нуля.
в данном варианте сведены к минимуму все затраты и DD стал переменной длины, что тоже должно всех устроить.

правда в этом случае, к великому сожалению Константина, (uint)Data.Length будет содержать данные вместе с опкодом, а Data данные вместе с опкодом. ну в прочем это само по себе и вытекло бы, как ни крути.

хех. вон VDm предлагает ту же идею и с хидером снифа.

[user456]

Сообщение от RomanRom2

господа, поступило шикарное предложение по формату чанка:

(byte)Direction;
(uint)UnixTime
(uint)TickCount
(uint)Data.Length
(uint)DD.Length
(byte[])Data
(byte[])DD

Да, если слишком кратко излагать - не доходит. Развернуто:
struct main_hdr{
int sign;
uint pkt_hdr_offset;
uint pkt_hdr_len;
uint data_offset;
...
}

struct pkt_hdr_node{
int len;
char [50] name;
}

потом с адреса pkt_hdr_offset забиваеш массив и получаеш свои типы, можно по name разбор делать или добавить константы типа. Получится структура велосипеда, который давно изобрели в каком-нибудь DBase.
Один фиг через год станет понятно что UnixTime в каждом пакете это мусор (достаточно тиккаунтов на четверо суток в миллисекундах и даты создания файла или одного time в хедере)

[VDm]

Сообщение от user456

Да, если слишком кратко излагать - не доходит.

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